#circuitpython-dev
1 messages · Page 357 of 1
In essence, pylint 2.7.0+ has an issue where it detects duplicate code, and that option cannot be disabled. So what we need to do, for the examples, is run pylint with the appropriate flags on each file individually
Just saw your comment on the PR, and makes sense.
I don't recall where I'd gotten that, but clearly it was a core library. Will update the patter
Because alot of samples have from foo import bar and then import foo sort of syntax importing twice I've seen this for I2C
?
Yeah, that's what was blowing up on a PR Melissa submitted that started this bruhaha
or isolated the cause of it I guess
OK... I was hoping it was something easier like it didn't like the essentially blank sample file...
@idle wharf what replaces make test for circup ? Typing the whole:
pytest --random-order --cov-config .coveragerc --cov-report term-missing --cov=circup ?
You can just run pytest I’m pretty sure.
ah ok
But I have this unread book on my desk
So I'm not sure yet 😉
@fossil gorge your last commit failed on the library with the comment I added. And then it showed the pylint --help many times
my test repo has 1 example
Actually it passed on the example and failed with all the help output on the library.
So much screen spew, sorry confusing.
Is this issue in a specific version of Pylint? We could specify and older one.
From my understanding, it is
Though Kattni could say for sure.
I just made an update which should be slightly more... selective, in what it tests for library code
https://github.com/PyCQA/pylint/releases
Releases 8 hours, 3 days and then 8 days ago so my guess is that the last one broke us.
🧪 == Testing I've decided
The problem though, even if it is the latest that broke us, we'd have to touch every repo that gets updated between now and [insert fixed date] to make builds succeed
That ran clean for me on my CircuitPython_Bloomsky library
So this change is just one that had been planned, but more accelerated
Hurry up and break stuff... the normal way things are done everywhere
That I know 😉
But yeah. I looked at the issue they were tying the seemingly related change to. So works on >=2 simultaneous jobs, but what about ==1?
I see what you did there types: [python] nice !
Let me know if you want me to try anything else.
I'll push to my library in GH too... I only tested locally
I can't take full credit for it, but yeah, I thought that was a clever way they had of specifying file types
If you've looked it over, tried it and are satisfied, I'm happy with it. Seems good on my end too, so will let Kattni be the one to decide whether this is sufficient and well, or if something more would be required.
Thank you so much for your time, help and feedback @idle wharf. So very much appreciated!
Happy to help. Thanks for figuring out the fix!
I just pulled the lasted main CP version and am trying to build for the pyportal and get this message
supervisor/port.c: In function 'port_idle_until_interrupt':
supervisor/port.c:560:10: error: implicit declaration of function 'tud_task_event_ready' [-Werror=implicit-function-declaration]
560 | if (!tud_task_event_ready() && !hold_interrupt) {
| ^~~~~~~~~~~~~~~~~~~~
supervisor/port.c:560:10: error: nested extern declaration of 'tud_task_event_ready' [-Werror=nested-externs]
Any ideas what is going on? I ran the git submodule sync and git submodule update --init to no avail.
When I saw that it was the tinyusb module I think that wasn't updated but not sure
I ran this and it seemed update a lot of tinyusb files.
git submodule update --init --recursive
I redid make clean and then built and it worked. Thanks Mark!
glad it worked. I'm pretty sure it was the recursive thing that fixed it for me too, just couldn't recall
Add --recursive to update command.
We actually have recommended not to do --recursive, because it drags in a lot of stuff to TinyUSB and some other submodules that aren't needed. I do not do --recursive myself and my builds work, so I think the original problem discussed in discord may have been due to something else.
@blissful pollen @mental nexus I did this to verify what is needed:
$ git clone https://github.com/adafruit/circuitpython
$ cd circuitpython/
$ git submodule update --init # note no --recursive
$ cd ports/atmel-samd/
$ make BOARD=pyportal clean # (unnecessary first time)
$ make BOARD=pyportal
and it built without error. So there was some other problem. If you didn't do a make clean in advance it's possible that might have caused a problem, but I'm not sure
This adds a new bitmaptools module to house any bitmap graphics manipulation tools. The first is a "rotozoom" function that provides rotation, scaling and clipping.
Ok, no problem. My builds were failing due to TinyUSB, so I had to make clean, then run the --recursive and then I could build properly. This was for the pyportal.
@kevin-tracy I forgot to ask, do you think you could write a test script for linalg.dot? We should have been able to catch this error earlier, and the fact that we didn't means that the test was not quite up to the task... In case you are interested, here is what you would need: https://github.com/v923z/micropython-ulab/#testing
@v923z I would be happy to! I'll add them sometime this week.
I'm having trouble finding the issue for the rpi pico uart, I just wanted to check if there was an update available yet?
@indigo pollen it is PR 4224 and it is still being worked on.
it looks like there are some successful tests with gps chips
thats exciting
thanks for working on this
I’m just doing some testing. Glad to be able to help that way.
I’m getting a Sphinx error error: Name 'bitmap' is not defined in my function definition string. This is for a new module that operates on bitmaps. Seems like it doesn’t recognize this bitmap data type. Is there a way to let Sphinx know about data types from other files? Or define bitmap as a type inside this file?
did you call midi read from your firmware application. The data is stored in midi fifo and need to be retrieved else it will be full and prevent further data transfer. It is mentioned in the hathach/tinyusb#618 discussion
@tulip sleet interesting MP work for asyncio ble: https://github.com/jimmo/micropython-lib/tree/lib-aioble/aioble
@marble hornet @lone axle I ran some tests on the LC709203F and reproduced the issue with nrf52840 boards https://github.com/adafruit/Adafruit_CircuitPython_LC709203F/issues/3 I'm not sure where to go from here. Let me know if you have any suggestions or if you see anything helpful in the information posted.
@tulip sleet Just an observation -- I have been having a lot of Linux box (Ubuntu 20.04) crashes lately when disconnecting CP boards from the USB. It "seems" like the nRF52840 is particularly bad but that may just be because I have been working with them. It has been failing frequently with them. So much that I've moved back to using my Raspberry Pi instead (slow but steady...) I have not seen the same issue on the RPi.
@solar whale Same here, for me especially the ESP32S2 boards will freeze my Ubuntu. at the beginning I thought it was only me with my USB ports used and abused, but glad to know that I am not the only one having this problem
Another Thing, Dahn the instructions a little different from the guide, it is just in this particular case for Kmatch or this apply across the board for all builds? normally I used the instructions in the learning guide that are slightly different.
@still zephyr I have had the same problem with ESP32S2 boards. You are not alone!
@solar whale thanks for all the testing support with pico uart... seems like I pushed the wrong version upstream... would like to give it another shot before I push again
@analog bridge sure. It’ll be about 15 minutes before I can try it.
np... 🙂
@analog bridge its is "better" but still not working -- I get characters, but they don't make sense. Something loks to be getting overrun ```Adafruit CircuitPython 6.0.0-alpha.3-2124-gefe6aab5f-dirty on 2021-02-24; Raspberry Pi Pico with rp2040
import gps_echotest
5Q-ÍÅÑbb
bbbbbbbbbRH ÕEµ%)25)ÿ
ooopss -- nevermind.... its is OK -- forgot to connect the GPS....
I am getting data grom the GPS now -- still trying to see if I am missing anything ... give me a few more minutes
@analog bridge Yay! got a fix and it all seems to be working !!!
Sorry about the False Alarm
nice! I'll rebase and push now... thanks! 👍
You are welcome Thank you!
These two standard modules implement exactly the same API.
None of the boards in https://circuitpython.readthedocs.io/en/latest/shared-bindings/support_matrix.html has both of them. If ever there appears a board that needs both, AudioOut constructor can select the implementation appropriate for the passed pin.
Thus, renaming audiopwmio to audioio, and PWMAudioOut to AudioOut, will not cause any conflicts, and will allow for more portable CircuitPython code, avoiding hacks such...
Discussed in discord # circuitpython, but for the record, this works on a fresh clone, without --recursive:
$ git clone https://github.com/adafruit/circuitpython
$ cd circuitpython/
$ git submodule update --init # note no --recursive
$ cd ports/atmel-samd/
$ make BOARD=pyportal clean # (unnecessary first time)
$ make BOARD=pyportal
the --recursive is not necessary in general. I don't know what state @mental nexus's repo was in that made that sequence of commadns work, but I don't believe it is inherently due to the --recursive. See the PR comment above. It may have been a missing make clean at some stage, but that's just a guess.
audioio might be more properly called audiodacio. This is an interesting idea, if we are willing to hide the implementation under the covers. Another example of such a thing is generic touchio vs chip-specific touchio: we don't provide both, and we hid the choice in compilation options.
@tannewt @ladyada what do you think about hiding whether DAC or PWM is used, and leaving it up to the build flags to pick?
This covers the Tiny 2040, Keybow 2040, and PicoSystem.
I have tested these locally as instructed, but did not see a download .uf2 option as on Pico etc, nor a flag to make that appear.
Also, the instructions for what tags to include mentioned a list of ones to use, but did not actually give a list. Could you point me to the list so I can update the tags accordingly.
I find that the REPL is slow to start up on nRF52840 boards. I haven't looked into this yet. I don't know whether it's related in any way to the crash when unplugging.
I think I have been avoiding these crashes, at least in some cases, by making sure the filesystem is quiescent before unplugging or resetting. That is, there's been no file write within the past few seconds or I did a sync. I just got a new-used dev machine that's 6 years newer, and I'll see whether any crashes show up.
I have developed many schemes that seem to help for awhile -- then it comes back....
I'm getting more fond of my Raspberry Pi for board testing....
I had to change the variable type to displayio.Bitmap and then Sphinx was happy. It built fine on my local machine without this, but I had to modify it this way to build in the PR autobuild system on GitHub.
My tests thus far have been limited to transmitting MIDI. However I did update my test code to include a read but it made no difference.
@fossil gorge !!!
You deserve it! 😄
This is amazing, thank you
about to test it locally, but it looks great
Awesome! Hopefully it works locally as expected for you too. You probably saw their comment, but Askpatrickw tested it on a library repo succesfully
🤞
I did! Testing now. I need to make some errors first 😄
Finally! Every error I made was caught by Black at first, lol.
It works!
I'm so excited. Thank you so much!
@fossil gorge I'm impressed. Way to go!
I think we should remove bad-whitespace though. I'll comment on the PR. From Pylint 2.6 changelog: ```Other Changes
bad-continuation and bad-whitespace have been removed. black or another formatter can help you with this better than Pylint```
I imagine eventually it will return a "bad argument" failure with it included.
😆 Something like that!
Now I can close my 50-tab-rabbit-hole of a Firefox window from yesterday 😂
Number sounds about right!
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timingsare:
Brightness Before After Improvement
1.0 117 kpix/s 307 kpix/s 2.62x
0.07 117 kpix/s 273 kpix/s 2.33x
It's worth noting that even the "before" rate is fast compared to the time to transmit a single neopixel, but any time we can gain back in the whole pipeline will let marginal animations w...
@solar whale @analog bridge looking at these junk results with no device connected, I wonder if the UART should enable a pull-UP or pull-down on the RX pin
Could someone review https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/pull/65 ? Thanks!
agreed!
Thanks for adding. Could you adjust the Features list so that it matches only the items in the list available at this page: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads#header-3034486-5.
@tulip sleet I too was getting crashes with connecting/disconnecting MCU boards with Ubuntu 20.04 (Linux Mint 20). I changed to the 5.8 kernel and that fixed it
This was on a Dell XPS 15 9500 laptop
@slender iron should the following error be removed... it causes uart.read() to not function properly... the only other occurrence I found of this was on nrf where it is commented out
https://github.com/adafruit/circuitpython/blob/4cac412fac4353c94e684773948788576b99e879/ports/raspberrypi/common-hal/busio/UART.c#L208-L210
ya, I think it makes sense to remove
read should block while filling the given buffer
yes either that or timeout
iirc the timeout is reset when a new character is received
nice idea apart from this being not the standard approach with uart
I really want to see a workflow where pull and/or pin direction can be explicitly set from user code and an error is raised when it is conflicting with what a module is trying to do
yes
sounds like you are close!
ya almost done... need to update translations jerryn tested it with gps breakout and it is working now
great!
FYI _ I built CP with this PR and tested it with the GPS -- both the echotest and simpletest now work normally.
I see that atmel-samd does specifically disable any pull up/down on the RX line. I find that odd. ``` if (have_rx) {
gpio_set_pin_direction(rx->number, GPIO_DIRECTION_IN);
gpio_set_pin_pull_mode(rx->number, GPIO_PULL_OFF);
it seems like rx should be pulled up, to me
ya an external pull-up is what I usually see
@slender iron if that error is removed... won't that cause a continuous loop if ringbuf is full and we keep receiving bytes
ya, you need to copy out of the ringbuf in the loop
@meager fog Sorry to ping you but This comes up occasionally and I don't know if there is anyone else beside you who can address it. If you have a chance, can you look at this Forum discussion https://forums.adafruit.com/viewtopic.php?f=8&t=175885 regarding use of CE0 for SPI CS with Blinka.
ok...
use ringbuf_get_n in the loop and reset start_ticks every time you get more than 0 bytes out of the ringbuf
@onyx hinge @analog bridge to be fair, I got the noise when I had the GPS connected to TX/RX,/GND but power was disconnected. With everything disconnected, I am not getting any noise.
that makes sense... the wiring increases susceptibility to the noise
I feel like this is a FAQ but couldn't find a concrete answer, or glean from looking at code: can MicroPython ports be used out of the box with CP? With some effort? Or not possible due to reason x or y. Apologies if this has been overly answered...
@shell bolt generally no because the hardware apis are different
what port are you looking at?
Thanks. I have updated these now.
May I suggest including a link to that guide in the template.md. It was not obvious to me that the comment that said "this list" was referring to the options below, in part because I was expecting there to be more choices that would align with our products.
That's what I gleaned from the docs, makes sense.
Zephyr, though it is more of an intellectual exercise at the moment.
I think someone was just talking about maybe doing zephyr yesterday
mhelm has been doing a lot of the MP work for it
CP is more closely tied to tinyusb which might make it a bit more difficult
are you wanting it for a new platform?
@kevin-tracy Many thanks! @jepler Jeff, I hope that my appeal for testing doesn't qualify as hijacking the thread.
is the rtc module expected to be working on the RP2040 - pico now? it's there , but getting odd results
trying to use the gps_time_source.py example
@solar whale rtc was not being initialized properly, fixed in the uart PR... the fix is also in the uf2 I gave you earlier
hmmmm -- not working for me
Adafruit CircuitPython 6.2.0-beta.2-48-g4cac412fa-dirty on 2021-02-24; Raspberry Pi Pico with rp2040
>>>
>>> import gps_time_source
Set GPS as time source
Fix timestamp: 00/00/0 17:36:55
RTC timestamp: 00/32/1985 32:08:16
Local time: 00/00/0 17:36:55
Fix timestamp: 02/24/2021 17:36:56
RTC timestamp: 00/32/1985 32:08:16
Local time: 02/24/2021 17:36:56
Fix timestamp: 02/24/2021 17:36:57
RTC timestamp: 00/00/16 32:08:16
Local time: 02/24/2021 17:36:57
Not specifically a platform, but we're using a several IoT protocols and security features. It would be ideal to implement them in one place, and create CP libraries on top.
RTC timestamps are wrong.
@dhalbert I've already rebased it but thank you for your help. :)
I added 2 new commits that fix other USB problems on Spresense.
@dhalbert Thank you for your comments. I will make another push in a couple of days.
can you do a test with the following :-
import rtc
import time
r = rtc.RTC()
r.datetime = time.struct_time((2021, 2, 24, 15, 14, 15, 0, -1, -1))
while True:
print(r.datetime)
time.sleep(1)
Who knows Pulsein? Is it feasible or totally infeasible to make it work with pulses up to 800ms (instead of, what, up to 65ms now? are pulses in microseconds? it's not clear in the docs)
HW of the moment is samd51
this behavior was also a bit odd ... ```>>> p = pulseio.PulseIn(board.D5, maxlen=60)
p.popleft()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Input taking too long
p.popleft()
65535
p.popleft()
65535
p.popleft()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: pop from empty PulseIn
That'd be neat! I'm always happy to guide any work folks want to do.
Bitbangio I2C seems to go off the rails when it's trying to do a read. The writes look OK. Here are some Saleae screenshots. The clock pulses after the "Setup Read" are extra-long (9 us), and then something starts clocking SDA every clock cycle. I'm not sure if it's the RP2040 or the device.

By comparison, here is the same read when done from a Metro M4:

r.datetime = time.struct_time((2021, 2, 24, 15, 14, 15, 0, -1, -1))
while True:
... print(r.datetime)
... time.sleep(1)
...
...
...
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=18, tm_wday=2, tm_yday=55, tm_isdst=-1)
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=19, tm_wday=2, tm_yday=55, tm_isdst=-1)
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=20, tm_wday=2, tm_yday=55, tm_isdst=-1)
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=21, tm_wday=2, tm_yday=55, tm_isdst=-1)
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=22, tm_wday=2, tm_yday=55, tm_isdst=-1)
struct_time(tm_year=2021, tm_mon=2, tm_mday=24, tm_hour=15, tm_min=14, tm_sec=23, tm_wday=2, tm_yday=55, tm_isdst=-1)
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
KeyboardInterrupt:
it could be something to do with how we switch from digital output (to pull down the pin) to floating (to allow the resistor to pull up) to input (to read whether its pulled) thats the 'weirdest' part of i2c because we mimic an open drain bidirectional
Problem
I found when I use play_tone, I can only play so many separate tones. So I can play 500 as many times as I want, at any speed. But if then I play 490, then 480, and so on, eventually it stops working.
Explanation
The library uses simpleio.tone. It gives the error
Traceback (most recent call last):
File "", line 1, in
File "simpleio.py", line 65, in tone
NameError: name 'AudioOut' is not defined
eventually. This is caused by a ValueError, which...
perhaps the issue is with setting the time source ```print("Set GPS as time source")
rtc.set_time_source(gps)
yes earlier this was giving random results
Ah -- OK -- not a problem for me, just wanted to make sure it was a known issue.
I don't know why this is not working though
can you file an issue for this
sure -- thanks!
Division is clearer than a shift and should result in equivalent code.
self->post_brightness_buffer[i] = (self->pre_brightness_buffer[i] * self->scaled_brightness) / 256;
Thanks for the speed up! Just a couple small things.
Why is this added? I don't see it used anywhere.
@kamtom480 Looks like an API changed with the newer version and needs to be updated in CP.
Note we have a TinyUSB update in #4245
It should just work as long as the board ids (aka folder name) match between the two repos. Releases here produce a json file that is merged into circuitpython-org with availability info. So, these boards will have a concrete release artifact with the next beta.
The rtc.set_time_source() does not appear to be working properly on the RP204
Adafruit CircuitPython 6.2.0-beta.2-48-g4cac412fa-dirty on 2021-02-24; Raspberry Pi Pico with rp2040
>>>
>>> import gps_time_source
Set GPS as time source
Fix timestamp: 00/00/0 17:36:55
RTC timestamp: 00/32/1985 32:08:16
Local time: 00/00/0 17:36:55
Fix timestamp: 02/24/2021 17:36:56
RTC timestamp: 00/32/1985 32:08:16
Local time: 02/24/2021 17:36:56
Fix timestamp: 02/24/2021 17:36:57
RTC time...
just to clarify -- here is a clean start after a power cycle and with a good GPS fix
Adafruit CircuitPython 6.2.0-beta.2-48-g4cac412fa-dirty on 2021-02-24; Raspberry Pi Pico with rp2040
>>> import gps_time_source
Set GPS as time source
Fix timestamp: 02/24/2021 18:13:10
RTC timestamp: 00/00/16 32:08:16
Local time: 02/24/2021 18:13:10
Fix timestamp: 02/24/2021 18:13:11
RTC timestamp: 16/80/512 32:08:16
Local time: 02/24/2021 18:13:11
Fix timestamp: 02/24/2021 18:13:12
RTC tim...
I'd rather not hide the implementation because it has noticeable quality differences and impacts external design (adding an external filter for PWM audio). This is similar to bitbangio vs busio. It's better to be explicit.
It's important to note I2SOut is identical except for the constructor. Managing what audio form you want to output should be expected.
My preference would be to split touchio instead of modelling after it. I think it's more important for the native API to be clear tha...
right, the HID callback API is updated to support multiple instance of HID interfaces. They are all listed here https://github.com/hathach/tinyusb/pull/678 . Not all callbacks are used by circuitpython though.
I know this order makes sense here but in practice all required params should be first in the list here and above in the docs. They need to go before a *, which indicates where the kwarg-only parameters start in the function declaration.
One request around argument ordering but good otherwise. Thanks!
@slender iron I am pushing a couple more uart changes now... can you delay its review
Thanks for this! The logic looks good except for storing the object. It won't work with multiple counters running at once. Suggestions inline.
This won't work if you have multiple counters going at once. I think you want an array of size 8 (one for each slice) that can store each object. Then in the interrupt you'll need to check which slice wrapped and increment the corresponding counters count.
I wonder if it matters. The sorting is likely to coincide with a tilegrid moving and it'll cause a redraw of the area anyway.
I updated the HID callback API used by CircuitPython.
@slender iron or @onyx hinge - I am using an IRQ in my RP2040 pio program. All works fine; except that when I CRTL-C out of my script and then CTRL-D to reset; the interrupt handler is being called constantly. The deinit() function for the object is not getting called. Any thoughts?
@uncut nexus deinit isn't called automatically unless you allocate the object with a finalizer
usually the reset_* function deinits everything
I suspect that the object itself is going away; but the state machine program and interrupt are still going
ya, I had a similar problem with audio_dma
do we maybe need to add code to check for and clean up any state machines on a soft reset?
ya, I think so
OK, I'll look at that
or does state machine do it already
are you using pio through the state machine internals?
doesn't seem to - the SM is still running
using the rp2pio call to create the SM, nothing after that
I wonder if I fixed it in my PR
Is that in main? I may not have the latest merges.
OK, I'll see if putting that in helps. Thanks!
both i2s and pdm free run though...
there is this bug too: https://github.com/adafruit/circuitpython/issues/4237
@tulip sleet do you want to look at rotaryio or can I do the rp2040 impl
feel free to do it. I was going to revisit the algorithm to see why there's a dead spot. There's that PR about the dead spot but I need to look at it carefully.
I did the nrf impl, basically from first principles. Someone else did a similar one, I forget who (not you), and reworked that, though I wasn't sure it was as clear. It also has a dead spot.
I was thinking you could use PIO if you didn't want to do interrupts.
I think you could start with nrf and just change it for the port. It would have the same problem but it would work "as well".
i am still looking at gpio and DigitalInOut to see why bitbangio is not working right on the RP2040. I may try increasing the drive strength. I have tried a bunch of minor things
have to leave the house in one minute but I'll have my phone
np, I'm about to take a break and then mu meeting
@slender iron uart pr updated 
@fossil gorge https://github.com/adafruit/Adafruit_CircuitPython_TestRepo/runs/1973242093?check_suite_focus=true That's running remotely on a repo with two identical examples. Thank you so much again!
You're very welcome. Glad I could help out!
More "I'll read it laters" are lost on a daily basis to abandoned and orphaned tabs than ships have been lost to the Bermuda Triangle.
@fossil gorge Let me know when you're back around, I'd like you to take a look at the patch to make sure we didn't miss anything.
I am on a Pico, connected to pico demo that has PWM output on GP27 and GP28. I can make it beep one at a time, but when I try "stereo" the first "beep" is interrupted when the second start. I use the latest build "adafruit-circuitpython-raspberry_pi_pico-en_US-20210223-e41137c.uf2" and this kind of code: https://circuitpython.readthedocs.io/en/latest/shared-bindings/audiopwmio/index.html my test code is here: https://gist.github.com/dglaude/d20ebff34e225581f0c865690c603935
GP27/28 are left/right (or the opposite). What I mean is that it seems that I can only run one audiopwmio.PWMAudioOut at a time. I don't need stereo, I have never used audiopwmio.PWMAudioOut before. So maybe it is a bug and maybe it is a limitation.
I'm around and available now
Wonderful. Here is the patch PR: https://github.com/adafruit/adabot/pull/207
Looks right to me!
Thanks!
Just in case, I think it might be time to take that unplanned 48-72 internet & communication sabbatical!
So say we all 😆
Thanks for the review and for the feedback. I actually struggled with understanding how to use the MP_DEFINE_CONST_FUN_OBJ_KW. I pulled this out of Bitmap.c and into its own file, I went from use of my_bitmap.rotozoom(...) to rotozoom(my_bitmap,...).
But I struggled for a while since I forgot to update the mp_arg_parse_all to not subtract an argument!
I updated per your request and tested this with positional-style usage, and with parameter-name usage and both worked fine.
...
Tested using:
import board
import busio
import random
uart = busio.UART(board.GP0, None, baudrate=9600)
uart.write("|-".encode("UTF-8")) # Clear display
uart.write("Hello world! ".encode("UTF-8")) # Show some text.
uart.write("Rand: ".encode("UTF-8"))
rand = str(random.randint(0, 100))
uart.write(rand.encode("utf-8")) # So I can see that it's working every time, print a random number.
and a SparkFun Serial LCD. I can verify that it is...
Thank you for the improvements. Unfortunately, UART has a lot of corner cases. Let me know if you'd like to hand off the PR to me.
Why false? The FIFO will help buffer incoming data.
mod and division are usually easier to reason about than shifts and masks. I only use shifts and masks when bitpacking.
if (!(((pin->number % 4) == pin_type) && ((((pin->number + 4) / 8) % NUM_UARTS) == uart))) {
Use NUM_UARTS from here instead of the 2s: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/platform_defs.h#L21
for (num = 0; num < NUM_UARTS; num++) {
if (uart_status[num] == STATUS_FREE) {
break;
}
}
if (num == NUM_UARTS) {
mp_raise_RuntimeError(translate("All UART peripherals are in use"));
}
Thank you for your review, I will work on this further over the weekend.
@tulip sleet meeting time
Tested on 6.1.0 stable and 6.2.0-beta.2. I ran into this trying to write up a sound-reactive LED example for the BLM Badge. I distilled the code down to what's necessary to reproduce. It fails the same way on the Circuit Playground Express. This code works properly on Circuit Playground Bluefruit.
When the code runs, mic.record only records 32 samples, the rest of the 160 are 0. Below is an example. (All of the examples I can find of using sound to get levels uses 160 samples. That is wh...
@slender iron @onyx hinge ^^ I don't know what milestone to put it in. I'll leave that to your decision.
Is record returning the correct number of samples back to you? It will return less than what you give when it can't keep up with the data rate.
@tannewt It appears to be? Should I be using a different sample rate?
Implementation of pulsein for the RP2040 using PIO. This was tested using a DHT11 sensor and a Vishay Infrared receiver. Since pulseout is being deprecated soon in favor of PWM no attempt was made to implement it; just returning a NotImplementedError.
Some notes:
- The PIO frequency was chosen to sample the pulses at a rate that gets multiplied in the interrupt handler. This was done to decrease the amount of data transferred from the PIO to the CPU. I also attempted to return a count fro...
@onyx hinge 32 samples is all over the place for magnitude.
@slender iron Re: the issue I filed. If that's expected behavior, how do I deal with it?
Heading out. Will pick this up on Monday.
we can use this "mold" to add other symbols too, as far as I know. but otoh this is only covering one port, and looking at firmware.elf.map would at least cover all arm-based ports... I'm fine if we want to not do this right now either -- close if you prefer
I am going to test this with hardware.
#4251 has been merged so maybe that un-sticks this PR?
I think I would rather just scan the .map file, because then we can print out a useful error message instead having to rely on a link error. So I will close. But I do very much like the idea of catching inadvertent addition of chunky helper routines.
Here is what I just did in my volume demo:
while True:
count = pdm.record(s16, len(s16))
magnitude = normalized_rms(memoryview(s16)[:count])
diff = max(0, magnitude - 50)
led.duty_cycle = min(int(diff) * 256, 2 ** 16 - 1)
np.brightness = diff / 500
This was tested using Circuitpython 6.2.0-beta.2-141.... build using this PR. Test code was the simple code in the Adafruit Circuit Python DHT library https://github.com/adafruit/Adafruit_CircuitPython_DHT/blob/master/examples/dht_simpletest.py.
DHT11 and DHT22 temperature sensor were tested in the following GP pins
GP0
GP16
GP21
GP28
A total of 10 measures in each pin with an interval of 5 seconds in between.
There was no error raised during these test in either of the Temperatu...
#4251 includes the new init code. Sorry for blocking this!
Hope to get to it this weekend, shouldn't take long (once I figure out how to pull in that other PR to my branch)
Thanks, nice to have this implemented!. The implementation of this is related to the issue in the Adafruit_Circuit_Python DHT https://github.com/adafruit/Adafruit_CircuitPython_DHT/issues/61.
The original problem appears to be fixed, but accidentally while trying things from the REPL I found this. Notice that at first try I can't set the shared PWM to different frequencies, but if I deinit() one and then reinitialize it again with a different frequency. It does not complain. The actual frequency sent to both pins is the second frequency (200 in this case).
>>> import pwmio, board
>>> p0 = pwmio.PWMOut(board.GP0, frequency=2, duty_cycle=32768)
>>> p1 = pwmio.PWMOu...
@onyx hinge or @slender iron what does hosting circuitpython weekly involve? Beyond what we see as attendees😅.
@marble hornet the trickiest bit is recording I think. we do post the video to adafruit youtube too
before hand there is just grabbing stats and community news
qt py haxpress still doesn't fit. Could you change ports/atmel-samd/boards/qtpy_m0_haxpress/mpconfigboard.mk to:
USB_VID = 0x239A
USB_PID = 0x00CC
USB_PRODUCT = "QT Py M0 Haxpress"
USB_MANUFACTURER = "Adafruit Industries LLC"
CHIP_VARIANT = SAMD21E18A
CHIP_FAMILY = samd21
INTERNAL_FLASH_FILESYSTEM = 0
LONGINT_IMPL = MPZ
SPI_FLASH_FILESYSTEM = 1
EXTERNAL_FLASH_DEVICE_COUNT = 1
EXTERNAL_FLASH_DEVICES = GD25Q16C
CIRCUITPY_AUDIOBUSIO = 0
CIRCUITPY_BITBANGIO = 0
CIR...
Expanded pin names for TinyS2 and added some new ones for functionality I forgot to add pin names for.
Cleaned up mpconfigboard.
May I comment that displayio transparently supports displays of various colour depth (and therefore, noticeable quality differences) and underlying protocol (SPI / I2C / whatever), not requiring the programmer to be aware of the differences.
Also, managing what audio form to output is trivial when there's only one audio form available on any board: "you can choose any colour so long as it is black", so to say.
@slender iron Check speeling of the first "direction" in https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/rp2pio/StateMachine.c#L429
@slender iron A better wording would be "Out buffer elements must be max 4 bytes long"?
https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/bindings/rp2pio/StateMachine.c#L476
Still fighting with pico + pico demo that has an output jack on GP27+GP28.
dac0 = audiopwmio.PWMAudioOut(board.GP27, right_channel=board.GP28)
#code.py output:
#Traceback (most recent call last):
File "code.py", line 14, in <module>
#ValueError: Pins must share PWM slice
I have no clue what that "Pins must share PWM slice" mean... but that could explain that when I was firing a second output on GP27, the one on GP28 was stopping. You somehow cannot use both simultaneously (and that is unfortunate as this is what Pimoroni and/or Raspberry Pi foundation chosed.
I have been translating (or trying to translate) some of those into French. And my feeling was that it would not really help... If I was to receive my translation of the error message, what would I do? If it was in English, I could search the source to figure out where is that happening. But how does one "reverse translate" an error message back to the English, to then find where in CP code the problem is, to then maybe understand. Or how does you use the English version to "google" for help, or communicate with other likely using English version of CP?
the English version of the error can be obtained from the respective language.po file in locale directory
So you get an error in Language X, you find the PO file, then find the error message in English, and then you can find the place in the code where it is used.
My feeling was that maybe those message would not be clear, and the user will not see the link between what he did in his code and the error reported.
Maybe it is not supposed to occurs and it is some kind of sanity check, or maybe someone doing PIO will know imediatly what it mean (at least in English).
Another language question... maybe there are very similar error message that should be the same. And if they are the same in English, then they will have the same translation and save space everywhere.
#: ports/atmel-samd/common-hal/sdioio/SDCard.c
#: ports/cxd56/common-hal/sdioio/SDCard.c shared-module/sdcardio/SDCard.c
msgid "Buffer length must be a multiple of 512"
msgstr "La longueur de la mémoire tampon doit être un multiple de 512"
#: ports/stm/common-hal/sdioio/SDCard.c
msgid "Buffer must be a multiple of 512 bytes"
msgstr "La mémoire tampon doit être un multiple de 512"
For me "Buffer must be a multiple of 512 bytes" and "Buffer length must be a multiple of 512" could be the same.
There might be other like that, but not obvious to find. Could be in different port (and then it is not a saving).
Except a saving in translation effort.
ya I keep finding that kind similarity in error messages...
I think I know of an error where the meaning is same and the error is written in like 4 different forms
when I am writing an error I try to find a similar message but sometimes I just end up with message pairs like the following
"All UART peripherals in use"
"All UART peripherals are in use"
I am digging manually... and start to feel it need an AI to notice the "distance" between message and suggest them to human for review. 🙂
ooo... AI... that stuff is cool
Ok, maybe compression make this totally unsignificiant.
living on the edge every byte counts
To be efficient on this quest, maybe I need a list of the message for a specific port, and only with the module that are actually build in. If a board import ulab, then it has no space issue... Is there an easy way to generate a "short list" of all the english string for one specific fight for byte?
you can edit the included directories for strings in the makefile
https://github.com/adafruit/circuitpython/blob/main/Makefile#L43-L56
a subsequent make translate in the root directory will include only the strings from those directories
Is there a guide on updating the .github/workflows directory for a repo.
I'm trying to get a PR to pass CI [https://github.com/adafruit/Adafruit_CircuitPython_GPS/pull/57] and I think the recent updates to cookiecutter from @fossil gorge may be the cure [https://github.com/adafruit/cookiecutter-adafruit-circuitpython/pull/109]
To the best of my knowledge, there isn't. I believe that some of those files, such as the ones in .github/workflows/* along with .pylintrc, .pre-commit-config.yml and several others, should remain pretty much static, at least for libraries.
As far as updating those, I know that Kattni ([@]kattni) was working [@]dherrada to get the changes in that PR applied across the existing repositories. You can see that in PR #207 in the "adabot" repository here: https://github.com/adafruit/adabot/pull/207
While it is possible to apply that .patch file to a branch in a repository, even the main one, I don't know what effect that would have on the automated mechanism, since it might run into a merge conflict.
Also, just to say, that's just me talking from my understanding of the various processes at work. I would defer to someone more knowledgeable with the process and in a more "official" position to confirm before making any final decision.
we should 100% fix these strings to be consistent when we notice stuff like this. reducing the total number of distinct strings helps translators, even if it's not a savings of flash space because we never have two of these similar strings in the same build (but probably we have that too)
Cheers Hugo. I'll hold off for a while. I don't want to mess with config files if a mass update is likely to be coming.
Where can one grab the stats and news from?
just "for fun" I changed the gps code to continue as long as anything was in the UART and now both the gps_simpltest.py and gps_time_source.py examples work.
This is what I changed at https://github.com/adafruit/Adafruit_CircuitPython_GPS/blob/master/adafruit_gps.py#L200#if self.in_waiting < 32: if not self.in_waiting: return NoneNot a fix, but it's nice to see it running
As an aside the 32 is too large, new issue...
Looks absolutely fine. If you want to trim the voltage-monitor pin names, up to you, but we can merge as is.
The first priority is to have a name that's the same or similar to the silkscreen. We have been trying to use VOLTAGE_MONITOR for new boards.
It has passed all the tests. Thank you for your help!
Great! Thanks for persevering while we worked out the build issues.
I believe the reason I couldn't push changes to the PR is that your repo is forked from micropython/micropython, instead of adafruit/circuitpython. This seems to block "friendly" pushes even though you may have set the permission for them. I had the same trouble with @tannewt's fork. This doesn't need to be fixed, but it's worth explaining.
@marble hornet we have a 12 page internal document on the process. I think the biggest "deal" is that since the post-meeting items involve putting a video up on the Adafruit youtube account, the person doing that has to have the credentials to do that. Otherwise, there's stuff like getting OBS set up just so. As an aside, I'm not sure how important it is that the host ALSO be the one doing the video recording & uploading, but that's just the workflow as it's done today.
The source of the statistics is https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=adabot/bin/reports/ -- reports are generated daily which cover approximately 7 24-hour periods (a week to you and me)
PR please!
suggestion needed regarding the wording of an error message
on the pi pico, a pin can only interact with a specific uart instance...
the question is when the uart instance for the given pin is already in use what error message should I raise... currently I have the following implemented
static uint8_t get_free_uart(uint8_t num) {
// Check if the requested uart is free.
if (uart_status[num] == STATUS_FREE) {
return num;
}
// Raise different error message based on whether the other instance is free or not.
else if (uart_status[!num] == STATUS_FREE) {
mp_raise_RuntimeError(translate("UART peripheral is in use"));
}
else {
mp_raise_RuntimeError(translate("All UART peripherals are in use"));
}
}
Where did they choose 27 and 28? 26 and 27 share a pwm slice
When you find these, please make a PR to make them the same. We should share where we can.
I'd go with the version we already have
ok so just raise "All UART peripherals are in use"
You do realize I can't do PR's from inside of weblate? 🙂
I do. 🙂
do we have an issue for the duplicate-code check?
I just ran into it with two examples in a library
not a general issue, I think, just like https://github.com/adafruit/Adafruit_Blinka/pull/422
ya, I saw that
I should probably wait for kattni to be back. I know she thought about it already
Not 100% sure. "pico demo" implement the reference design: https://datasheets.raspberrypi.org/rp2040/hardware-design-with-rp2040.pdf
ah, they must use two slices. is there code for it?
26 and 27 should work
it's must easier to share a slice for stereo because you also share dma then
There was a PR to fix this in cookie cutter that I think was going to be applied to all the libraries at some point, but I don't know if there was an issue. https://github.com/adafruit/cookiecutter-adafruit-circuitpython/commit/0581192e3e12324c2fde5af2c44d138475475a5a
https://github.com/raspberrypi/pico-playground is where some demo code for that take place.
@slender iron I don't want to sound too stupid... but I have no clue what I am talking about. I looked at the silk screen, I tested the simpletest code or those in the documentation from CP and it as working mono on GP28. I searched further and it was working on the "other side" for GP27. Then I decided to try both simultaniously and it failed. Then I discover it is possible to specify left and right and it also failed.
But I don't know what a slice is. 🙂
is this CI failure a network glitch?
https://github.com/adafruit/circuitpython/runs/1981142249#step:7:192
Unfortunately, UART has a lot of corner cases. Let me know if you'd like to hand off the PR to me.
@tannewt Thanks! for the review. I have addressed the current set of suggestions.
If there is still a chance of improvement you can go ahead push directly to my branch. :)
@slender iron next I could to try I2S / PCM. Strangely enough it reuse the same pin 28 and 27 but also 26.
@slender iron have you successfully used the J-Link with the Pico? I have it wired up and it connects, but the stack traces are nonsense (usually only one level). Using V6.96 version of the J-Link sw
^ @onyx hinge you may also ahve tried
@tulip sleet I have not tried
I get good tracebacks (at least excluding interrupt handlers; they don't trace back into "where did the interrupt occur from") with picoprobe
i have not tried that - I'll look into it; thanks
needs yet some other different fork of openocd, as it seems like each and every different microcontroller does in the present day 😕
but it was no trouble to build on linux
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/t/tipa/tipa_1.3-20_all.deb 403 Forbidden [IP: 52.147.219.192 80]
yup, I'd say it's network
that failure seems similar to the following one... @tulip sleet added apt-get update to fix it
https://github.com/adafruit/circuitpython/runs/1537429786#step:7:113
ok maybe not... I'll try a re-run
So is Azure, a Microsoft property, saying that GitHub, another Microsoft property, isn't allowed to connect? 🤨
I am guessing it's a temporary capacity problem and that a 403 response isn't exactly .. correctly reflecting the circumstance. but who knows.
@onyx hinge it failed again with a new error https://github.com/adafruit/circuitpython/runs/1981342427#step:7:91
jlink flashing doesn't work afaik
so I load it with uf2 and debugged with jlink as normal
aha, that would explain it - tnx!
i guess they could hook into the bootloader, but that would be tricky
I assume they will eventually
they also have to handle the case of blank flash where they setup the ssi
that should work lrck and bck need to be consecutive
ooooh that's nice!
looks like their example may be mono after all
@onyx hinge I think their openocd knows how to flash
At least I can get sound on one side or the other... but not simultaneously.
Not that I need stereo, just testing the water.
a slice is a PWM portion that has two output channels that share a frequency (and duty cycle register)
Retrogaming can be mono, it is even better.
@thorny jay changing to pins 26 and 27 or 28 and 29 should work with stereo
the slice number is (pin_number / 2) % 8
Changing? It is hardware, a product: https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-base
🤦
you could ask pimoroni about it
two separate PWMAudioOut objects would work too
just not be as efficient
And they just copied the reference design from Raspberry Pi...
Is this two separated PWMAudioOut: https://gist.github.com/dglaude/d20ebff34e225581f0c865690c603935
That's what I did and when the second start... the first stop. Maybe I just make an issue?
I splitted everything to make sure there was no interaction I don't understand.
I played with WAVE file and I had the issue with the sound being bizarre from time to time when accessing the flash. And I was thinking... maybe I should put thing in memory and play from there. 🙂
ya, flash is pretty agressive in turning things off while it does its thing
its hard to get right when code is loaded from flash on demand
@slender iron about MicroPython V1.14 merge, the CI currently fails at build unix port...
I'll be making a draft PR in order to get reviews regarding what should be kept before I start adapting the rest of the codebase to the changes.
kk, a draft PR is a good way for us to provide feedback I think
did you run the style formatter over CP before starting the merge?
no... micropython had done this though since the last merge... so a lot changes are just formatting related
right, the merge will be easier if you start by formatting circuitpython the same way
then you don't need to do it by hand
You should be able to clear it faster than it is populated. (You are reading bytes at 125 mhz.)
I think we can always do that in the future for consistency...
I have already addressed all of the conflicts and mostly kept the circuitpython changes like long lived gc, kw args etc.
kk, ya. it'd be good for us to enforce the style with the 1.14 merge
Code to make sure PIOs and state machines are cleared out on a soft reset.
I don't recognize it but I suspect @ladyada is right. The open drain behavior of DigitalInOut may be wrong. I'd be surprised if the bitbangio code was wrong since its old and shared amongst ports.
May I comment that
displayiotransparently supports displays of various colour depth (and therefore, noticeable quality differences) and underlying protocol (SPI / I2C / whatever), not requiring the programmer to be aware of the differences.
You are right that board.DISPLAYIO does handle this for you. It doesn't for external displays though. So, I'd say if there is "built-in" audio output like a headphone jack, then we should have a board.HEADPHONES that is the appropriate audio ou...
This is on the Pico RP2040 (and using the pico demo board from Pimoroni, that board follow the reference design from Raspberry) and using 6.2.0-beta.2-137-ge41137c74
In the following code (just a copy of https://circuitpython.readthedocs.io/en/latest/shared-bindings/audiopwmio/index.html but with one sound on GP28 and one sound on GP27 for left and right channel), when after one second the sound start on GP27, it stop on GP28. And reverse way if you inverse GP27 and GP28.
So two indepen...
This seems to block "friendly" pushes even though you may have set the permission for them. I had the same trouble with @tannewt's fork. This doesn't need to be fixed, but it's worth explaining.
(If you want us to be able to push to your fork, then you could add us as collaborators.)
I did fix some things in DigitalInOut which fixed bitbangio. I am still trying to get bitbangio.I2C to be used internally in busio.I2C for short writes without glitches. I think I will submit the first fix as a separate PR so it doesn't get held up by the second.
@analog bridge are you still up?
I think UART just needs the fifo cleared too
I do wonder if you can infinite loop the interrupt still though
I can test and fix it this afternoon
I am creating draft PR for mpy now
ya... you can take on the uart... thanks!
👍 thank you!
Fixes #4221.
This fixes some glitches that occur when changing direction or state in DigitalInOut. It also turns on the strongest pin drive strength available (12ma) for DigitalInOut objects; the available strengths are 2ma, 4, 8ma, and 12ma.
The fixes for DigitalInOut mean that bitbangio.I2C now works properly. It can be used as a temporary workaround for some other issues issues with busio.I2C on the RP2040: #4024 and #4082.
Code looks good! CI is unhappy because we'll want to turn this off for SAMD21 and any builds without displayio.
I suspect you'll want to turn off BITMAP tools for all SAMD21 builds in the ports/atmel-samd version of this file even if they have displayio.
CIRCUITPY_BITMAPTOOLS ?= $(CIRCUITPY_FULL_BUILD) && $(CIRCUITPY_DISPLAYIO)
What is wrong with this? Shouldn't the output value be false but toggle output enable?
Since pulseout is being deprecated soon in favor of PWM no attempt was made to implement it; just returning a NotImplementedError.
PulseOut isn't being deprecated. The only deprecated thing is using pulseio.PWMOut rather than pwmio.PWMOut. Returning a NotImplementedError is fine though! DHT folks will be happy to have PulseIn.
(Will review the rest later after I run.) Thanks!
Suppose value is true. This will pull down the output temporarily, and then it will got back up on line 119/122.
Hey @dhalbert :) Yeah, I'm happy to have them all in there. I'm going to point people to he VBAT or VBAT_SENSE on my pinout cards, but having the ones Adafruit use will also mean those that don't check the card should be able to get it working from what they already know or from the learn guides.
This updates the blit function to provide clean blitting of a bitmap into itself.
Make unfortunately doesn't have boolean or arithmetic expressions, so you have to do this test in a more convoluted way, but you can use an existing test for CIRCUITPY_DISPLAYIO at line 158:
ifeq ($(CIRCUITPY_DISPLAYIO),1)
CIRCUITPY_BITMAPTOOLS ?= $(CIRCUITPY_FULL_BUILD)
CIRCUITPY_FRAMEBUFFERIO ?= $(CIRCUITPY_FULL_BUILD)
else
CIRCUITPY_BITMAPTOOLS ?= 0
CIRCUITPY_FRAMEBUFFERIO ?= 0
endif
CFLAGS += -DCIRCUITPY_BITMAPTOOLS=$(CIRCUITPY_BITMAPTOOLS)
CFLAGS += -DCIRCUITPY_FRAMEB...
Thanks for the comments. Dan, special thanks for pointing me in the right direction on the conditionals for AND of DISPLAYIO and BITMAPTOOLS.
I updated the configuration files for the other smaller builds that were failing to not include this module. I'll wait to see if all those builds pass before resolving this comment.
Hello,
I'm having the same issue on ESP32-S2 and nucleoG7.
with this simple code reset() returns always false:
import board from adafruit_onewire.bus import OneWireBus ow_bus = OneWireBus(board.XXX) print("Resetting bus...", end="") if ow_bus.reset(): print("OK.") else: print("Nothing found on bus.")
When i probe the bus (on nucleoG7), timing is not correct. According to [source](https://github.com/adafruit/circuitpython/blob/bbe0602738ae5c5d4bfc1cab4a515a82336c396b/...
The wrong stride value was being checked.
Thanks @DavePutz. A few comments to hopefully simplify the program and allow other things to run while capturing pulses.
Update this and any others please.
You can exec something before enabling so that the state machine doesn't race ahead. Please comment on what this instruction is.
I usually just inline the state machine object. Here is an example: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/audiobusio/I2SOut.h#L40
Why is this in board? This code should already reset everything: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/rp2pio/StateMachine.c#L94
In this implementation we don't set the value in set_value at all when in open drain mode. So, we need to set it to false somewhere. Otherwise you'll just toggle asserting high. (I think you can move this bit to after the set_value call below because it'll turn off output enable when value is high.)
Major improvements to Group are underway: https://github.com/adafruit/circuitpython/pull/4233
After those are implemented then I will revisit this issue.
Should be able to merge for the next beta.
Testing I2SOut on pico + "pico base" with 6.2.0-beta.2-154-gd4bf0d5e2
("pico base" use PCM5100A DAC for line out audio over I2S, just like in Raspberry Pi reverence design)
Playing "StreetChicken.wav" from flash on I2S, the file and code inspiration come from the learn guide: https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a/circuitpython-wiring-test
The sound is metalic (randomly, sometime it is good) and i2s.playing return False "randomly" long before the end of the s...
Ok, I fixed the mask we use to see if both channels are free. (It was incorrectly shifted by the channel.) The example code now correctly errors the second time.
Replacing
while i2s.playing:
pass
by `time.sleep(15)`
Make a much better sound (except the first play) and let you hear the full sound.
> Playing 10 times StreetChicken.wav
> Total lenght = 258.805 - 243.804 = 15.001
> Total lenght = 273.807 - 258.806 = 15.0011
> Total lenght = 288.809 - 273.808 = 15.001
> Total lenght = 303.811 - 288.81 = 15.001
> Total lenght = 318.813 - 303.812 = 15.001
> Total lenght = 333.815 - 318.814 = 15.001
> Total lenght ...
This give much better result (so replacing pass by a short sleep):
while i2s.playing:
time.sleep(0.01)
Still the first play can be too short and/or metallic.
Gotcha. Thanks for the fix!
OK, I've gone over this carefully, and tested with bitbangio.I2C. I think it's correct now.
common_hal_digitalio_digitalinout_set_drive_mode() is now identical to the atmel-samd implementation. The difference between the two implementations is that the atmel-samd impl infers the state of the pin in get_value() if it's open-drain by looking at the direction (so it doesn't need to actually set the value ever in that case). In the raspberrypi implementation, we always set the regi...
can ya remove
{ MP_ROM_QSTR(MP_QSTR_NEOPIXEL_POWER), MP_ROM_PTR(&pin_GPIO17) },
?
@dhalbert code modification has been done following your change requests. Thank you for your comments.
As for deep/light sleep selection, I have not substantially changed its implementation direction. I think we need further discussion for the better low-power design, while I need kind of working sleep implementation right now for my nRF board experiments.
anyone around and want to review a few fixes I made on the UART PR?
@analog bridge fyi, I pushed to your branch a few more fixes
Ok, I've fixed a couple more issues I spotted. If folks could test and review, that'd be awesome.
Ok after a couple of tries I got all of the mpconfigboard.mk files updated. All the builds pass, so I'm marking this as resolved.
I am designing a shield for the Metro m4 grand central and was testing a bunch of pins with the dht11 to make sure that all the pins will work with it as I cant connect it to another pin once the shield is made. So all the pins worked as expected (#D4-9 D11, D13-19 D22-45) except D31 just crashes circuit python for some reason, and it goes into safe mode. as soon at the dht11 is connected to pin31 it crashes, it works if it's not connected. the DHT is wired with 5v and then 10k pull up resist...
What was the error printed on the REPL when it crashed?
Found this quite quickly having wired up to test
Does such a Pico to Zero deserve a board definition in CP?
It has fixed mapping, is soldered and some pin have dedicated use like UART, I2C, SPI, ... and maybe the Pi Zero naming could be used. Something similar to what you would find on Blinka on a Pi Zero.
I think the main issue is the silk screen that is maybe confusing. ;-)
This is an issue for Raspberry Pi Pico implementation of CircuitPython.
trying to import board and initialize I2C. Get back:
AttributeError: 'module' object has no attribute 'I2C'
When trying to do a dir(board) get back:
>>> dir(board) ['__class__', 'A0', 'A1', 'A2', 'A3', 'GP0', 'GP1'...
This is with both the Adafruit CircuitPython 6.1.0-rc.1-51-gfb1e0106b on 2021-01-20 version as well as Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11 version.
There is not a "default" set of pins defined for I2C -- you will have to use busio to configure it
For example, if using GP0 for SDA and GP1 for SDL
i2c = busio.I2C(board.GP1, board.GP10)
I'm using physical pins 11 and 12 GP8 and GP9 I2C0.
I have tried
i2c = busio.I2C(board.GP8, board.GP9) and gotten "invalid pins" error
I'm simply trying to use the "standard" Adafruit displayio_sh1107_simpletest.py example file.
swap the order SCL is the first argument
i2c = busio.I2C(board.GP9, board.GP8)
That took care of the error.
Demo doesn't work yet, but that's my issue.
Thank you.
I think most of this will be handled in the new library https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout, so I’m closing this here.
Calling reset_rp2pio_statemachine() did not seem to clear the interrupt or
the
state machine program. When I used that and did the CTRL-C,CTRL-D sequence
I could see that the interrupt handler was still getting called.
On Thu, Feb 25, 2021 at 4:18 PM Scott Shawcroft notifications@github.com
wrote:
@tannewt requested changes on this pull request.
Why is this in board? This code should already reset everything:
https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/...
I tested by loading an adapted version of the fruit demo from https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/CircuitPython_RGBMatrix/fruit.py and causing heavy CIRCUITPY filesystem activity by running cat emoji.bmp{,,,} > bigmoji.bin; sync but didn't reproduce a crash.
I also re-tested entering and using the REPL and didn't encounter problems.
While writing to CIRCUITPY, the display will temporarily glitch. I believe this is because code can only execute f...
Used the excellent circup tool to upgrade libraries on my Feather M4 this morning (after UF2 3.13.0 and CP 6.1.0 updates). Very nice experience.
I was very pleasantly surprised to see the Wiznet5k WSGI server addition. Now I can stop reading Wiznet5k and ESP32 data sheets. Lol.
Ok, I've fixed a couple more issues I spotted. If folks could test and review, that'd be awesome.
Reran gsp_echotest and gps_simpletest -- both still work normally.
@v923z this might not be the right place to ask this question, but in writing tests I'm having an issue generating the .exp file for a new test. In the readme of the repo it says:
In case you have a new snippet, i.e., you have no expected results file, or if the results differ from those in the expected file, a new expected file will be generated in the root directory.
But when I do this for a new new_tests_2.py, I get the following error:
1 tests failed: new_tests_2
-e
FAI...
Hey ya'll! My name is Sruti and I just got referred to and joined in on this project. What would be a good place for me to start and familiarize myself with this?
We figured out why @ladyada and I were having ahem varying levels of success. Limor was testing the prototype Feather, while I was testing the pico. Feather has a status LED.
At the time everything goes south, GDB says...
#0 0x1006926c in _PM_swapbuffer_maybe ()
#1 0x10050986 in common_hal_rgbmatrix_rgbmatrix_refresh ()
#2 0x1004606e in rgbmatrix_rgbmatrix_swapbuffers ()
#3 0x1004e5b4 in _refresh_display ()
#4 0x1004eb04 in framebufferio_framebufferdisplay_background ()
...
Welcome: here's an overview: https://learn.adafruit.com/welcome-to-circuitpython/. What are you aspirations here?
Thank you this is great! I am really here to use my python knowledge for a useful project and learn and contribute as much as I can. But I'll probably have more specific interests once I dive into it.
hey, i'm putting together a list of displayio "helper" libraries. here's what i've got so far. any others?
Adafruit_CircuitPython_Display_Text
Adafruit_CircuitPython_Bitmap_Font
Adafruit_CircuitPython_Display_Shapes
Adafruit_CircuitPython_ProgressBar
Adafruit_CircuitPython_Display_Notification
Adafruit_CircuitPython_DisplayIO_Layout
@tulip sleet got time to chat? I have a problem I need to bounce off you
@tidal kiln Adafruit_CircuitPython_Display_Button
also Adafruit_CircuitPython_ImageLoad
@dense oasis Hello there as a new person myself I would recommend to review the page that sent you. Then have an overview of the core modules. Today there is a live stream at 2 PT (GMT -8) with Scott talking about the development. And tomorrow at 11 am (GMT -5) another with foamyguy the discuss some developments in the libraries
maybe Adafruit_Circuitpython_SlideShow I think of it as a displayio helper. But I could see it being judged as not really one.
@lone axle maybe display button?
Yep agree'd, mentioned that one.
Also you can take a look at the list of issues in the github repositories, and see what interests you.
@lone axle thanks. added all 3 of those.
@dense oasis A few other thoughts from another new person, since you said you want to use your Python knowledge you will likely be contributing to the libraries. You can see what needs work at CircuitPython.org https://circuitpython.org/contributing/open-issues. There is also an outstanding tutorial on the overall CircuitPython Git / GitHub workflow at https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/overview that has really helped me.
I don't think this will work for non-open_drain because in that case you never set direction.
2pm Pacific
(in 2.5 hours)
Two quick updates to the above comment:
- It looks like when a test script results in a different output than expected, it creates the appropriate .exp file in the root directory. However, when there is no expected output .exp file, it does not produce the appropriate .exp file in the root directory.
- It also looks as if the matrix-vector multiplication is still not working. I tried both with the testing tool on my computer as well as the most recent version on my board:
A...
Corrected thanks I was thinking my timezone🙃
Ok, I totally believe that. It seems to me that reset_rp2pio_statemachine should turn off interrupts as well instead of having a separate way to reset things.
Sorry! I'm hoping to get to this very soon! Hopefully today or Monday.
@kamtom480 By when would you like a beta release that includes these fixes? We are trying to finish off some significant RP2040 additions/fixes. If necessary, we could do two betas in quick succession.
@electric1236 Are you pulling up to 5v? The SAMD51 is NOT 5v tolerant so you should be using 3.3v.
Gah, I had my debug text files in there for a bit. re-did that last commit and the CI needs to run again.
on the tutorial, it says it should be fine (https://learn.adafruit.com/dht/dht-circuitpython-code). though I'll switch to pulling it up with 3.3v but power the dht11 with 5v. Though I don't think that why it crashed cause it worked fine with every other pin, though ill try it out.
@tannewt @dhalbert I added both of you as collaborators. :)
We had to shift everything by a month. We want to make sure everything works first. So you don't have to do two betas. Thank you for your help!
Are there any estimates when 6.2.0 will be released?
@slender iron the difference between the Arch arm gcc 10.2.0 and the official ARM release 10.2.1 is the software math library, which is substantially smaller on the Arch side:
00000132 __aeabi_f2d | 00000144 __aeabi_f2d
00000060 __aeabi_f2iz | 00000064 __aeabi_f2iz
00000046 __aeabi_f2uiz | 00000048 __aeabi_f2uiz
00000716 __aeabi_fadd | 00000828 __aeabi_fadd
00000040 __aeabi_fcmpun | 00000042 __aeabi_fcmpun
00000460 __aeabi_fdiv | 00000560 __aeabi_fdiv
00000484 __aeabi_fmul | 00000588 __aeabi_fmul
00000728 __aeabi_fsub | 00000860 __aeabi_fsub
00000128 __aeabi_i2f | 00000156 __aeabi_i2f
00000018 __aeabi_idivmod | 00000008 __aeabi_idivmod
00000024 __aeabi_llsl | 00000090 __aeabi_lmul
00000024 __aeabi_llsr | 00000132 __aeabi_ui2f
00000072 __aeabi_lmul <
00000116 __aeabi_ui2f <
00000018 __aeabi_uidivmod | 00000008 __aeabi_uidivmod
00000024 __ashldi3 <
00000146 __divsi3 | 00000460 __divsi3
00000074 __eqsf2 | 00000076 __eqsf2
00000046 __fixunssfsi | 00000048 __fixunssfsi
00000124 __gesf2 | 00000140 __gesf2
00000124 __gtsf2 | 00000140 __gtsf2
00000124 __lesf2 | 00000134 __lesf2
00000024 __lshrdi3 | 00000134 __ltsf2
00000124 __ltsf2 <
00000072 __muldi3 | 00000090 __muldi3
00000074 __nesf2 | 00000076 __nesf2
00000222 __udivmoddi4 | 00000406 __udivmoddi4
00000120 __udivsi3 | 00000266 __udivsi3
arch is left side. Also I'm not sure why some routines are not even present; I'm guessing they have been compiled inline
this is very interesting, and I wonder if these are written in C or assembler. If the former perhaps they were compiled with more optimization (or less! maybe arch is -Os instead of -O2 or -O3 for those libs). Otherwise perhaps there are at least two versions to choose form.
the numbers above are sizes in bytes
interesting!
I don't think this will work for non-open_drain because in that case you never set direction.
You're right, I needed to look at the whole thing. Now direction gets set at the right time.
Tested: bitbangio.I2C still works, and I tested simple DigitalInOut with normal drive (not open-drain) on some LEDs and it's working right when switching from input to output and back again.
Got my relay working with rest api in Wiznet5k thanks to the wsgi example. Happy dance.
Now I need photo diodes to sense which led is active on the USB switch.
Pico users: have you seen your REPL connections spontaneously close after a few minutes? I am seeing this on Linux.
And then write it up as a proper demo for Show and Tell.
I have not seen it on windows and have had it idle for quite a while - not sure exactly how long but more then a few minutes
Wow I cannot type today. Sorry edited it a few times, but I have seen no problems on Windows 🙂
Measured time in the interrupt handler for a burst from a DHT11 was 3.69 millis. If you think that is too long I can look at interrupting on a per-word basis.
I changed the pindirs op to be exec-ed; but the wait on the pin to go low needs to be there for every reset of a pulse burst. So, I think it best to leave it in the SM program.
I should explain the rationale behind the frequency and delay choices. Since pulsein wants to know the length of pulses (in microseconds), and since I couldn't get PIO to count properly, I am sampling every 4 us or so, and pushing those bits into a 32-bit word. Not trying to get every bit, just enough of a sampling so that in the interrupt handler a calculation can be done to give the desired result. In this case, I am multiplying the counted bits for a pulse by 6. The result is typically wit...
I just downloaded latest and greatest adafruit-circuitpython-raspberry_pi_pico-en_US-20210226-2e6e91d.uf2 - the good news is this fixes a PWM issue, the bad news is CIRCUITPY no longer appears. Is that a known issue on Pi Pico?
I tested adafruit-circuitpython-raspberry_pi_pico-en_US-20210226-2e6e91d.uf2 and this looks good wrt this PWMOut issue.
That version doesn't present CIRCUITPY though. I went back to adafruit-circuitpython-raspberry_pi_pico-en_US-20210215-2a467f1.uf2 and CIRCUITPY reappeared. I'm sure it's not related to this and I've just mentioned it in discord in case it's not an intentional interim state.
I get no CIRCUITPY on absolute latest
I got another hung backtrace, again using the feather uf2 but not obviously related to neopixel:
#0 0x10069088 in _PM_row_handler (core=0x20000994 <displays+20>)
at ../../lib/protomatter/src/core.c:534
#1 0x10069238 in _PM_PWM_ISR () at ../../lib/protomatter/src/arch/rp2040.h:148
#2 <signal handler called>
#3 0x10068698 in _PM_init (core=core@entry=0x20000994 <displays+20>,
bitWidth=bitWidth@entry=64, bitDepth=bitDepth@entry=4 '\004',
rgbCount=<optimized out>, rg...
I don't see that normally, but I have found that Linux's USB ports can get stuck to a useless state with these errors and a reboot is necessary. Try that.
I've been using REPL a fair but and haven't noticed anything unusual from Windows. I've had it briefly plugged into a Raspberry Pi 4 for MicroPython fiddling but I've spent most of my time fiddling with PWM and PIO code.
I just tried the 2e6 build and it's showing CIRCUITPY for me
ah you say it's on Windows, I will try that
@simple pulsar well, 2e6 is showing CIRCUITPY for me on Windows as well.
Interesting, I'll reboot later and see if that fixes it. It comes back for me when I go back to an older uf2.
there were some TinyUSB fixes, but maybe there was a regression. See if it happens on the RPi 4 as well, maybe.
Changed wording to use "max" instead
No, no error was printed, it just froze then I rebooted it and it said it crashed hard and it was in safe mode and to report it to here
Yikes! Found two off-by-one errors in my last commit on Bitmap.blit.
Lesson: Do way more testing prior to next PR request.
I was just testing it again with the 3.3v, when i powered it with 5v but had a 3.3v pull up on the data pin it still had the problem, but when it powered with 3.3v and has a 3.3v pull up it works fine.
also sorry I forgot occasionally it did output an error message "Checksum did not validate. Try again." before crashing when it crashed I heard the noise that it disconnected from my computer and then reconnected.
when it rebooted it says, it also sometimes said something different and to...
@yugesh-recursive did you ever figure out what this was? I'm running into the same error with a different sensor.
@paulmand3l What sensor are you having trouble with? This kind of error can be due to I2C protocol issues. I am trying to track down a similar error on a different board.
Garmin LIDAR-Lite V4. Here's my forum post about it: https://forums.adafruit.com/viewtopic.php?f=57&t=176040
Pico users: have you seen your REPL connections spontaneously close after a few minutes? I am seeing this on Linux.
After I posted the query above I tried some things. I just started using a new USB hub, and after switching to a different one, the problem has gone away. So this does not appear to be a CPy problem. Thanks for the comments.
I answered in the forum post.
This issue is relevant to animations in widgets for the https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout, this is primarily to bitmap redraws, often with a fill followed by a blit`. In this process we need to a flash on the screen that will occur if an auto_refresh triggers between the fill and blit.
I’ve been defaulting to passing in the display so that the widget can toggle the display.auto_refresh to pause (False) and then batch changes (when set to True). The...
Danh, I will test that, I come back to you if I find something.
Foolishly, was trying to save a file to the internal storage of the Raspberry Pi Pico.
Upon running the following code:
import io
f = io.FileIO("/file.txt", "w+")
f.write("bye flash\n")
f.close()
I get this message:

Translation:
- USB Device not recognized
- The last USB device you've connected to your computer hasn't worked properly and W...
This PR merges in upstream MicroPython changes till release V1.14.
Notes :-
mpy-crossbuilds successfully.CIcurrently fails atbuid unix port.- I am doing a draft PR to get the changes reviewed before adapting the rest of the codebase to it.
Changes :-
- Upstream ran a code formatting script... so a lot of the changes are formatting related.
We can r...
Thank you for starting to work on this! The last time I did it was #1068, in 2018.
I would really like to understand the changes rather than just depend on automatic merging. To that end, I think it would be good to make some of the changes that MicroPython has made, by hand, first, so minimize the diffs.
For instance:
- Code formatting: If we reformat the code in advance according to the same style rules, that will greatly reduce the number of changes.
- Some macros were renamed or m...
Interim notes:
I am seeing this same NACK issue that the Saleae screenshots above show. I have a fix for bitbangio.I2C for #4221, and for busio short writes for #4202. When I use bitbangio.I2C for the TCS34725, the sensor works properly. The Saleae traces for bitbangio vs busio do not seem to show any notable differences, but, still, the busio traces show a NACK, and the bitbangio ones show an ACK for a simple write. It may be due to my fix for #4202 not being exactly right yet,but...
I just grabbed the new uf2 with the uart fix for the pico, running a uart bluetooth dongle connected to the pico - bluetooth connection from my phone - sending commands controlling a pwm esc driving a motor and the pico driving a 180 degree servo. The uart is working flawlessly for my purpose.
thank you all who worked to get this in I appreciate you all
Hello! I'd like to contribute a en-uk translation for circuit python! I tried to start via the weblate system, and I got an error saying en-gb wasn't a valid option? When I went back to grab the exact error I was logged out for too much activity. I may also have requested a new translation in a random language, sorry!
The hardware reference design for the Pico/RP2040 ( https://datasheets.raspberrypi.org/rp2040/hardware-design-with-rp2040.pdf ) has a board in chapter 3 with both analogue PWM and digital I2S.
So hiding the difference between the two technology might not help there.
I have a really simple script to interact with a random RGB strip i got. the strip is common anode but it shouldn't matter.
Basically i initialize a regular power pin, and 3 PWM ones (for R,G,B); I leave the power pin turned on and play with the 3 PWM channels, reversing the duty cycle values (2^16 is completely off and 0 completely on).
Problem is, only 2 channels work at a time, the third's duty cycle doesn't update. i tried in the REPL and 2 channels always works completely fine, but w...
While looking into the "pretending to deep sleep" issue, I found that wake-up from deep sleep (pretended) is not properly detected. I am trying to fix it..
I can see CIRCUITPY drive from Raspberry Pi 4 but not from Windows. I have two Pi Picos, it turns out CIRCUITPY is ok on a "naked" Pi Pico but not on the Cytron Maker Pi Pico for adafruit-circuitpython-raspberry_pi_pico-en_US-20210226-2e6e91d.uf2 - I'll grab latest again, try that and log this as an issue
This sounds like #4210 - try "absolute latest" version of CircuitPython for the recent fix.
I have been using adafruit-circuitpython-raspberry_pi_pico-en_US-20210215-2a467f1.uf2 successfully for sometime now but I upgraded to a more recent version to test out a PWM fix. I noticed this made CIRCUITPY disappear on a Windows 8.1 desktop. Further investigation shows this problem appears to be unique to the Cytron Maker Pi Pico, the bare Pi Pico board does not suffer from this. A Raspberry Pi 4 running their standard os can see the CIRCUITPY drive.
I've tested both `adafruit-cir...
I've been having a lot of fun and success with the Maker Pi Pico but ran into this strange issue with CIRCUITPY disappearing yesterday #4282
For the problematic combination I also note that device manager shows a pair of CircuitPython MIDI devices when just the Maker Pi Pico is plugged in. One is ok and one has the yellow problem triangle. The yellow triangle one says:
This device cannot start. (Code 10)
The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect.
Both have USB PID of 80F4. In Information under Properties / Events it references them as:
GOOD: `...
It looks like this broke builds with CIRCUITPY_USB_MSC = 0:
ld: firmware.elf.lto.o: in function `usb_background':
<artificial>:(.text.usb_background+0xd2): undefined reference to `usb_msc_umount'
ld: <artificial>:(.text.usb_background+0x2ca): undefined reference to `usb_msc_mount'
ld: firmware.elf.lto.o: in function `storage_remount':
<artificial>:(.text.storage_remount+0x3c): undefined reference to `usb_msc_ejected'
ld: firmware.elf.lto.o:(.rodata._usbd_driver+0x18): undefin...
This can be worked around by always adding lib/tinyusb/src/class/msc/msc_device.c and supervisor/shared/usb/usb_msc_flash.c to the supervisor.mk.
I looks like we should set CFG_TUD_MSC to 0 for tinyusb when CIRCUITPY_USB_MSC is 0.
If you figure this out in general way a PR would be welcome. Thanks! I did not test all the possibilities.
@tannewt this is a bit confusing, neither the old pins nor the new ones match what is in the PCB repo https://github.com/adafruit/Adafruit-Feather-RP2040-PCB:

D13 should be GPIO14 to match the github version, is it changed to GPIO13 in the production rev or is this a bug?
Avoid undefined functions when MSC is disabled.
This is very odd. I looked at the Cytron board, and though I don't see a schematic, it just appears to add a bunch of stuff to various pins. The USB is untouched.
Try detaching all the Picos and cleaning out the USB devices with the Device Cleanup tool https://www.uwe-sieber.de/misc_tools_e.html. Windows may be confused.
Another thing to do is to erase flash completely: https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython/circuitpython#flash-resetting-uf2-3083...
Thank you!! I will merge when builds finish.
@kevinjwalters I tried with both version of circuitpython you mentioned on my Maker Pi Pico and they work just fine on Windows 10. Perhaps you may try out the methods as suggested by @dhalbert and see how it goes.
Thanks.
@kevin-tracy Sorry, I didn't spell this out, but anything written on micropython-ulab is for micropython.
But more importantly, the fix is in a still-open PR, https://github.com/v923z/micropython-ulab/pull/339, so Jeff hasn't yet pulled in the changes, because the PR is still not resolved. Hence, loading an adafruit-compiled piece of firmware is not going to make the cut here.
What you can do, however, is simply clone https://github.com/v923z/micropython-ulab/, switch to the `legac...
@waiweng83 Thanks, I'll give them a go and report back.
This was tested with the following code in a MagTag using CircuitPython 6.1.0
import displayio
import terminalio
font = terminalio.FONT
glyph= font.get_glyph(ord('A'))
letter = displayio.TileGrid(glyph.bitmap, pixel_shader=displayio.Palette(1), default_tile=glyph.tile_index, tile_width=glyph.width, tile_height=glyph.height)
letter.transpose_xy = True
This works fine in a wioterminal
This is the same as Fluff M0, but disables the MSC, CDC and MIDI USB
endpoints. This is useful for devices like keyboards or mice running
CircuitPython, once we are happy with their code and don't want to
change it anymore.
I'm adding this board mostly so that we have a test for this case.
Could you try this with 6.2.0-beta.2?
@tulip sleet you can see it live now in the stream 🙂
not a bug, final production file is different than pre-release schematic we distributed to help folks out with RP2040 designs
When I run the command brew list gcc-arm-embedded it returns this error:
Error: No such keg: /usr/local/Cellar/gcc-arm-embedded
I tested this on:
Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; Adafruit MagTag with ESP32S2
I'm not getting safe mode, but the device does "hard" crash and reboot.
Tested on
Adafruit CircuitPython 6.1.0 on 2021-01-21; Adafruit Metro ESP32S2 with ESP32S2
-- hard crash and reboot.
Is there a list of/are the defines you can use for boards documented anywhere (like SUPEROPT_VM for example)?
See py/mpconfig.h and py/circuitpy_mpconfig.mk and .h
I am getting a hard crash and a subsequent reset into safe-mode with the following setup :-
Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; microS2 with ESP32S2
I ran a backtrace and here are the results :-
/home/mdev/code/circuitpython/ports/esp32s2/../../shared-module/displayio/TileGrid.c:111
/home/mdev/code/circuitpython/ports/esp32s2/../../shared-module/displayio/TileGrid.c:307
/home/mdev/code/circuitpython/ports/esp32s2/../../shared-bindings/displayio/TileGrid....
Aditional comments
For 6.1.0 goes to safe mode
Adafruit CircuitPython 6.1.0 on 2021-01-21; Adafruit MagTag with ESP32S2
>>> import test_transpose
[tio 12:42:33] Disconnected
[tio 12:42:36] Connected
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode: something unanticipated happened.
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
...
Great! Winows can do odd things when it detects device errors. It has some heuristics about which drivers to install when based on previous errors but I do not find them obvious.
@dhalbert Thanks! for the suggestions.
Code formatting: If we reformat the code in advance according to the same style rules...
I ran the same script (i.e. tools/codeformat.py) on the whole CPY codebase.
I had to modify it a bit as I got an IndexError. That reduced about 150 files from the diff.
I can make a PR for it... I think I should wait for the open PRs to come down a bit before doing that.
...
Thanks! everyone for collaborating on this. 👍
OK, thanks. I guess it's just following the trail then.
Ok, I'll make a custom build then :)
I was wondering, is there any general guidance or best practices when writing CP? Particularly for libraries and examples?
I figure for examples, the simple the better. But I was thinking about code structure, such as using intermediate variables, number of method calls, nested statements and conditions, etc?
Hello! I'd like to contribute a en-uk translation for circuit python! I tried to start via the weblate system, and I got an error saying 'Select a valid choice. en_GB is not one of the available choices. This list includes only basic languages. Please contact project maintainers for adding another one.' I may also have requested a new translation in a random language, sorry! So should I make a github issue or can someone just add en-uk to a list please? kudos to all CP folks btw, I'm hoping this will be the first but not last contribution...
I would also find this very helpful. In general, when beginning, I'd rather have a highly opinionated system and just learn how to use it, then gather better wisdom and confidence to carve my own path later on...
@tidal kestrel could you create an issue? Thanks.
Does it happen when you set the width, height, tile_width and tile_height explicitly to constant numbers?
I think I see the problem:
https://github.com/adafruit/circuitpython/blob/main/shared-module/displayio/TileGrid.c#L107
The width variable is defined as int16_t but the self->pixel_width it is getting assigned to is uint16_t.
Dear sir, madam and personages who prefer otherwise
I humbly request the opportunity to make a modest contribution to the magnificence that is circuit python.
As you can doubtless divine, I am fluent in British English and feel compelled, nay impelled, to forward my services.
If you would be so kind as to add the Queen's English to the list of possible languages, I can then begin the task of translation.
I remain, your most obedient servant
I have gamepad causing a hard crash on soft reboot on ESP32S2, but also I noticed that on 6.1.0 it falls into safe mode after the reset (making recovering easier), which 6.2 doesn't, should I make a separate issue for that ?
Does it happen when you set the width, height, tile_width and tile_height explicitly to constant numbers?
Yes, this code will produce crash and restart.
import displayio
import terminalio
font = terminalio.FONT
glyph= font.get_glyph(ord('A'))
letter = displayio.TileGrid(glyph.bitmap, pixel_shader=displayio.Palette(1), default_tile=33, tile_width=6, tile_height=14)
letter.transpose_xy = True
also I believe that has been mentioned before but the drive mounting on macOS causes a code reload, making it a crash loop
Can you try #4287 and see if it fixes it?
The following codeon a UM Feather S2 causes a crash (loss of USB and reset) on soft reboot, like by saving a file, with latest (and drops into safe mode on 6.1.0, which is better in terms of recoverability).
import board
import gamepad
from digitalio import DigitalInOut, Pull
button1 = DigitalInOut(board.IO7)
pad = gamepad.GamePad(
button1,
)
Tested on a Lilygo TTGO too.
Seems similar to #4166, but different port, slightly different symptoms.
@powersoft are you happy that the explanation / solution given closes this issue?
Is this separate issue still valuable alongside #4280?
Possibly related to #3693.
As for the "pretending to deep sleep" issue, when alarm.exit_and_deep_sleep_until_alarms() is called in .py,
(1) configure pins & interrupt in common_hal_alarm_set_deep_sleep_alarms()
(2) raise DeepSleepRequest exception and exit from .py execution
(3) do cleanup_after_vm()
(4) check port_idle_until_interrupt(), and if pin event found, soft reboot.
While in (3), pin settings are reset, and deep sleep event (pretended) cannot be detected afterwards.
What should we do ?
idea (A): skip...
This could be somehow related to the long-lived object handling. The gampead singleton is created as a long-lived object, maybe it's not getting reset properly? I can't see anything immediately obvious in the code, though.
I tried this out on a magtag:
Adafruit CircuitPython 6.2.0-beta.2-183-g2a3cd5b29-dirty on 2021-02-27; Adafruit MagTag with ESP32S2
I'm still getting the hard crash and reset from this code:
font = terminalio.FONT
glyph= font.get_glyph(ord('A'))
letter = displayio.TileGrid(glyph.bitmap, pixel_shader=displayio.Palette(1), default_tile=glyph.tile_index, tile_width=glyph.width, tile_height=glyph.height)
letter.transpose_xy = True
This is a fine clean-up fix but I don't think it will solve #4284, because the width and height are pretty small integers, and they'll fit in either a signed or unsigned 16-bit int.
I tried too
Adafruit CircuitPython 6.2.0-beta.2-84-g79b122675-dirty on 2021-02-27; Adafruit MagTag with ESP32S2
with the following code
import displayio
import terminalio
font = terminalio.FONT
glyph= font.get_glyph(ord('A'))
letter = displayio.TileGrid(glyph.bitmap, pixel_shader=displayio.Palette(1), default_tile=33, tile_width=6, tile_height=14)
letter.transpose_xy = True
I chose my idea (B) and pushed the latest code. I tested the following combinations on my nRF52840 board and the results look OK.
- USB host connected (pretending to deep sleep) / disconnected
- deep sleep / light sleep
- trigger pin high / low, and timed-wait (for light sleep)
Now I can go into REPL by Ctrl-C while pretending-to-deep-sleep wait, and soft-reboot by terminating the REPL session.
One important modification which might affect other ports is replacement of port_idle_unti...
I suspect that in the case of a font bitmap, one of the dimensions is actually quite large, and that's causing problems.
I would like to the code review to be started again since I have done a series of modifications and commits.
Here is a revised implementation notes.
README_impl_r2.txt
@fossil gorge and @tidal kestrel the closest thing to that I am aware of is this design guide: https://circuitpython.readthedocs.io/en/latest/docs/design_guide.html I'm not sure if it covers those specific details that you asked about though.
Now I can go into REPL by Ctrl-C while pretending-to-deep-sleep wait, and soft-reboot by terminating the REPL session.
One important modification which might affect other ports is replacement of port_idle_until_interrupt() call with alarm_pretending_deep_sleep() in run_code_py().
Thanks for working on this: see #4010, where ctrl-C does not interrupt a simulated deep sleep.
Thanks for all this work, and addressing the review questions. I have two more questions related to TimeAlarm deep sleep.
I have looked over the code have these questions before noting small corrections (only one or two):
-
You thought that
TimeAlarmwas not possible if the chip was in System OFF state because you said the RTC would be shut down? Is that actually not true, or doesTimeAlarmstill not work with deep sleep? Could you just stay in System ON if necessary? -
You are...
thanks @lone axle that's a nice and well written guide, if there are specific things missing you can identify @Hugo perhaps we can raise issue at next deep dive?
Sorry for the false comments in my original post, which would be in your email. Instead, look at the comments here.
This is nicely cleaned up. I think TimeAlarm can be simplified to use mp_hal_delay_ms() in light sleep, and to use a prescaled RTC with System ON in deep sleep. Are those things you think would be easily doable, or do you want to pass that on to someone else? If the latter, I think we might disable TimeAlarm for now until it's completely implemented.
Thank you very m...
"Cannot wake on pin edge. Only level." -> "Can wake only on pin level, not edge"
RTC_DATA_ATTR is a specific ESP32-S2 macro. Its RTC has a special small area of RAM associated with the RTC peripheral. So maybe call this UNINITIALIZED or SLEEP_MEMORY instead, since it's not associated with the RTC on the nrf.
Instead of setting up the interrupt here, which is limited to 512 seconds, you can just remember how long you need to sleep. Then, actually do a mp_hal_delay_ms() or the equivalent in common_hal_alarm_light_sleep_until_alarms(). More comments there.
idea (B): do pin reset in cleanup_after_vm(), and call a re-configure function before "pretending to deep sleep" wait loop
I agree with this choice; looks like the right thing to do, which was not necessary in the ESP32-S2 implementation, but is necessary in other cases like nRF.
@onyx hinge I had some ideas about speeding up multiple translation builds, but I don't know enough about how it works to see if they make sense. Do you have some time for an audio or video chat about this now or later?
@tulip sleet I'm in Amelia. I'm at a different computer than usual so I dunno if audio will be wonky
#define TRANSLATION(id, firstbyte, ...) if (strcmp(original, id) == 0) { static const compressed_string_t v = { .data = firstbyte, .tail = { __VA_ARGS__ } }; return &v; } else
make clean; make V=2; make TRANSLATION=fr V=2
jepler@rat:/tmp$ gcc -c -flto b.c
jepler@rat:/tmp$ gcc -c -flto -o ab.o a.o b.o
gcc: warning: a.o: linker input file unused because linking not done
gcc: warning: b.o: linker input file unused because linking not done
ld: a.o: plugin needed to handle lto object
ld: b.o: plugin needed to handle lto object
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
jepler@rat:/tmp$ arm-none-eabi-gcc -O3 -c b.c
jepler@rat:/tmp$ arm-none-eabi-gcc -Wl,-r -flto -O3 -o ab.o a.c b.c
/opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: warning: incremental linking of LTO and non-LTO objects; using -flinker-output=nolto-rel which will bypass whole program optimization
jepler@rat:/tmp$ arm-none-eabi-gcc -O3 -flto -c a.c
jepler@rat:/tmp$ arm-none-eabi-gcc -r -flto -O3 -o ab.o a.c b.c
Contents of section .gnu.lto_fn.e092362af6141212:
arm-none-eabi-gcc -flinker-output=nolto-rel -O3 -r -o ab.o a.o b.o
Is there a HW debug tool that does work for both debugging and flashing the QSPI flash. I just got my first Pico on Friday and am still waiting for DigiKey and Element14 to ship the ones I ordered from them. I've got a few things here that I can try (Olimex, Bus Pirate, Amstart, Jlink and JLink mini) but I'd rather find just use something that I know works. Is the flash programming part of the Debug tool or is it in OpenOCD? The Jlink can be used with the Segger firmware and also with openOCD (I think they are different but I'm not sure).
I've got a Raspberry Pi I can use. Is that working to debug and flash? If so, is there a way to use VSCode with that on my desktop with OCD listening on my RPI?
git log |grep -i czech
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 149M 100 149M 0 0 25.1M 0 0:00:05 0:00:05 --:--:-- 31.8M
8312c4c91799885f222f663fc81f9a31 -
jepler@rat:/tmp$ curl https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 | md5sum -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 149M 100 149M 0 0 5305k 0 0:00:28 0:00:28 --:--:-- 6182k
8312c4c91799885f222f663fc81f9a31 -
arm-none-eabi-gcc (Arch Repository) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
[for those wondering what in the world, all this is related to a chat we're having in Amelia about build sizes and times]
Hello
I want to get the I2S bus working. I found an example [(https://learn.adafruit.com/adafruit-max98357-i2s-class-d-mono-amp/circuitpython-wiring-test)] were I try but there is an error: ImportError: no module named 'audiobusio'
How can I fix it? I used the CircuitPython version 6.0.1
Thanks for your help.
The M0 (SAMD21) builds don't have enough room for audiobusio and several other modules, sorry. The list of which modules are included with which boards is here: https://circuitpython.readthedocs.io/en/latest/shared-bindings/support_matrix.html
@slender iron @onyx hinge and I are fairly certain that the libgcc.a for your 10.2.0 Arch arm-none-eabi-gcc was built with -Os, and the ARM 10.2.1 build was built with -O2, hence the size difference for _aeabi_fadd etc. So we could keep a different libgcc.a in our back pocket if we really needed the space.
It looks like the MagTag is using the default SPI pins (GPIO36 for SCK and GPIO35 for MOSI) for the E-ink display. In order to use SPI for some other device you might need to use busio.SPI instead of board.SPI.
?serverinfo
Summary of the project discussion at Friday's Deep Dive video https://youtu.be/Vlxf8FRtV30?t=6418 for others following along this issue:
- Long term goal of
pythonwrites a singlebuild.ninjafile andninjabuilds everything. Usually when we build a particular board, there is a heirarchical graph ofMakefiles that is used to build that specific case. What we instead want is a singlebuild.ninjafile that builds all of the boards at once and share information between boards...
Maybe it would make sense to move the default SPI to other pins.
@dhalbert Thank you for your comments. I have just looked into mp_hal_delay_ms(), and found light sleep can be implemented with it, removing the 512 sec limitation. I will try.
deep sleep can also be implemented by System ON & pre-scaled RTC, then, there will be very little difference between both sleep modes. Is that OK ?
Why does the MagTag even have a board.SPI ? What physical pins is that for ?
Is it to address the display directly ? Does it matter with board.DISPLAY being there ?
I have just looked into mp_hal_delay_ms(), and found light sleep can be implemented with it, removing the 512 sec limitation. I will try.
deep sleep can also be implemented by System ON & pre-scaled RTC, then, there will be very little difference between both sleep modes. Is that OK ?
Sounds good! Yes, that's fine. It's still the case that light sleep returns and deep sleep doesn't. We want both to be available on all the boards so we can have cross-platform code.
It's mainly a code portability thing. I should think the singleton shouldn't error.
This is all I can think of: https://circuitpython.readthedocs.io/en/latest/docs/design_guide.html
I used the rpi direct with their custom openocd to do it when needed
I only really need it when things get really hairy though
Thanks. I'm just getting set up with my Pico and am trying to make sure I've got everything covered. Once I get more than one board (the rest are coming from Digikey) I'll prob use a 2nd board for debug.
@onyx hinge usually sets up the newer translations
Go ahead and open an issue about this. @onyx hinge and I just talked about translations this morning. He revised the info on weblate about new translations, and I edited the standing open issue: https://github.com/adafruit/circuitpython/issues/1098
so, I noticed that, since 6.1 apparently, boards don't show the yellow status LED and wait for the safe mode reset press
testing on a QT PY I met 2 issues
- the reset reason seems to be
UNKNOWNwhen pressing reset (which exits early fromwait_for_safe_mode_reset) - even commenting that out the status LED does not light up during
wait_for_safe_mode_reset(but it does reset into safe mode)
Add the headless board to tools/ci_check_duplicate_usb_vid_pid.py; it's complaining right now that the two Fluff boards have the same PID.
Could you open an issue? Thanks!
yes, I'm looking into it a bit to get an idea of the scope of the problem
This only appears to be supported on the ESP32-S2. Unclear if it's stable enough to port or not.
Seems like the nRF52 would be at least as good of a candidate for low-powering as the ESP32-S2.
Also seems like there'd be a benefit to prioritizing it over the RP2040 if one had to choose between them in the near term.
++tkx
There is already a PR for nRF52 alarm implementation. #4236
I think this GitHub feature would be nice to have.
We can also create different templates for bug report, feature request etc.
Doing some reading of the W25Q128JV datasheet was curious if there was a reason the W25Q128JVSIM isn't supported but the W25Q128JVSIQ is? or just because is hasn't been added for support yet (iirc not every flash chip is able to work)?
referenced datasheet: https://www.winbond.com/resource-files/w25q128jv revf 03272018 plus.pdf
common_hal_mcu_processor_get_reset_reason is only implemented on ESP32S2, it returns UNKNOWN for every other port. An unintended consequence is that, because of the following code addition, these boards don't implement the normal yellow status LED to wait for the reset button and reboot in safe mode. Making safe mode impossible to reach.
>>> import micro...
how can i tell how many people actually use chinese pinyin?
i might stop translating if im only one, just tell me there are more then 1 download in past few months
renders improperly because it's missing the required whitespace. Should be .. note::
Sorry @upbeat plover I don't know, but I would like to encourage you to continue! I believe strongly you are helping many more than 1!
@tannewt I can't make today's weekly meeting, but am interested in the next steps of ideas for milestones, a minimum viable product, and to pencil in dates for myself to meet those goals; I'm a fan of setting weekly goals with a few weeks sprinkled in as buffer. I feel like I have enough background now to work independently on some of these things, but in the call you mentioned maybe working on some of this during your week on Adafruit time so I thought it would make sense to coordinate more...
@upbeat plover I have the download log data. In January 2021 there were 1976 downloads of a pinyin build. By comparison there were 46490 downloads of an en_US build, downloads of de_DE, 2030 of fr, etc.
So a question is, how many of these downloads are real, and not some automated fetching? Little-used or empty translations show about 1300 downloads each, so it appears to me there were 700 downloads of pinyin over and above the noise downloads
this is across all boards
I am just doing a count like this: egrep '"GET.*pinyin-' 2021-01 |wc on the AWS S3 concatenated logs
@onyx hinge I had a light-bulb moment 💡 on the issue of how to convert translate("some message") into an integer or an address. Instead of the huge if tree that gets optimized down, we can define a macro in each file that has translations. All it does is return a uniquized line-number that is a symbol name denoting the location.
#define translate(s) PREFIX_FOR_THIS_FILE ## _
##__LINE__
So each call to translate() generates just a name. The prefix would be something like shared__bindings__busio__I2C_, say, for that source file. So if line 345 is
mp_raise_valueError(translate("Invalid pin"));
gets converted into
mp_raise_valueError(shared__bindings__busio__I2C345)
A previous scanning step has scanned all the source files looking for translate( calls. It remembers them all, including the line numbers, deduplicates them, and converts the strings into compressed data. There's an integer (say) that represents that string, either an index into the the data of compressed strings, or, as as we discussed, an index into a table of indices. It produces a file to be included that is something like :
const uint16_t shared__bindings__busio__I2C_345 = 123;
const uint16_t shared__bindings__busio__I2C_677 = 543;
...
These could even be #ifdef-guarded to save time if we asked that each file with translations also define the prefix:
#define shared__bindings__busio__I2C
#define translate(s) shared__bindings__busio__I2C ## _
##__LINE__
Alternatively to integers, the definitions could be symbol names that get resolved by the linker, as we discussed.
The only restriction is that there be no more than one translate() per line.
Ideally the prefix would automatically be based on the filename. But __FILE__ has non-symbol-name characters int it, like / and ., and the cpp doesn't have enough functionality to substitute that stuff.
Return the correct value in the range 0 to 65535 for Analog In.
@tulip sleet Interesting. It seems to require no more than one translate() call per physical line.
Here are some other things I thought about:
- the decompression routine itself can either be configured to use
uint8_toruint16_tfor some types, depending on whether the language includes values beyond unicode code-point 255 or not - the specific range of values used to name n-gram dictionary values differs, iirc it always starts at 128 but either stops at the first "used" character value in the 160..255 range or for 16-bit alphabets that don't use 160..255 can extend beyond that but to some other limit. So the decompressor code varies depending on the language.
it seems like there was something else that was complicating but I can't recall right now.
const uint16_t shared__bindings__busio__I2C_345 = 123 this ensures that two translate() calls with the same literal can share the storage of the translation, right?
I am writing this up in an issue (should have done that first). Your comments there would be valuable.
Yes, all the, say, "Invalid pin" messages would share the same number. Also those const defs could be #defines too, I realized, when writing this up.
I don't know that it makes a big difference, but it could.
the main brainwave is that __LINE__ together with some prefix unique to the file gets you a unique name which you can use at compile time, once, across all translations.
QSTR's could be converted to something similar too, though that's not necessary right away.
Looks fine, no testing performed.
Fix how many off by one errors? :grin:
I didn't test it, but the changes make sense intuitively.
Currently our builds are a Cartesian product of boards * translations. We save time on the translation builds by starting with a previous build, so that only files with translation strings need to be recompiled. This saves a lot of time, but I think we could save more.
A small build like trinket_m0 takes an additional 14-15 seconds for each translation. A large build like metro_m4_express takes about 40 seconds for each.
Right now the translate() call is a true function call. It c...
Good question, whats the right function to use for counting off-by-one errors (can I pick the last one?)
- 1+1+1+1
- 2*1^2
- 1^4
It seems to require no more than one translate() call per physical line.
Yes, that's a very minor restrction.
(forgot to answer this earlier)
sometimes these things can happen from macro expansion and surprise everyone
the translation preprocessor can flag such occurrences
if(x < 0) ... translate("x is too small"); else if(x > 100) ... translate("x is too big")```
so yeah just want to mention it, had it happen to me, still have the scars
the translation preprocessor would need to do macro expansions if we put translate() calls inside cpp macros
actually, I guess it would need to do that anyway due to #if CIRCUITPY... which would remove/insert lines with translate() calls.
so it would operate on cpp -E output, and pay attention to # line directives
wouldn't it be easier to do something similar to how qstr work, and name the macros after the contents of the string?
I thought about using qstr syntax for all messages: that is certainly possible, but harder to read. I was trying to preserve the current message-as-key method
Cautionary note: each build+translation needs its own compressed string table, because there are shared dictionaries among all the strings that depend on the exact strings chosen for the build. So something like this wins if the cost of doing the translation preprocessing is substantially less than recompiling on each build.
It turned out it is not easy to exit mp_hal_delay_ms() waiting loop at pin interrupt, and I think modifying the function a lot would not be welcomed, so I introduced another (similar) waiting loop which can handle pin and rtc interrupt. Looks to work fine so far with deep / light sleep, and native / pretending combinations. I will test further for a couple of days before git push..
I have four cap-touch buttons. One increases LED brightness, the next decreases it, the next cycles through a rainbow of colors. What should I make the fourth one do?
Close #4293 by changing ..note:: to .. note::.
As for the Ctrl-C in pretending-to-deep-sleep issue, it looks mp_hal_is_interrupted() cannot detect Ctrl-C outside python execution vm. So I decided to check it by serial_bytes_available() in the loop. It is just like Ctrl-C check in run_code_py().
Eh?
(as opposed to one-step-per-press)
Hmm
No I mean the third one only does once
you have to keep holding on it to cycle the whole rainbow
so what if pressing #4 for however long does a complete rainbow cycle, making it different from #3 which cycles as long as it's held?
if there's more than one LED, can it cycle which LED you're changing?
or just stop the whole thing until you press it again?
It doesn't do anything when you're not touching 1-3
so "stopping" isn't necessary
Or you mean
i thought it was running continuously - my mistake. So it could be a toggle to do 1-3 either continuously or just once
I kind of like it as an enable/disable. Because it's easy to touch the other buttons when handling it
so you could get it where you want it and force it to stop there
until you touch 4 again perhaps?
yes, toggle
@tulip sleet I wonder if it would be somehow possible to generate qstr-like names from strings with a macro
not really familiar with the C preprocessor in such detail
cpp has almost no functions; make has many more. It's fairly terrible. Basically is it just a string substituter, with a few features for concatenation and variable number of arugments
or maybe we could add our own preprocessor somehow?
then we have to compile the transformed source; that might confuse the debugger in terms of filenames (unless we can simulate the original filename). I was hoping to avoid that
If gcc had a an escape to run an arbitrary preprocessor over the input, that would be great, but i don't see that
one more idea, can we use consecutive numbers per file, instead of line numbers?
Using "#line" directives is traditionally the way to deal with such transformations -- a challenge to get right, however. https://en.cppreference.com/w/cpp/preprocessor/line
i think we can't use consecutive numbers without using some weird recursive metaprogramming trick. The advantage of the line numbers is that any program looking at the source knows the line number; it doesn't have to be computed by counting
sounds good then
as I have thought about this more since this morning, there is more and more the translation preprocessor has to do. I am a bit worried its responsibilities may be too great or there will be an insurmountable stumbling block. But I like the original trick enough to keep thinking about it.
@tulip sleet is anything about making release notes automatable?
I do not want to. The summaries of each thing require thought. I looked at this and the PR titles were often not clear and needed to be re-written. It doesn't take a long time, given how many changes there are.
the contributors and the download counts is already semi-autoamted
@ionic elk please add the adc note to https://learn.adafruit.com/adafruit-metro-esp32-s2/esp32-s2-bugs-and-limitations too -- I think this page is mirrored across several guides
@onyx hinge here is the rotaryio work I've started: https://github.com/tannewt/circuitpython/tree/rp2040_rotaryio
<@&356864093652516868> Meeting coming up in 15-ish minutes, sorry for the late notice. Notes doc: https://docs.google.com/document/d/1u7_1iSfVo1LGNRU6WGSMYAr9Dp6VvEqK8UMHlco8oVA/edit?usp=sharing
Remember, if you will speak or have notes to read, get them in the doc. If you're just listening in, no need to do anything in the doc or in the text channel. Scott is hosting today.
CircuitPython Weekly for March 1, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate, ad...
Good afternoon all you wonderful folks 🙂
😀 I'm looking forward to catching up with everyone!
I'm also going to take a back-up recording today to see if I can resolve my volume level troubles
brb.
The CircuitPython subreddit on Reddit.com crossed the 2,000 members mark! Thank you to our Reddit readers for choosing to get your Python fix on our subreddit. Adafruit is dedicated to providing yo…
We are excited to share the results of the fourth official Python Developers Survey conducted by the Python Software Foundation with the hel...
Check previous PRs if you're unsure how to submit to the newsletter! And we're happy help.
MakerMelissa is totally not a robot 🤖 😉
some of my best friends are robots
some of my best robots are friends

Low power, high thought.
@onyx hinge what is mystery board blog
@ionic elk https://www.bunniestudios.com/blog/?p=6062
I don't know what it is but it's soooo pretty
yes, very colorful. My JLC stuff is all just black silver and green.
@slender iron stream on thursday, did you say?
yup!
Thermal camera will love that... I have 32x24 pixels out of MLX...
Playing random Xmas #RTTTL "music" on a @Raspberry_Pi #Pico plugged on the "pico demo" from @Raspberry_Pi just with a few lines of #CircuitPython and the @adafruit RTTTL library:
https://t.co/xD2KF9BjGx
RTTTL Xmas song list;
https://t.co/4lg7GejRAg
I am ready for Xmas 2021... https://t.co/PnynRykYZv
I am pretty sure someone did work on a firmware updater, but I don't remember the name/url
KeyBow-mini from @pimoroni
controlled from a @Raspberry_Pi Pico running #CircuitPython.
Magic come from the Red Robotics "Pico to Zero adaptor" that I found on @tindie: https://t.co/KydLlGk2rW
I have many pHAT that I plan to use that way.
Source code: https://t.co/AZsARAEuUG
yep, will link after my turn.
@lone axle I will take you up on that. I'll let you know.
@thorny jay https://github.com/bcr/blinka-cli this tool allows upgrading firmware from a command line interface.
(as well as some other useful utilities)
Thanks. I knew it existed! Just could not find the name.
-10100001-000101001-000000110-000000010-001000010-000100000-
2021-03-01 19:51:00 dstinfo=0
-> 2021-03-01 13:51:00-06:00
One full minute of WWVB signal, the decoded version in UTC (GMT) time, and then translated into Central time...
@solar whale huh
I remember having some issues with the GPS way back last year but that's weird
it's a hard lock for me when it happens
5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
fwiw
@slender iron has a very good PC with very good USB ports...
my pc has a "Win7" sticker on the side to give a rough age of hw 🙂
lspci can usually show the usb root hub
$ lspci | grep USB
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
mine is an old -- mac-mini..
probably intel as well
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
I've seen similar lock-ups on my AMD system with Debian ```02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller (rev 01)
0b:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
yes
haven't lately with kernel 5.4.0-0.bpo.2-amd64, knock on wood
also of note - can happen with arduino and no CP firmware on board
tinyusb core or arduino usb core?
(so maybe bootloader?)
I'm not sure if it helps narrow anything down any but fwiw I have never had this happen (knock on wood also) on my linux box. It's Pop_OS! which is built on top of Ubuntu if I understand correct.y
❯ lspci | grep USB
00:14.0 USB controller: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller
I have not seen it with Arduino (don't use it much) or with Micropython..... yet
@mental nexus We have a test repo available if you need something to hack on remotely in situ. Regarding the Sphinx exploration. You'll need to add some code and doc content, but basically it's there to do whatever is needed.
@slender iron would "read bitmap from file" go in this module @mental nexus is talking about?
I keep starting but then stopping the implementation, it would probably speed font loading even more though
I'd do a separate bmp one
I want use the inheritance-diagram feature on Sphinx, it requires graphviz to run, will need to see if that’s available. Can your sample sphinx library allow to explore that?
Arrrrrrrr you sure about removing en_Pirate?
@mental nexus Ooh, I have no idea! Depending on what goes into it, we can make changes to the test repo.
Ok, point me there and I’ll check it out.
Is there a Weblate option to be notified when new translations are needed for a given language?
We essentially included the pirate translation in the first place so folks who may only know English were able to contribute to translations and the core. It was a community thing.
test as you fly, fly as you test....
I need to step away for a few.
graphviz should be available. it's an oldie but goodie
Perhaps you discussed this idea while I wasn't listening, but if each adapting-board has a file that defines its mapping, you can import adafruit_picozero_board as board
Thanks Dan, I’ll submit something and see if it survives the gauntlet of black/pylint/Sphinx.
and then the only change is to import redrobitics_picozero_board as board if you use the other product, etc.
we do probably need to install graphviz; it may not be there by default
ok, it's not:
$ dot
Command 'dot' not found, but can be installed with:
sudo apt install graphviz
this is on a recently installed ubuntu system
Will I need to update one of the library files to be sure it gets installed before my run?
we need to change the github actions .yml file
it's another package that will need to be installed
looks like right now all the library packages are pip3. But this is non-Python package that will need to be installed with apt
the standard libraries build.yml doesn't actually do any apt installs right now
It's just 2 weeks until the US change to Daylight Saving ("Summer") time, be aware this shifts the meeting time by 1 hour if your locality follows a different rule.
Ok will take a try at it based on your comments. Thanks for the warning about apt vs pip
Thanks
See you, all!👋
Thanks everybody!
Thanks.
I'll write up the manual merge instructions this evening and have that over to you @idle owl
Thanks!
👋
Thanks everybody
@mental nexus there are apt installs in the circuitpython build.yml: https://github.com/adafruit/circuitpython/blob/main/.github/workflows/build.yml#L36
apt-get is older, apt should work fine
doesn't matter
I've been trying the latest build the last several days and the symptom now is the application not running ("locked up").
OK, looks like my recording levels (of other people) came out much better this week, hopefully I can recreate the magic next week when it's time for me to run the meeting for reals.
@onyx hinge I'm going to try to remember to run a "backup" recording during the meetings as well. I did the first one today and it seemed to go okay. So in the future we may have an extra chance in the event of anything going weird.
I noticed that by carefully sizing my discord window, I can exclude the "server list" from the recorded area in obs but still fill the whole video area. Recorders might be interested in this if they feel other servers they belong to are "private" and don't belong in the recording.
you could record your mic and the discord to different channels and fix the balance afterwards if needed
That is a good tip. I did realize part way through that I was resizing the window and clicking into other chats to look at something =x so I'll also have to try to get better about getting it set and leaving it alone.
yeah you have to not do that stuff during a video that'll actually be used!
"oh what did my wife DM me on discord -> NOPE, you can't look for 90 minutes, hope it's not important" 😀
(have discord on your phone 😉 )
yeah
Yeah, I'm going to have to look into a way to get a second instance running or something
maybe it will let me do one application instance, and one browser instance.
I have also wanted to have a recording instance separate from the instance I use, so that I can mute my mic in discord and have it muted in the final stream as well.
as the host
Discord in a browser window for the channel?
Here is the notes document for Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1Y9ornOqrwr6Mh6jEFjHN5tEXtb61Kwlf0WupEpcvkao/edit?usp=sharing
CircuitPython Weekly for March 8th, 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,...
@tulip sleet should this be removed, or should it stay for now? ```python
# Normally different language builds are all done based on the same set of compiled sources.
# But sometimes a particular language needs to be built from scratch, if, for instance,
# CFLAGS_INLINE_LIMIT is set for a particular language to make it fit.
clean_build_check_result = subprocess.run(
"make -C ../ports/{port} TRANSLATION={language} BOARD={board} check-release-needs-clean-build -j {cores} | fgrep 'RELEASE_NEEDS_CLEAN_BUILD = 1'".format(
port = board_info["port"], language=language, board=board, cores=cores),
shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
clean_build = clean_build_check_result.returncode == 0
there are still a few boards that need it; it's used to turn off terminalio for ko and another translation that doesn't have a good font
I think there are one or two third-party boards that are still using it that could probably be cleaned up, but I wasn't sure what to remove for those if it didn't work, so I didn't pursue them
The initial allow-list removes the following language builds:
- Hindi and Greek with zero messages translated
- Czech with 3% and no recent translation activity
- Korean with 7% translated and no recent translation activity
@tannewt will be writing up guidelines about what constitutes a minimum translation that we will package up, and we will potentially re-evaluate the translations built based on those criteria. The guidelines will also help translators so that they know what messa...
@ladyada I re-tested the slot machine demo from Adafruit_Learning_System_Guides/CircuitPython_RGBMatrix using the Feather RP2040 build and my Pico pinout on a Pico, but with R and B pin swapped to trigger the bug I was able to reproduce.
During the testing process, I ten times hit ctrl-c, ctrl-d to re-load the program, and caused filesystem activity with cat emoji.bmp{,,,} > large.bin; sync; rm large.bin; sync also 10 times with 5-second sleeps between. (of course, large.bin is only ab...
See https://github.com/adafruit/Adafruit_Protomatter/pull/36 for the PWM slice number fix, already merged in yay
@kamtom480 I tested this build on a Spresense, and on A0, I get 512 connected to ground and 42304 or so when connected to 3.3V. Is this expected? The IO voltage jumper is set to 3.3V. 3.3/5 is 0.66 and 42304/65535 is ~0.6455, so that would be expected if 5V was full-scale. On our own boards 3.3V is 65535 full-scale.
This is a good correction, but we have two reports that it doesn't fix the original bug, #4284, so I'm not sure where to go from here. We could just accept this but leave the bug open, or someone can work on fixing the bug.
Add the headless board to tools/ci_check_duplicate_usb_vid_pid.py; it's complaining right now that the two Fluff boards have the same PID.
@bergdahl Are you requesting this change to make both it and your translation shorter? I have been advocating use comparison operators like In-buffer elements must be <= 4 bytes long for brevity, but I don't know how easily that translates.
Approving; all issues addressed. Thanks!
@tannewt I think maybe you have to re-approve? I thought that was not necessary if I approved, but apparently it is.
is this a bug? or just me not using correctly? here's code:
import time
import board
import pulseio
rx = pulseio.PulseIn(board.A3)
while True:
if rx.paused:
print(rx[0], rx[1])
rx.clear()
rx.resume()
time.sleep(0.1)
input is a hobby servo control signal
output:
20190 1764
20436 1518
1547 20404
20804 1193
20102 1853
20936 1038
note that the order gets swapped every now and then
Is this a esp32s2?
ah, good question. board being used is a Qt Py.
Adafruit CircuitPython 6.1.0 on 2021-01-21; Adafruit QT Py M0 with samd21e18
>>>
I have seen this with pulseIn but for the ESP32S2, when you clear and resume
For the esp32s2 if you let it "be" it get sinchronized,
per the docs:
At start and after resume the first recorded pulse will the opposite state from idle.
oh really? could you point me to that link? I have an issue regarding this
But, anyway I did some tests, and restarting and clearing the pulsein, will give me not predictable results. I can try your code in a trinket, if you want me to test
sounds like you are seeing something similar already?
So, let me point look for the issue. give me 30 secs,
Sorry for the delay my internet went down. So I was not aware of the beginning you get the opposite pulse. So durig the investigation I did something like you did in your script tryint to clear the buffer and restart, and pause, and you name it, I found out that sometimes the time get inversed, When I resume the PulseIn object
But In my M4 I did not have any issue with this, so I suspect is was just the esp32s2
I have no made any more test in other boards to see what is happening
could be something mcu dependent. i'll try m4 and see what happens.
Let me know if you want me to test it in the trinket