#circuitpython-dev
1 messages ยท Page 257 of 1
Yeah, I don't like any of this... but I like running out of memory randomly even less
definitely. also, it doesn't help per se, but wrapping the read in a try...except and catching the MemoryError is an option.
#This is a section for AAC Device Scanning
#It sends keycodes for 1-4 & Backspace and lights up blue
mode1 = Mode("Scanning", "#0000ff")
mode1.keyPress(1, "1")
mode1.keyPress(2, "2")
mode1.keyPress(3, "3")
mode1.keyPress(4, "4")
mode1.keyPress(5, Keycode.BACKSPACE)
mode1.modeChange((1,2),"Windows",2.0)
I could make a "config file" like that
The tuple in the last command means "switch 1 & 2 together"
The 2.0 means "for 2 seconds"
All of the methods could take that style - first is integer or tuple, then action, then duration of hold
Might be simple enough?
That would waste no memory on string management - it would all by done by the runtime at import time.
i don't consider it much more dificult than reading INI style, when putting my i've never seen either of these things goggles. documentation and support...those usually make up for confusion.
Well, one nice thing is that the comments in this file won't hurt me... I found that parsing the COMMENTS in the .INI file blew through memory
Just allocation/fragmentation
So I could comment the hell out of it
there might still be a hit as a raw .py though. still needs to be parsed in RAM.
๐ค hmm. i couldn't be sure without running it through the gc paces.
holy moly. its 10-to-2... i should go to bed. ๐
Yeah 10-to-3 here ... me too
This looks fine, I didn't spot any problems.
As we discussed on discord, I hope that in the future we can revisit this and reduce runtime memory allocations further (and maybe reduce memory allocated overall) by putting the AudioOut object in the driver's seat. But that work's not started, and this presents a solid improvement right now.
@tough flax I've found import order makes a large difference but is very unpredictable as to the effect. Have you tried this order at the top? ```import board
from digitalio import DigitalInOut,Direction,Pull
from time import sleep, monotonic
Also try swapping these two around
import adafruit_dotstar
import SettingsParser```
I tend to do the built-in libraries, then frozen libraries, then adafruit, then mine by default now
You can save a few bytes with brightness=1.0 too to avoid the second buffer that library makes for non-1.0 values. This is a bit insignificant when you only have 1 pixel but it sounds like you are desperate to save some bytes.
You'll get a more predictable/well-timed file close and cleanup using a with statement for the file.open() but i'm not sure if that will ultimately make any difference.
Can anyone check if this gives a weird error and puts their board in safe mode? ```>>> print(time.time())
Assertion 'MP_OBJ_IS_TYPE(self_in, &mp_type_tuple)' failed, at file ../../py/objtuple.c:254
Otherwise, examples like the one attached to the related issue fail
because tud_hid_ready never returns true.
Testing performed: Adapted the example to nrf particle xenon (it was
handy), removed dependency on IR, verified that the problem occurred
before this change, and that it was fixed after this change.
Closes: #2048
My reproducing program:
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keycode import Keycode
from adafruit_hid.keyboard_layout_us import Ke...
@tulip sleet @meager fog @raven canopy GitHub got back to me and said their plan is a 60 job concurrency limit per org ๐
Cross-platform bugs aside (#2048) this seems to work, and there's plenty of room available.
ahh, in relation to this, i assume: https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/
i need to watch the blog more closely.
yup, exactly
@exotic pumice for now reproducing the busio.I2C module impl in rust would be interesting
nice! let me know if I can help with the CI switch, I kid myself into thinking that sort of thing is fun
I think once we had an example we'd potentially use it more
interesting. i imagine its backend is Azure. No doubt it will get further integration in the future.
@onyx hinge I won't be able to take a crack at it until next week since I'm traveling
I do think it's worth doing sooner rather than later
@slender iron no worries
yeah, i'm on board too. (as if that was a question. automation seems to be my jam). ๐
@onyx hinge Any board? I've got Metro M4 plugged in.
๐ well, if either of you do start it, then post here so we can build off of it
@simple pulsar I was on a particle xenon, not sure if it's general or not -- might be tied to not having an rtc implementation come to think of it
@simple pulsar knowing it worked on a samd board would be great too
>>> import time
>>> print(time.time())
946684946
>>> print(time.time())
946684951
oh, we can set max parallel too: https://github.com/actions/starter-workflows/blob/master/ci/python-package.yml#L10
or even trigger builds on other CI providers, like CircleCI. nice! could even split up things across CI. e.g. build boards in Actions, run unix/docs/etc in Travis.
@simple pulsar that is a good data point, thanks! I'll do a bit more testing here, but kinda suspecting it is specific to nrf
While debugging an unrelated issue, I discovered that in master branch on a particle xenon, this hits an assertion failure:
import time
time.time()
The debugger says:
Breakpoint 1, __assert_func (file=0x8db34 "../../py/objtuple.c", line=254,
func=0x9a9b0 <__func__.12400> "mp_obj_tuple_get",
expr=0x8db0c "MP_OBJ_IS_TYPE(self_in, &mp_type_tuple)") at ../../main.c:486
486 mp_printf(&mp_plat_print, "Assertion '%s' failed, at file %s:%d\n", expr, file, line);...
.. such as namedtuple and attrtuple objects. This is the same predicate used elsewhere in the file to check for adequate compatibility between the types.
This was discovered due to crashing time.time() on the nrf port.
Closes: #2052
@dpgeorge would you like me to roll a version of this for micropython?
yeah a metro m4 express with 5.0.0-alpha on it doesn't have the problem, so it's nrf specific, or samd51 anti-specific
trololo I ran rust-bindgen on shared-bindings/busio/I2C.h and got back a 105908 line file. I think it generated bindings for all of circuitpython XD
Tested on PIRKEY_M0 with the code that was failing -- Works now!
Looks good to me! Thanks.
just realized this morning that audacity can create samples to test with mixervoice, so i can rule out downsampling noise quantization. ๐คฆ
is this the pinmux macro used in common_hal/busio/i2c? #define PINMUX(pin, mux) ((((uint32_t) pin) << 16) | (mux))
convert to u32, shift left 16, or with the mux?
@exotic pumice that's how I read it
where is gpio_set_pin_function and friends defined?
it looked like ports/atmel-samd/asf4/samd21/hal/include/hal_gpio.h but there's too many levels of indirection
and my trail ended with an empty inline function in the hpl
I'm just gonna try to extern it based on the definition I found and hope the linker can figure it out later
@exotic pumice I assume at ports/atmel-samd/asf4/samd51/hpl/port/hpl_gpio_base.h (or /samd21/) in a static inline void function
(so nothing that would end up with extern linkage, frustratingly for your use-case)
hmph, looks like I'll have to wait to play with the gitlab CI, because I had not signed up for the actions beta and now I'm in what I'm sure is a lengthy queue to get enabled ๐ฆ
@exotic pumice "static inline" means it's intended for the C compiler to put a copy of the function body at each site where it's used, and so there's no copy available for linking to
so yeah you could hypothetically modify asf4 to move the implementation to a source file and change it to be a "regular extern function" type as a first step. That's pretty offensive if you have to do it for all those low level APIs
I can see why they would do it for efficiency, though most circuitpython ports currently link with lto, so there would be the opportunity for that function body to be inlined whether or not the definition is in the header file or not
yeah I'll figure it out later lol
Looking at a fun project for the new Digital Pot boards ... early days, but I got a brain-dump into Eagle so I thought I'd share it
https://github.com/ATMakersOrg/ATMakers-Hardware/tree/master/JoystickWing
PCB Design files and other hardware artifacts from ATMakers.org - ATMakersOrg/ATMakers-Hardware
This needs some tidying up and corner case handling before it'll be PR-ready, but some time hopefully tonight (or tomorrow) I'll be submitting a PR for... PEP-498 (f-string) support in CircuitPython! ๐ (also cc @slender iron so you know you can ignore my dms from earlier... lol)
print(f'hi')
print('hi'.format())
x = 1
print(f'{x}')
def foo():
return 'CircuitPython is fun'
print(f'{foo()}')
print(f'{this_var_does_not_exist}')
hi
hi
1
CircuitPython is fun
Traceback (most recent call last):
File "../../tests/basics/string_pep498_playground.py", line 10, in <module>
NameError: name 'this_var_does_not_exist' is not defined
is adafruit_sdcard being rewritten from a c library? https://github.com/adafruit/circuitpython/issues/1947#issuecomment-502416941
@tulip sleet made the comment "We have a C-based library we are planning to use instead of the python-based SD library."on June 15.
I ask because I have been playing around trying to figure out the issues against the CP adafruit_sdcard lib.. and I fixed the issue with the Samsung SD cards issue #13 / and #15. I'm just waiting on my pull request to be accepted / merged.
Well until it's accepted and merged I "think" I fixed it ๐
The SD part of the SDFat library. Away from desktop until Monday, but sounds good!
so not "adafruit_sdcard"
I was going to look at the large write hangs.. but it would not be much point if the python library is going away.
Though what I learned about Samsung SD cards may prove helpful regardless.. Samsung SDcards seem to check command CRC values when they shouldn;t be.. ie the default is not to check.. but they default to checking.. So once I added valid CRC codes it started working for Samsung cards.
I had read somewhere they did it because it added reliability/stability to large cards.. which got me to thinking about our large write issue.. what if we try turning on CRC command codes.. So I am going to try that and see what happens.
Anyone know of an Eagle library that has one of these in it? https://www.adafruit.com/product/1734
Is there a good way to measure how long board.DISPLAY.refresh_soon() is taking on circuit python? I want to benchmark some code changes, but it appears it will take some C code to complete. Currently I am using this code, but I am getting very high resolution:
board.DISPLAY.refresh_soon()
millisStart = int(round(time.time() * 1000))
print("Start Refresh:")
board.DISPLAY.wait_for_frame()
millisEnd = int(round(time.time() * 1000))
print("End Refresh:", millisEnd - millisStart)
This implements (most of) the PEP-498 spec for f-strings, with two
exceptions:
- raw f-strings (
frorrfprefixes) raiseNotImplementedError - one special corner case does not function as specified in the PEP
(more on that in a moment)
This is implemented in the core as a syntax translation, brute-forcing
all f-strings to run through String.format. For example, the statement
x='world'; print(f'hello {x}') gets translated at a syntax level
(injected into the lexer) to...
I've also submitted this upstream as https://github.com/micropython/micropython/pull/4998 - modulo the lack of translation support upstream (at least in the way CircuitPython does it?), the PRs are identical. I'm happy for both projects to benefit from this, but since I mostly work in CircuitPython (and I'm also not sure how often CircuitPython rebases off upstream), I wanted to make sure the PR here landed as my higher priority ๐คทโโ๏ธ
@tough flax I don't know of one, but I could make a part like that fairly quickly if you don't want to.
In addition, it's technically incorrect to use MICROPY_VM_HOOK_LOOP without the _INIT and _RETURN macros also being present, I think.
huh a new message I don't recall seeing while trying to build the docs โ otoh, I'm not sure this laptop is set up right for doc building anyway. Seems like sphix shouldn't be looking at these files! /home/jepler/src/circuitpython/ports/nrf/drivers/bluetooth/s132_nrf52_2.0.1/s132_nrf52_2.0.1_API/include/ble.h:document isn't included in any toctree
sphinx is 1.8.5
oh is it a super old circuitpython source tree, and that's no longer where the nrf sdk stuff comes from?
@dhalbert what about MICROPY_EVENT_POLL_HOOK, used in shared-module/bitbangio/SPI.c?
I only touched the areas that I believe are specific to circuitpython, so as to reduce the chances of merge conflicts with upstream, so there are uses of the deprecated (to us) macro remaining.
Closes: #2013
should this also be applied to HID as in #2050 ?
@main meteor no, I was just hoping there was a more up to date eagle library I was missing. The newest I can find is 2015
It looks like there hasn't been a commit since then on github. I just realized I hadn't pushed any updates to my library in 3 years, so I just did.
@jerryneedell yes, #2050 would need further (trivial) modification if this goes in first. good catch.
@tannewt looks like travis is OK with the latest changes, so I'm ready for your review again. TIA!
Iโll review this by Tuesday. Thanks!
Looks like one failure here was due to flash size for one locale of M0 builds - perhaps this needs stashed behind a mpconfig flag and disabled on M0s? Seems like an unideal UX but might have to do what we have to do (or I just made a really flash-size-bloated feature?)
Another failure I don't understand at all - this seems to have not even built the feature, as ...
The way the tests work, they are mostly comparing the circuitpython result with the python3 result. It looks like we are using python 3.5 as the baseline, due to travis being based on ubuntu xenial. That may mean that there's no way for us to validate the functionality right now, which is a bummer.
And, yes, many of the ports are almost full (in terms of flash space usage). As a first step you could try making the f-string feature depend on the preprocessor macro CIRCUITPY_FULL_BUILD. I think this gets you "almost everything except boards based on SAMD21".
What's the philosophy of freezing modules into the nrf ports? Right now it feels like they have plenty o' flash storage space (at least, this particle xenon does; are they all the same at 1MB?) I have validated that adafruit_hid works and created a PR. I've also just validated that neopixel works, but haven't PR'd it yet.
@onyx hinge We only freeze modules in when absolutely necessary. The nRF boards should have enough space to not warrant frozen modules.
@idle owl maybe a comment to that effect on #2051 is warrented so it doesn't get merged blindly
We typically don't freeze modules unless absolutely necessary. In theory, the nRF boards should have enough space to not warrant frozen modules. @tannewt Thoughts?
<@&356864093652516868> Here is the notes doc for the CircuitPython Weekly for 12 August 2019. Everyone is welcome to attend! Please include your hug reports and status updates in the notes even if you'll be attending the meeting - it's super helpful! If you're going to miss the meeting, feel free to include hug reports and status updates in the notes and we'll read them off during the meeting. Hope to see you there! https://docs.google.com/document/d/1LjcLPbieUa4qvX4jyJJLf6Q4G6UuA5m4NjUX93gs3rk/edit?usp=sharing
I'm confused about when to use DISPLAY.wait_for_frame() vs. DISPLAY.refresh_soon()
and if either of them will help me ... I'm trying to do a side-scrolling thing and it's coming out slower than I expected.
I have the latest CircuitPython (4.1.0)
the function sceneCycle(...) has several calls to wait_for_frame() and refresh_soon(), but I'm not sure if I've ordered or arranged those in the best way
Right, donโt need to freeze unless there are RAM space issues.
@strange cargo scrolling right now requires redrawing the whole screen, so it's slow
@strange cargo maybe you could instead scroll in steps or whole screens
@stuck elbow , yes if I leave the background static and just move the characters it is very fast. I was hoping some clever use of wait_for_frame() and refresh_soon() could speed up the background scrolling, but when I shuffle those calls around it ends up tearing the screen more and not really going faster.
the pixels can be sent to the screen only so fast
one thing you could try is play with the hardware scrolling of the display itself โ that doesn't require sending new data, except for the narrow strip of the new content โ but that is not currently supported by displayio, so you would have to hack it yourself by sending commands to the display yourself
and of course then it would only work with the one display you use
by the way, wait_for_frame and refresh_soon are going to be removed in 5.x and replaced with a simple refresh
does MakeCode have some tricks/optimizations that CircuitPython hasn't applied? I look at the scrolling in this J.P. demo and it seems faster than what we can do with CP now.
Side-scrolling platformer games are everywhere, from old school consoles, to modern iOS and Android games, and now you can make your own with MakeCode Arcade...
that'c C code, no?
it's much faster
actually I don't know how they implemented scrolling
Maybe this is something for "in the weeds" today: What if a UF2 of circuitpython plus "the initial filesystem image" for each supported board was a build artifact of circuitpython? The benefits are (A) once done, it's easy for anyone with git to find out "what was shipped with board BB in release RR", (B) by scripting it, it is repeatable and (C) by providing a "fully reinitialize" option, it might help some users. On the other hand, (X) some users will accidentally use "fully reinitialize" and lose their own code, (Y) this doubles the number of build artifacts again, and (Z) it's a fair bit of work to do this for each supported board (source the file(s), add to git, etc)
To that end, I've written an alpha-quality "mkfatimg" program in C which uses oofatfs to produce a filesystem image containing the usual circuitpython meta-files like .fseventsd. https://github.com/jepler/mkfatimg
.. I did go ahead and throw a brain dump about this into "in the weeds"
@onyx hinge Looks good! I'll turn it over to you when we get to In the Weeds and let you talk through it and start the discussion.
@pastel panther or @gilded cradle Do either of you have a minute to test OBS with me?
I do
sure
Right on. Can you jump into the CircuitPython audio chat?
Sure
We're going to add auto_refresh as a kwarg and property to Display so that refresh is optional from the start.
Good afternoon all you wonderful folks! I'll be on the call today, lurking happily ๐
is there a keystroke to mute/unmute my mic in discord?
you can set one
Lurking only - no mic, meetings at any time
you can set it to "push to talk"
Can you ever have too many epaper screens?
do you have any round ones?
@stuck elbow no, have you seen some?
@slender iron are you damaging the screens in your testing/coding?
I've seen round oleds and memory displays, but I woulnd't be surprised with epaper ones
Lurking
@onyx hinge I don't know of a hotkey. no, not damaging, just different driver ics
lurking
lurking
not lurking ๐
๐
Lurking.
@stuck elbow I think we got some sample round ones
yah, will post some photos soon of the round displays
\o/
they are super-cool
are the pixels addressed in a spiral? ;-)
round tft iirc
CircuitPython day celebrations!
CircuitPython Day 2019 | Code + Community = CircuitPython <3
https://www.codensolder.com/blog/circuitpython-day-2019-codecommunitycircuitpython-lt3
I hope development on the round epaper doesn't have you going in circles.....
welcome @nimble narwhal are you listening in (aka lurking)?
Circuit Python Dayโ19: Blinking the Blinka: The official CircuitPython mascot!
https://medium.com/@ruchikabgosain/circuit-python-day19-c887a090a08b
CircuitPythonDay 2019 - Cake
https://youtu.be/_7WDHR-sW3w
otherwise we'll call on you later
mmm, licorice
IoT Makers Israel CircuitPython Workshop
https://youtu.be/pAwB3frQSYo
We held a special hands-on CircuitPython workshop on 8/8, the CircuitPython day. ๐ Thanks Adafruit for sending us the hardware, MakeLaB for hosting us, and B...
Smart Badge
https://medium.com/@urish/the-smart-conference-badge-we-almost-failed-shipping-edb2b1ae85b6
ASK AN ENGINEER with Scott and Ladyada
https://youtu.be/rAx3TNdPD9g
History of CircuitPython
https://youtu.be/SwNQdTU9m8s
Changing Lives through Open Source, Passion and Mentoring
https://youtu.be/kgTApb8f2L0
PyperCard - Easy GUIs for All
https://pypercard.readthedocs.io/en/latest/
FEATHER takes flight with the Wio Lite W600 from Seeed Studio
https://blog.adafruit.com/2019/08/06/feather-takes-flight-with-the-wio-lite-w600-from-seeed-studio-seeedstudio-adafruit-feather/
R is for Robot - Make Robot Friend
https://youtu.be/jeuAZO1kll0
Learn the ABCs of Robots & sing along with Adabot, Minerva, & Ruby! R is for Robots coloring book - https://www.adafruit.com/product/1936 Visit the Adafruit ...
Show and tell is now powered by streamyard.com
๐ฏ hug report for @swift arrow
that's a mouthful
Please subscribe to our weekly CircuitPython newsletter
https://www.adafruitdaily.com/
Lurking. Late. Mobile. Dying battery...
@turbid radish will that also work with breakouts with displayio drivers?
@gilded cradle it should but I don't go over that in the guide. I do point out as long as you have a board.DISPLAY object set up, it should just work
Ok, it's not board.DISPLAY on the breakouts, but you do have an equivalent object.
It might be good, as time allows to update it for general displayio wiring and use
Yeah
yes, the equiv object should work
looks
I really appreciate the degree to which you minimized that reproducer program
I've just noticed a REPL peculiarity on 4.1.0-rc.1 whilst discussing something unrelated with a fellow midi user. Note how the stack trace on exception accumulates: ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 4.1.0-rc.1 on 2019-07-19; Adafruit Metro M4 Express with samd51j19
from adafruit_midi.program_change import ProgramChange
ProgramChange(200) ### intentional illegal value
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
ValueError: Out of range
ProgramChange(200) ### intentional illegal value
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
ValueError: Out of range
ProgramChange(200) ### intentional illegal value
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in init
ValueError: Out of range
I can check against the pukka 4.1.0 and then log as a bug if that does it?
what do you mean by pukka?
I have to step away. thanks all, talk to you later!
bye @onyx hinge ๐ Thanks for stopping by
Yeah, the timers/periphs and the VM re-entrance are the biggest things imo. Aside from USB of course.
Yeah, definitely where I'd start. Sleep = loop ends.
RSTDBY and ONDMD flags...so confusing. ๐
sorry I have to miss this -- will listen to the recording -- have a good week all ๐
But, more complicated/convoluted will start to limit small boards, which I imagine are the target boards.
Happy day did it last year
But CPython only stops script execution with time.sleep(). I don't see that as equivalent to setting a PC in sleep mode.
Are both ways or doing this, compatible with a wakeup from GPIO?
no
@slender iron I assumed Jamie Oliver's favourite word had propagated over to the US: https://www.collinsdictionary.com/dictionary/english/pukka
so pukka is like echt?
Thanks everyone!!
Thanks for hosting @idle owl .
Thanks everyone! Mondays, Wednesdays, and Thursdays highlight my week.
I'll agree @errant grail -- as I'm recovering from an injury, these fun meetings give me something to look forward to, takes my mind off of things.
๐ later
@modern wing Hope you recover quickly!
Observed on 4.1.0-rc.1 and briefly discussed on Discord. 4.1.0 has same issue with accumulation of stack trace stuff in Traceback output:
Adafruit CircuitPython 4.1.0 on 2019-08-03; Adafruit Metro M4 Express with samd51j19
>>> from adafruit_midi.program_change import ProgramChange
>>> ProgramChange(200) ### intentional illegal value
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_midi/program_change.py", line 56, in __init__
ValueE...
Now that registration and planning are well underway for PyCon 2019 in Cleveland, the PSF is pleased to announce that the home for PyCon 202...
@slender iron Thanks!
Back at the office. On the drive, what came to mind is: the build artifact to start with is not a FAT binary image or a UF2 file .. it's a .zip file. Also, all the tooling is already done if you want to make zip files ๐ฒ
๐
Yup, closing since we don't need the RAM saved by freezing. Leaving it outside the binary makes it much easier to update.
@gilded cradle To repac, you where helping me with porting stuff to riscv, PlatformDetect was done, and I'm in the middle of adding code to blinka.
thanks tannewt
Yep
I'm a bit loss with was is missing. Can I send a PR and you can help by pointing out what's next?
Sure
Thanks a lot, I'll reviews the pins and send it.
Sounds good. I'll keep an eye out for it.
Thank you for this! It looks awesome and sent me down a dithering rabbit hole (this too). It'll be really handy for grayscale OLEDs and ePaper displays which are both coming in 5.x.
Unfortunately, I don't think this should be part of OnDiskBitmap because it is just one way we produce pixels to show and the others like Bitmap would benefit from it too.
There are two ways...
Great! Thank you for the improvements.
6253f11 samd: audio_dma_stop: Clear out audio_dma_state[] - jepler
8b71795 samd: audio_dma: wrap dma_{en,dis}able_channel ... - jepler
39c64bf samd: audio_dma_stop: don't free invalid channel - jepler
500d1bb samd: audio_dma.c: Remove exceptions, just retu... - jepler
33b949a samd: audio_dma, audio_background: Gate with CI... - jepler
@jepler Care to make a PR for that audio_dma_state fix?
@2bndy5 Ya, it could be a windows thing. Feel free to make a PR and rely on Travis to test it.
@jedgarpark discovered that sending a ProgramChange 2-byte message using usb_midi incorrectly produces two ProgramChange messages, the first with a zero patch byte value and the second with the correct patch byte value. One and three-byte messages seem to be unaffected.
The zero-value ProgramChange message was interpreted by Macintosh-based MIDI sniffers as incorrectly formatted. I used Windows 10-based MIDI sniffers to view the message traffic for the test.
I tested and confirmed ...
I had a brief look at this earlier chatting with John over Discord and couldn't see what was wrong from a library or MIDI point of view. Very interesting and very bizarre.
@stuck elbow echt is a new one to me!
its totally a windows thing (no problems building on the raspi)... May even be a my windows thing (running Insider Preview builds). It builds ok in travis, but the rf24.mpy is not in the correct subfolder "circuitpython-nrf24l01" under lib (see the release notes). I'm currently adding another module under the same folder that will emulate BLE advertisements using the nRF24L01. Hopefully having more than one py file in th...
I was curious how this looked, so I transcribed the algorithm into pure python and ran it on my desktop to create several output images. "posterized" is truncated to 3 bits per primary, "dithered" is using what I think is the current version of the algorithm, more or less.

This is how it looks on the PyPortal Screen:


I agree the color converter would ideally be the place for any dithering. I started looking at making a change like that, and it quickly snowballed into a bunch of changes. Large sweeping changes could easily slow rendering speed. Even this simple change to OnDiskBitmap slowed things down 100ms (~10%).
One of the key things color converter would need is the X,Y position on the screen of the current color. This could be passed to the function a pointer to a struct of pixel data instead of ...
While investigating #1908, I observed the following:
Next, I started tracking how dma_channel_enabled tracked with calls to dma_{en,dis}able_channel. I found that, contrary to what the code in find_free_audio_dma_channel requires, it appears that channel->CHCTRLA.bit.ENABLE can be set to false asynchronously.
When this happens, it's possible for both AudioOut and PDMIn to simultaneously believe they have been allocated the same DMA channel, and to make conflicting uses of it.
...
would you like me to roll a version of this for micropython?
Yes, it looks like a good change, but might be better to copy how objdict.c works with mp_obj_is_dict_type(o) macro? Also need to think how to write a test for this.
down in tinyusb at tud_midi_n_write, it looks like the ProgramChange message (msg=0xc) is not directly supported -- instead, it uses the cin=0xf option to send it as two one-byte messages. If my reading is correct, it's possible that some receiving software could treat this as two ProgramChange messages, only without a program number attached to the first one, never mind that the document I found from usb.org says it is permitted: (https://www.usb.org/sites/default/files/midi10.pdf)
![mid...
@jepler Thanks for checking into it and discovering that. In case it matters, I was on mac os 10.13.6 and seeing the issue when sending the Program Change message from a Circuit Playground Express and reading the messages with both MIDI Tools and MIDI Monitor.
It appears some of the displayio changes in 4.1.0 may have broken the SSD1351 driver. I just tested that the driver works fine in 4.0.1 and I will see if I can narrow down further with which iteration it actually stopped working. I'm wondering if it had anything to do with us removing that delay.
I get the following error accessing an I2C device (VCNL4040) after a soft reboot.
It works normally after a hard reboot, but fails after a soft reboot (control-D)
This occurs with CP4.1.0 and CP 5.0 (current master)
HARD RESET
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 4.1.0 on 2019-08-03; SparkFun Pro nRF52840 Mini with nRF52840
>>> import vcnl4040...
I am not able to reproduce this error on a SAMD51 (metro_m4_airlift_lite) it appears to be nRF specific.
Hi does "rotaryio' library works with CircuitPlayground express board ?
@obsidian compass it does appera to be "builtin" to the CPX ```Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-45-gd99d3bd47 on 2019-07-28; Adafruit CircuitPlayground Express with samd21g18
help('modules')
main adafruit_hid/keyboard_layout_us busio random
_os adafruit_hid/keycode collections re
_pixelbuf adafruit_hid/mouse digitalio rotaryio
_time adafruit_lis3dh errno rtc
adafruit_bus_device/init adafruit_thermistor gamepad storage
adafruit_bus_device/i2c_device analogio gc struct
adafruit_bus_device/spi_device array math supervisor
adafruit_circuitplayground/express audiobusio microcontroller sys
adafruit_hid/init audiocore micropython time
adafruit_hid/consumer_control audioio neopixel touchio
adafruit_hid/consumer_control_code bitbangio neopixel_write usb_hid
adafruit_hid/gamepad board os usb_midi
adafruit_hid/keyboard builtins pulseio
Plus any modules on the filesystemimport rotaryio
dir(rotaryio)
['class', 'name', 'IncrementalEncoder']
@solar whale thanks, seems like somehow it's not working for me . Let me re-flash
what versin of CP are you using -- this was 5.0 -- I'll check 4.1.0
I am on 4.1
it is there ```Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 4.1.0 on 2019-08-02; Adafruit CircuitPlayground Express with samd21g18
help('modules')
main adafruit_hid/keyboard_layout_us collections re
_os adafruit_hid/keycode digitalio rotaryio
_pixelbuf adafruit_hid/mouse errno rtc
_time adafruit_lis3dh gamepad storage
adafruit_bus_device/init adafruit_thermistor gc struct
adafruit_bus_device/i2c_device analogio math supervisor
adafruit_bus_device/spi_device array microcontroller sys
adafruit_circuitplayground/express audiobusio micropython time
adafruit_hid/init audioio neopixel touchio
adafruit_hid/consumer_control bitbangio neopixel_write usb_hid
adafruit_hid/consumer_control_code board os usb_midi
adafruit_hid/gamepad builtins pulseio
adafruit_hid/keyboard busio random
Plus any modules on the filesystem
type help('modules') at the REPL and see if it is the same as what I see.
I reflashed the same version and now I see it ๐ weird
sigh... good luck !
Great!
:+1 Thanks for the awesome guide @idle owl ๐
Ok, it seem to have broken between 4.1.0 Beta 0 (working) and 4.1.0 Beta 1 (not working).
I will try to reproduce this on a Particle Xenon with OLED featherwing, I believe that has an I2C interface.
I did verify just reading the source that reset_port() calls i2c_reset(), so it's not the most obvious possible cause.
Is there a way to search PRs for ones where I've been requested as a reviewer? I feel like there is an outstanding PR which I was requested to review but I can't find it
aha review-requested:jepler
@onyx hinge Also just by clicking:
How can we check which all modules/libs are baked in to default .uf2 for a specific board ?
Without actually flashing it
look at the board definition
@obsidian compass we are working automating this table right now: https://circuitpython.readthedocs.io/en/latest/shared-bindings/support_matrix.html. It may not be accurate right now, and it's hard to read, but that would be the place to look
With the current 5.0 master, I now see slightly different symptoms. The program runs after a hard reset, but also runs after a soft reset(Ctrl-D). However, if I run "exec(open('main.py').read())" from the REPL prompt, it dies with the following stack:
HardFault_Handler Line: 297
<signal handler called> Line: 297
displayio_group_get_refresh_areas (displayio_group_t * self, displayio_area_t * tail) Line: 313
displayio_display_get_refresh_areas (displayio_display_obj_t *...
I just reproduced it on a Particle Xenon as well - I have not tried the I2C devices -- will do that next
So far I have just used the vcnl4040.
@tulip sleet awesome :D. Is there a build script where modules names to be packaged are mentioned which I can refer?
for a particular board(say)
@stuck elbow thanks Gotchya ๐
@obsidian compass it's somewhat complicated: there are categories of boards, and then for some boards some specific modules are enabled/disabled: CIRCUITPY_SMALL_BUILD, CIRCUITPY_FULL_BUILD, and also varies by port (atmel-samd vs nrf, in mpconfigport.h), and then you look in mpconfigboard.h
that's why we're trying to automate figuring it out
@tulip sleet sounds fun, let me see where I could help ๐
@jerryneedell Could you try something besides a VCNL4040 or VEML7700? These boards have currently have pullups that are too weak for the chips (which need 4.7k instead of 10k for reliable operation).
@obsidian compass https://github.com/adafruit/circuitpython/pull/1985
SO far I cannot reproduce it with anything else -- I have tried am2320, adxl34x and adt7410
all work fine -- may well just be the vcnl4040
why is it just impacting the nrf and not SAMD?
For your new issues: table looks nice informationally but doesn't wrap;

Feather '840 has very short traces to I2C pins, shorter than other Feathers. Capacitance isn't quite enough. Adding 10pF caps or extra 10k pullups makes those chips work fine on Feather '840, but they don't work properly otherwise. Datasheet says 2.2k or 2.2k-4.7k for pullups. This is lower than most pullups. Metro '840 proto works with these chips with current 10k pullups. Try adding extra 10k pullups from 3.3V to ground on the SDA/SCL pins and see if this issue is still present. We're revis...
hmm - I have 2 other devices with 10K pull-ups on the bus I thought that would help but I'll try adding them directly
It may be a different problem.
also, why would it only fail after reboot but work after hard reset?
I saw the TWIM (I2C) peripherals seem get into a bad state while debugging the VCNL/VEML problem. Only a hard reset would fix them. But there may be some incomplete resetting going on. If we can duplicate the problem on other I2C devices, then we can eliminate chip-specific problem and it's a software problem, not a hardware problem.
adding 10K pull-ups does not help :-(
4.7kฮฉ are standard for high-speed IยฒC
FWIW - I accessed an adxl34x twice -- hard reset then soft reset -- no problem
then did a soft reset and tried to access the vcnl4040 and it failed as above.
@dhalbert did you really mean
Try adding extra 10k pullups from 3.3V to ground on the SDA/SCL pins
I have them from SCA/SDL to 3.3v -- not ground
No, I didn't, sorry, doing multiple things at once :)
also tried adding 10pF cap between 3.3V and GND but it did not change anything.
So - at this point - this does appear to be an issue that only impact the vcnl4040 -- the only reason I stumbled across it is taht I wanted to try the qwiic connectors on the sparkfun nrf52840 and daisy chain a few qwic compatible sensors. That test was successful...as long as don't do a soft reboot! Would you prefer to move this to the vcnl4040 driver repo?
I would prefer to have this on in all builds. I've never actually seen the Itsy Bitsy M0 be the one hold out on space. Looks like we're 160 bytes over which we could probably find a way to squeeze.
I agree with Damien's suggestion on the other PR about tests too.
@gilded cradle which library are you using?
Adafruit_CircuitPython_SSD1351
it works with CP 4.1.0 Beta 0 and stops working after that
and which device?
Feather M4 Express
Have to go make some pita -- back when dough is rising....๐ฅ
@gilded cradle try lowering the baudrate
Ok, I'll give that a try
Thanks for the suggestion
Hi! Why is this adding a different version of stage?
To add another frozen directory please add it as a submodule so that it's history is tracked outside of CircuitPython.
Oh, weird. @sommersoft may have an idea why it's getting move outside it's package.
@matthewnewberg I'm totally ok with passing x and y into pixel shaders.
I wouldn't worry too much about performance of dithering because it is a nice-to-have. One could always pre-process images to have dithering before loading them onto the device.
For ePaper performance matters even less because the refresh rate is so low.
Would you like to make the more drastic change of introducing a dithering module? I'm happy to help give pointers on it.
Thanks!
Based on the bare-arm test failure I got in upstream PR, this feature added about 700 bytes to the bare-arm build. I can probably find a way to trim that down (though I have very few ideas on that just yet - at work at the moment so can't toy with things much right now).
I'm wondering if finding a better alternative to the dual-buffer chr0-chr2 + chr3-chr5 workaround for switching between reader/postfix buffers would help code size by enough. I'm not sure if mp_readers are seekable, ...
@slender iron, adding the baudrate fixed it. Thanks for the suggestion.
The change was that the baudrate was added as a parameter to Fourwire and the default speed was increased. Manually passing in 16000000 for the baudrate has it working in 4.1.0.
@jepler Looks like you found the issue! I kinda figured that word packing would have an issue or two. It's kinda crazy to require IMO. Please PR TinyUSB for the fix.
Is 16mhz the limit of the ssd1351 or of the wiring? If it's the chip, we should add a way for the driver to reduce the baudrate of the given bus.
Yes, that seems to be the limit of the SSD1351. Currently the driver is separate from the bus. We could do a driver sweep and add that to the driver and reversion them as 2.0. For now though, I'm working on the guide page and I will be putting that in there.
...technically.... many our displays have SPI limits, we just ignore them because they dont mind overclocking. the HX for example, doesn't like going over 32MHz, but the ST77 is happy up to 80MHz+!
@gilded cradle - I made the requested change to Adafruit_CircuitPython_Display_Button. I am unfamiliar with how Travis works. What is it using for the automated lint checks? Also - is the creation of the .mpy automated, as well?
Thanks Jason, I'll take a look.
Oh, I think I've fixed this in my epd branch: https://github.com/tannewt/circuitpython/tree/epd
IIRC it's an issue of not resetting the group of a display properly: https://github.com/tannewt/circuitpython/commit/312c2408de359f2fe5324a5f29562d1479d7b415#diff-4ce49108868950347d358317f36c0935L238
In the OLED PR I lumped all of the reset logic into one loop not realizing that the continues would skip the display reset bits when hit.
Well, if I set it to 20MHz, it doesn't work.
I'm thinking that we can expose a baudrate property on the bus and have the driver cap it to the max it can handle.
@old smelt the lint is done with pylint. the mpy creation is automated
Can it be changed once the Fourwire object is declared?
Thanks Scott.
Nevermind, I just reread what you typed. That's what you're proposing. Sounds good.
Ok, drop this to 1 from 3 and you should have space: https://github.com/adafruit/circuitpython/blob/master/py/circuitpy_mpconfig.h#L317
I'll go back in and bump it up for M4+ later.
Yep. I haven't been actively working it, but I opened #2020 to track it.
Based on further findings, I'm deassigning myself. I'll still check with the i2c part I have, just in case, but it sounds like I won't be able to repro the problem
Are you refereding to this, USB-MIDI Event Packets on page 16 of https://www.usb.org/sites/default/files/midi10.pdf
MIDI data is transferred over USB using 32-bit USB-MIDI Event Packets. These packets provide an efficient method to transfer multiple MIDI streams with fixed length messages. The 32-bit USB-MIDI Event Packet allows multiple "virtual MIDI cables" routed over the same USB endpoint. This approach minimizes the number of required endpoints. It also makes parsing MIDI events...
Try adding --package_folder_prefix circuitpython_ to the arguments when you call circuitpython-build-tools. It defaults to include package folders named adafruit_.
This does raise a bug though. It should handle this better, than just dumping the file outside of the folder.
Playing around with BLE on the Particle Xenon (haven't managed to get my hands on an nrf52840 feather yet).
The samples are running nicely but i can't get the mac address. Is this supposed to work or it is still in progress?
Adafruit CircuitPython 4.1.0 on 2019-08-03; Particle Xenon with nRF52840
>>> import bleio
>>> bleio.adapter.address
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: extra keyword arguments given
@tannewt I tried your EPD branch on my PyPortal, but it always goes to safe mode (HardFauult) on hard reset. Do I need to make some changes to it for the PyPortal?
@subtle sun It looks like that will be added in 5.0 -- I am using a build from @tulip sleet repo and it does work ```Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-161-g1570ef2dd on 2019-08-13; Particle Xenon with nRF52840
import bleio
bleio.adapter.address
<Address e2:04:d5:fa:50:cb>
@solar whale Thanks. Ill take a look
@subtle sun I was using this branch https://github.com/dhalbert/circuitpython/tree/ble-pairing
Ok I'm missing something here. What do you do when you want to use two I2C devices at the same time?
I thought you specified the address and as long as they're different, it's happy, but I'm not seeing an address kwarg.
FYI -- the error also occurs, as predicted, with the VEML7700...
@idle owl It may depend on the device -- some are addressable some are fixed addresses - what are you using?
@solar whale DS3231 RTC FeatherWing and OLED FeatherWing.
@solar whale Compiled and flashed and it works as expected. Thanks again.
@solar whale I think I'm straight up missing something on what I should be doing for the code. Start by assuming I'm simply doing it wrong.
I thought to use board.I2C for the i2c object in both initialisation lines, and at least now I'm getting a new error.
I don't see that the ds3231 has addressing options
yes it is hardcoded to 0x68 -- should be fine with OLED
oh you mean to assign it an address
what error are you getting?
oled is 0x3C or 0x3D apparently. (according to master I2C address list)
I was getting SCL in use. I am now getting: Auto-reload is on. Simply save files over USB to run them or enter REPL to disable. code.py output: Traceback (most recent call last): File "code.py", line 9, in <module> File "adafruit_ds3231.py", line 97, in __init__ File "adafruit_bus_device/i2c_device.py", line 66, in __init__ AttributeError: 'function' object has no attribute 'try_lock'
can you post the code?
import time
import board
import busio
import displayio
import adafruit_ds3231
# i2c = busio.I2C(board.SCL, board.SDA)
rtc = adafruit_ds3231.DS3231(board.I2C)
oled = displayio.I2CDisplay(board.I2C, device_address=0x3C)```
now I get SDA in use
may need hard reset
do you have () for both?
rtc = adafruit_ds3231.DS3231(board.I2C())
oled = displayio.I2CDisplay(board.I2C(), device_address=0x3C)```
hhm try ```i2c = busio.I2C(board.SCL, board.SDA)
rtc = adafruit_ds3231.DS3231(i2c)
oled = displayio.I2CDisplay(i2c, device_address=0x3C)
or i2c=board.I2c()
SDA in use.
ยฏ_(ใ)_/ยฏ
Fair enough
I was having same issue with 5.0 and displayio OLED (also using other RTC wing and airlift), I think Scott was going to look at the code
OH.
omg.
You're right.
He said there was an I2C bug, but never clarified what it was.
cool ! You found it!
Let me try it with only that line though.
Sorry - I have to run -- good luck!
Thanks @solar whale as always!
Yes. Even though it fails on the rtc line, it doesn't fail with the RTC alone. It does fail on the I2C alone.
@crimson ferry Thank you so much. I even said "So if something happens, don't assume it's me." and Scott said "Yes." And I did it anyway.
@slender iron I found your displayio I2C bug.
I'll comment for all the good it will do
@tulip sleet re your comment nearly 4 hours ago .. I don't have those links (created/assigned/mentioned/review requests) on the pull requests page. Is it a feature you've opted in to or something?
@onyx hinge maybe it's because I'm a member of the "adafruit" organization
btw, I'm testing the nRF PWMAudioOut, using the tip of master, and getting playback artifacts on the second part of a wav file. Should I open a new issue or add to the impl one?
@tulip sleet Thanks for testing! Open new issues, I think, unless the original implementation one is still open.
@onyx hinge ok, not your issue- turns out the file got corrupted while copying to CIRCUITPY. Recopying and it's fine. This is with a potentially flaky nRF52840 that was having trouble, that I got from a user
what's a good way to get file size in bytes? os.stat seems to work, just wondering if there's something "better"?
>>> import os
>>> os.stat('font5x8.bin')[6]
1282
@tidal kiln in cpython, even, what you did is the "recommended" (just with named access instead of index). https://stackoverflow.com/a/2104107
if os.path.getsize exists that works (apparently in CPython it's an alias for... exactly what you wrote)
@sudden coral thanks. doesn't look like CP has os.path and the os.stat return is just a simple tuple in CP (thus the index)
@tulip sleet noted, thanks for checking further
As expected, I did not reproduce the i2c in use error after soft reboot with particle xenon + oled featherwing
@raven canopy want to talk audio mixer?
sure. give me a sec; finishing up a PR review.
of course
k. done. let me push current code to github. prob need to do a couple commits first.
Interestingly, on Linux I get ...

so it'll be tough for me to test any fixes.
@onyx hinge ready when you are. CirPy voice channel? (any other attendees are fine with me)
@raven canopy yes let me transfer to where I can do voice
../../shared-module/audiocore/Mixer.c|192 col 5| error: asm operand 1 probably doesn't match constraints [-Werror]
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)
#define SHIFT 0
asm volatile("smulwb %0, %1, %2" : "=r" (lo) : "r" (mul), "r" (val));
asm volatile("smulwt %0, %1, %2" : "=r" (hi) : "r" (mul), "r" (val));
asm volatile("ssat %0, %1, %2, asr %3" : "=r" (lo) : "I" (BITS), "r" (lo), "I" (SHIFT));
asm volatile("ssat %0, %1, %2, asr %3" : "=r" (hi) : "I" (BITS), "r" (hi), "I" (SHIFT));
asm volatile("pkhbt %0, %1, %2, lsl #8" : "=r" (val) : "r" (lo), "r" (hi)); // pack
dangit I was doing that "have to have the last word thing", sorry!
have a good remainder of your evening
for those who weren't listening in, I got it building on nrf but the audio levels seem weirdly low. I tried to convince sommersoft to just submit the PR without the asm stuff and leave the chance to optimize it as a gift to future generations
I plan to investigate the (probably nrf / pwmaudio specific) audio level problem soon, but maybe not super-soon
afk
built and ran this on my CPX proto - may tweak pinouts as we get closer to completion
It looks like once a button is created with fill=None, the selected_fill setting is ignored and won't show if the button is touched. I've been looking at code for quite a while, and I
...am a bit stumped.
Snooping around led me to this question: Once make_transparent() has been called for a given button's palette index, will it accept being set to a color at a later time?
Or do you have to call make_opaque() first?
...something that I tried in a locally modified copy of roundrect.py, but no luck
ooops, while trying to get my metro m4's filesystem to include "tetros" (boot sector tetris) it looks like I corrupted the filesystem.
I was just thinking, what a great easter-egg it would be to have a bootable PC game on there
is the first sector of the disk fake or something?
ah, yes, it is
oh well, it won't work out
hi @tannewt it's because of audiopwmio (for nrf port), instead of audioio, here's the issue in stage repository https://github.com/python-ugame/circuitpython-stage/pull/6.
This is marked WIP till there is a better solution. @deshipu suggested one possible solution can be that stage library gets the audioio/audiopwmio module as an object from ugame.py.
Switched from trying to parse a .INI style file to just putting the settings in a .py file ... saved 8K (on a Trinket M0) ๐
This seemed fairly harmless in REPL. Is it definitely REPL only? If not, is there any chance of leaking memory for applications with repeatedly/many caught exceptions? I'd guess not as the TraceBack/text would only be prepared when it's not caught?
I'm thinking that we can expose a baudrate property on the bus and have the driver cap it to the max it can handle.
That sounds like a magical side effect that will only cause problems at some point to someone. I know it's not as user-friendly, but perhaps just checking the baud rate and raising an exception when it's too high would be better?
TODO: figure out how to enable this only on builds on April 1.
Thinking about MixerVoice makes me even more sure that "something" comprehensive needs to be done about memory allocation for audio. Suppose you wanted to mix 8 wavs, you should be able to do it without allocating full memory for all 8 of them. Putting the audio consumer in charge would be a big improvement there too
So I understand that the ESP32 circuitpython port is not prioritized cause there's no native USB, does that mean that now with the ESP32-S2 close, the port can get redemption?
@tough flax awesome!!!
Anyone interested in a low-level discussion about how make_transparent() and make_opaque() work in displayio? Seems like they may be intended to work dynamically, but I can't create a demo which shows that is possible. On the other hand, I think I can show that they do not work that way. But if the transparency/opaqueness of a shape is NOT supposed to be changed after initialization, I may be barking up the wrong tree.
Hi,
I am VERY interested in seeing some kind of source level debugging added to Circuitpython. By this I mean the facility to have a script stop at a certain point (breakpoint), be able to examine and change variables, and the continue after the breakpoint. I am at a point with one script where it would be VERY useful to be able to do this.
For instance, I have verified that code sequences work, by using the REPL, but I am not able to see what my script is actually doing and why it is n...
what is NO_PIN defined to for samd21? I see 84 for samd51 and 0xff for nrf and stm
oh nevermind
samd51 is 118 samd21 is 84?
but the section that defines NO_PIN to PORT_BITS is only in the samd51 peripherals
@tough flax for that .INI parse thing - could you switch to using a native Python data structure (ex: dictionary) to hold the info? if it's a requirement that the old .INI file still be supported, a simple translation program could probably be written
also - i have an Eagle part for the 5mm NeoPixels, but it's not the best - the hole spacing is pretty tight
@tidal kiln thatโs what we did: and I like the python settings file. It was just nice that new users would have a safer ini experience and their computer would open the text editor for them
We made the eagle part, but thanks!
cool. sorry for lag. been deep in other necks of the woods.
Odd. The mac os receives it as straight up broken. Windows seems to get the intended Program Change message plus a bonus unintended one. And now your Linux test show it perfectly fine.
@CedarGroveStudios Is the program you used in the original report available to download? I can pop over to windows for testing/debugging (no macs in the house though)
import adafruit_midi
import time
from adafruit_midi.timing_clock import TimingClock
from adafruit_midi.channel_pressure import ChannelPressure
from adafruit_midi.control_change import ControlChange
from adafruit_midi.note_off import NoteOff
from adafruit_midi.note_on import NoteOn
from adafruit_midi.pitch_bend import PitchBend
from adafruit_midi.polyphonic_key_pressure import PolyphonicKeyPressure
from ad...
I meant the Windows program with the title "MIDI input messages"
Hi everyone i try to flash the makerdiary mini usb dongle with circuit python but geting the following error message: TypeError: 'NoneType' object is not iterable - Full error Log: https://pastebin.com/8WgebWV2 - i would appreciate some help please ๐
2019-08-15 01:33:39,150 Using board at serial port: /dev/ttyACM0
2019-08-15 01:33:39,157 Sending Application image.
2019-08-15 01:33:42,798 No trigger interface found for device with serial number: D3E3CF822FFA, Product ID: 0xCAFE and Vendor ID: 0x1915
2019-08-15 01:33:42,799 Serial: Waiting 500 ms for device to enter bootloader 1/10 time
2019-08-15 01:33:43,304 Serial: Waiting 500 ms for device to enter bootloader 2/10 time
2019-08-15 01:33:43,815 Serial: Waiting 500 ms for device to enter bootloader 3/10 time
2019-08-15 01:33:44,326 Serial: Waiting 500 ms for device to enter bootloader 4/10 time
2019-08-15 01:33:44,837 Serial: Waiting 500 ms for device to enter bootloader 5/10 time
2019-08-15 01:33:45,347 Serial: Waiting 500 ms for device to enter bootloader 6/10 time
2019-08-15 01:33:45,858 Serial: Waiting 500 ms for device to enter bootloader 7/10 time
2019-08-15 01:33:46,368 Serial: Waiting 500 ms for device to enter bootloader 8/10 time
2019-08-15 01:33:46,879 Serial: Waiting 500 ms for device to enter bootloader 9/10 time
2019-08-15 01:33:47,394 Serial: Waiting 500 ms for device to enter bootloader 10/10 time
2019-08-15 01:33:47,906 Serial: Device is either not in bootloader mode, or using an unsupported bootloader.
2019-08-15 01:33:47,908 Serial: Set Packet Receipt Notification 0
2019-08-15 01:33:47,908 SLIP: --> [2, 0, 0]
2019-08-15 01:33:48,910 SLIP: --> [7]
got it working now - nvm ๐
@indigo wedge have they released the ESP32-S2?
I guess so? hard to say https://twitter.com/EspressifSystem/status/1161622747467792385
@indigo wedge I can't see it in the Espressif Taobao store so i guess they haven't released yet. Hopefully the tweet means the release is near
let me know if it appears ๐
i know beta silicon was sent out to some members of the community
but that one didn't have usb working i heard
I also saw those reviews but they were very tight on the details
I would love to see eventually a version with BLE + WIFI + USB on the same chip
@vivid temple for the benefit of others, can you describe what you had to do to make it work? I put the UF2 bootloader on mine so I don't use nrfutil.
@subtle sun I'm sure it will come eventually
@indigo wedge yes
@slender iron Any idea when you'll have a chance to look at the I2C OLED displayio bug? I know you have your priorities. I'm blocked on it and wanted to know if you had any idea when you might get to it so I can try to plan.
@indigo wedge we have beta hardware but usb doesn't work. we'll get to it when it's more readily available and we have cycles
@old smelt it should be possible to undo but there may be a bug where setting it doesn't cause a redraw
@idle owl which bug number is it? I can try to look this week
@slender iron - thanks for confirming the intent. I think there is a bug there, but I don't know where to file the issue. I'm guessing it is for displayio?
I created a short program that I think tests the behavior and shows the failures.
It fails the other way, too. That is, if you create a shape with a fill color and then later try to set the fill to None, it does not go transparent.
Very repeatable.
The original place I saw this symptom was when I noticed that the select_fill color is ignored for a button if the original fill color is None.
In yesterday's Adafruit Daily, there was a snippit about Bryan and a APDS-9500 Gesture sensor. Clicking thru takes me to new products, but no APDS-9500. Was this just a new product pre-announcement OOPS ?
@pastel panther would know @lunar crown
@old smelt if you can replicate it with just displayio apis then it should be filed on the core
Ok. I probably can do that. I'm using either the Button or one of the shape objects to make it happen - but it really comes down to the fill() setter in the shape class, which is calling the displayio API function. Hopefully I'm making sense.
@idle owl working on it now
๐
I can test things if needed.
@tulip sleet Doing the intro to linting guide. Worth creating a venv to install Pylint into? Mine's in one. Is it ok to simply provide the command to create the venv without getting into the details of it?
@idle owl which feather are you using?
M4 Express.
Yeah I saw that! Thought it was an illusion
@idle owl I never use a venv; I just install pylint and be done with it
@tulip sleet Good to know, thanks.
a venv is useful if what you're going to install is going to conflict with existing stuff, or you need to maintain multiple python environments. But I think for most people, they just need one
@slender iron I'm not even getting CIRCUITPY with this firmware... screen says hallowing m4 express for board type.
Also says 4.x
Ooh I have stuff on the OLED. But SCL in use.
switches to metro
Yep. Still getting the same behavior. Ok on first load, SCL in use on soft reboot.
been fixing MiniMQTT this week - the server and client now properly sync with the keepalive provided to the server. Previous network errors are now handled by the library, for both issues with the ESP module and the socket. Here's an old screenshot showing disconnection from a server due to lack of synchronization , or the network module not communicating.
And here's a screenshot showing the updated MiniMQTT library...
no red !!! disconnects ๐
heya @lunar crown I missed that that made it in there! The APDS-9500 and the other sensors there are still in development; The TLV493D that @idle owl did and the ICM-20948 that ladyada did will be out a bit sooner because they're adaptations of existing boards, however the APDS-9500 that I'm working on is new to us so it's development cycle will be a bit longer
@idle owl try this:
@pastel panther If you need an alpha tester for the APDS-9500, I'll volunteer. I am interested in the part.
@slender iron I'm still getting SCL in use.
@lunar crown I'll keep you in mind if I need some help. I normally do most of the testing myself but if I see a place where you could help out I'll let you know
hrm, what is your test code?
checking now
@pastel panther Ok.
import board
import displayio
import adafruit_displayio_ssd1306
displayio.release_displays()
i2c = board.I2C()
display_bus = displayio.I2CDisplay(i2c, device_address=0x3c)
display = adafruit_displayio_ssd1306.SSD1306(display_bus, width=128, height=32)
this is mine
@lunar crown what specifically did you think you could help with testing?
I don't have the release
k, lemme try that
get SDA in use with board.I2C().
yup, I see that too
@pastel panther I am interested in finding a better gesture sensor that could be used to replace knobs on a radio. So some knob replacement oriented application testing, general debugging of the drivers.
@lunar crown Ok, great, I'll let you know if something comes up
@slender iron is the displayio.release_displays() required?
@idle owl you should have the release
Because it seems like it's trying to work with that line.
@pastel panther Ok.
otherwise you'll make multiple displays over the same one
hmm ok
Ok, looks like it's working then. Though I have no idea how to do anything with it. Obviously doesn't work like the original OLED driver.
@slender iron Want me to review?
sure
Thanks for the fix! Tested on Feather M4 Express with OLED FeatherWing. Initialises successfully without error.
Example code:
import board
import busio
import displayio
import adafruit_displayio_ssd1306
displayio.release_displays()
i2c = board.I2C()
display_bus = displayio.I2CDisplay(i2c, device_address=0x3c)
display = adafruit_displayio_ssd1306.SSD1306(display_bus, width=128, height=32)
Looks good, and thanks @kattni for the crucial actual smoke test!
OK, I reproduced the problem with miditools, verified that my proposed change fixes it, and filed an issue and a PR with tinyusb: https://github.com/hathach/tinyusb/pull/99
Subsequent to that, we can PR "pull in updated tinyusb" which will enable us to close this issue up.
Have you guys seen this?
https://youtu.be/EMnx_EZYM1Y
A Code Companion for my offline address generator, uBitAddr designed to run on the Adafruit M4 line of microprocessors.
509cbd4 First stab at building a board with github actions - tannewt
I left this comment in the ARM community thread linked above:
https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile/159410#159410
I am suspicious that the compiler build itself was done with at least some optimizations turned off. In the 7-2018-q2 (7.3.1) release, lib/cc1 is 20MB in size. In the 8-2018-q4 (8.2.1) and 8-2019-q3 (8.3.1) updates, it is 30MB, which is a huge increase.
By comparison, in the Ar...
interesting findings @tulip sleet
i'm looking at the source tar file now
good luck! There was a lot of stuff there
@tulip sleet I noticed that in build-toolchain.sh there is a block for "is_ppa_release" which sets ENV_CFLAGS to hold -O2. By changing to non-ppa releases, did they introduce this performance regression?
what line number is that? I was kdiff3'ing the gcc7 and gcc8 source releases. The website (not ppa) release for gcc7 and gcc8 has this size difference @onyx hinge
okay, hmm
i am building the latest release to see what the cc1 size will be
line 186 of build-toolchain.sh in gcc-arm-none-eabi-8-2019-q3-update
is that what you mean? no diff there between 7 and 8
cc1 is 31MB in my build (after strip)
errr line 168
what I was suggesting is, adding -O2 to some cflags is gated by is_ppa_release. I thought maybe that was the change, not any revision to the building scripts
but since you were comparing the binary size of two non-ppa releases that seems like a bad hypothesis
yah, that's possible, though looking at teh compile lines fly by, I am seeing -O2 on most of them
i don't use arch, I was just trying to find another build that was a size comparison
I can try the build again and set that flag or disable the check. I have to go out but will be back around lunchtime
there is a diff invovling the addition of CXXFLAGS in that script, though I don't see anything wrong with the changes
I'm hoping someone on the build team will take a look at my comment ๐
will check with you when I'm back
-DBASEVER="\"8.3.1\"" -DDATESTAMP="\" 20190703\"" \
-DREVISION="\" [gcc-8-branch revision 273027]\"" \ -DDEVPHASE="\" (release)\"" -DPKGVERSION="\"(GNU Tools for Arm Embedded Processors 8-2019-q3-update) \"" \
-DBUGURL="\"<https://gcc.gnu.org/bugs/>\"" -o build/version.o /home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/version.c ``` I don't see any -O when it comes to building gcc proper
+make -j$JOBS CXXFLAGS="${CXXFLAGS:-}" CXXFLAGS_FOR_TARGET="-g -Os -ffunction-sections -fdata-sections -fno-exceptions" ```
+make -j$JOBS CXXFLAGS="${CXXFLAGS:-}" all-gcc ```
I think these have the effect of clearing out optimizer flags, but for C++ files only. Most of gcc proper is compiled as C++ these days, I think
looks like circuitpython doesn't yet have a general audio resampling algorithm in it?
I wonder if libsamplerate is even slightly amenable for inclusion in CP. It's two-clause bsd license. i386 libsamplerate.so has 14kB in its "text" segment, but 1.5MB in its "rodata" segment(!!)
3 sets of resampling coefficients, from 2464 to 340239(!!)
looks like it would need some banging on to create a "libtinysamplerate" that has a more reasonable footprint
cool, current libsamplerate includes octave scripts to generate filters, s possibly a smaller but adequate filter could be generated
@onyx hinge you saw this, right? https://github.com/adafruit/circuitpython/blob/485dd8a67375a3b10a0cc8163c447ab6bb68d333/ports/atmel-samd/common-hal/audiobusio/PDMIn.c#L311. The filter coefficients were generated form some filter generator, and we optimized the speed to be adequate for M0. The filter shape is not great, but is good enough. I have some graphs somewhere.
@tulip sleet yes, I did see it
I experimented with different cutoffs, # of coefficients, etc.
Some part of me figured, better to put this off onto a library than to code it ourselvs -- avoiding NIH
but taking it from the samd build is probably more practical
i did do some looking and there were surprisingly few helpful libraries or sample code.
libsamplerate seems on a sound footing, it has a small API surface, but the coefficients are way too elaborate, even before you consider that we only have 32-bit FP math
unfortunately I can't seem to find our discussions. I think they were in hipchat and are gone
argh filled up my ssd trying to build arm sdks
OK but I'm looking at a random object file in build-native/gcc-final/gcc (web.o) and yes it looks like an optimization-disabled build. This trivial leaf function (rhs_regno(rtx_def const *)) has redundant manipulation of the stack that -O2 eliminates
install-native/cc1 is 30-ish megs stripped
@onyx hinge did you try forcing the ppa release setting?
line 168 is -O2 for libs, it looks like
@tulip sleet no, my next try is manually putting "-O2" on the line CXXFLAGS= (line 152)
build-toolchain.sh --build_type=ppa and other choices. See around line 52
i'm trying to see how to do a clean without unpacking and re-fetching again
x86_64-linux-gnu-g++ -fno-PIE -c -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/. -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libcpp/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-native/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-native/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-native/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libdecnumber -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libbacktrace -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-native/host-libs/usr/include -o web.o -MT web.o -MMD -MP -MF ./.deps/web.TPo /home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/web.c
this file no optimization
the mingw build does pick up optimization though, interesting.
bleh
i686-w64-mingw32-g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/. -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libcpp/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-mingw/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-mingw/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-mingw/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libdecnumber -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/../libbacktrace -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-mingw/host-libs/usr/include -I/home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-mingw/host-libs/usr/include -o web.o -MT web.o -MMD -MP -MF ./.deps/web.TPo /home/jepler/eabi8/gcc-arm-none-eabi-8-2019-q3-update/src/gcc/gcc/web.c
anyway, as far as building again, can you just remove the build* and install* directories?
er except don't remove build-* because that removes the scripts oops
@onyx hinge in my now lost PDMIn, I was using the samd filter as a basis. Since nrfx uses different buffer sizes, I played with the number/amplitudes of coefficients. All I ever got was clipped tones in the end though...
yeah, I did that ๐ unpacking again
i didn't install all the mingw stuff, so the build-prerequisites failed early, but it didn't affect the linux build
i will try a ppa build
+++ ./build-toolchain.sh 2019-08-15 11:22:41.081622816 -0500
@@ -149,7 +149,7 @@
done
fi
-CXXFLAGS=
+CXXFLAGS="-O2 -g"
if [ "x$BUILD" == "xx86_64-apple-darwin10" ] || [ "x$is_ppa_release" == "xyes" ]; then
skip_mingw32=yes
skip_mingw32_gdb_with_python=yes```
this is what I'm trying
and now I can see that web.o got built with "-O2 -g" flags, yay
afk
@onyx hinge ppa build is failing for some reason, maybe requirements in wrong place. Anyway, once you can find cc1 in the build output, you could stop and check its size. Do you want to reply to my post in that ARM comminity thread or shall I?
nice investigation @tulip sleet and @onyx hinge . it'd be nice to have a modern gcc deb for bionic which github ci supports
I was thinking we may want to zip all of our deps up together and simply unzip them in the CI
what's amazing to me is that this issue has lasted through two release cycles with ARM builds
ya, I think fewer and fewer folks use their release
I'd love to port the arch build script to homebrew and use that
People just expect software to get slower over time. And, not sure what's used more, but I bet the windows builds weren't affected
Looks like I get a tarball as a build artifact, not debs
can you just find . -name cc1 -ls and strip that to check the size?
When I get back to my desk I'll do that
@umbral dagger hihi
@meager fog hey
@umbral dagger ok so for the bitmap stuffs, is there more you can do with the PR to get it shipshape
Yes, scott had a suggestion. I'm looking at that now.
ok please work on that today
@umbral dagger meanwhile, do you have one of these
I do not
ok, let's report it, do you want to register and post in that thread, or shall I cite you (by name or anonymously)? Someone else opened a support case but we cannot view it. I'll ask that person if they got a reply eyt.
@tulip sleet feel free to name me, do you want me to provide some circuit python build times too?
not needed, other people have said it's 3 times slower
I don't want an account with arm,I think I've avoided that so far
I can cite your github id or just your name
I'll say you confimed it and changed CXXFLAGS to have -O2, and it fixed it. Whoever made that change can figure out what they really want.
Yes please include or at least describe that diff
definitely
@umbral dagger please grab one each and also a 1.3" OLED https://www.adafruit.com/product/938
@umbral dagger plz order now cause we only have one of the lil displays in stock ๐
@slender iron I can do that, like I did for the xtensa toolchain once
@meager fog Ordered.
@umbral dagger ok next few projects will use those - please keep workin on the PR with scott till then ๐
@umbral dagger do you have a pi 4?
@meager fog Not yet
@umbral dagger ok is there a place you can order one
@umbral dagger looks like seeed has some https://www.seeedstudio.com/Raspberry-Pi-4-Computer-Model-B-4GB-p-4077.html
also get a camera if you don't have one yet
@meager fog I have a couple Pi cameras kicking around
ok you'll want the 8mp one
@jepler and I confirmed that the downloadable toolchains are not built optimized: https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile/159420#159420:
A co-worker (GitHub @jepler) and I confirmed that the builds are not optimized: they are not built without
-O2. Between the 7-2018-q2 and 8-2018-q4 releases, some changes involvingCXXFLAGSwere made tobuild-toolchain.sh.This diff makes optimized bui...
@meager fog That's what I have
ok gr8! thanx
@tulip sleet https://emergent.unpythonic.net/files/sandbox/gcc-arm-none-eabi-8-2019-q3-update-linux.tar.bz2 has the -O2 mod (built on debian stretch, dunno if it would work in the current build env)
Thanks. I think we will wait for a fix, unless we want to host this somewhere for people to download. We are currently recommending the gcc 7 release; the gcc 8 one doesn't do much better on optimization. We do want to make it easy for people to duplicate our build environment.
i did download that, for future reference. it takes a long time to build the whole thing ๐
it makes me smile to be your co-worker fwiw
afk though, I need to concentrate on other stuff
i also have more on my list ๐ฅ
@tulip sleet have you tried gcc 9?
I wonder if we compile gcc -O3 we'd speed up linking
nope, not yet. Damien is trying it, and there are some issues with the nlr mechanism: https://github.com/micropython/micropython/pull/5008
gcc -O3 would be interesting, though it might be I/O bound. Your idea of making one job per board is interesting, to allow more than 5 jobs but let others squeeze in. I wonder though if they will all get queued at once and still be a monolithic block of stuff in the Travis queue.
Last night I was testing the keyboard code on the PyRuler and everything was working fine after I updated the code a few times.
This morning I went to try the new code @ladyada wrote and my ruler will not show up as a CIRCUITPY drive, nor does a USB serial port show up.
About 6.5 seconds after plugging in the ruler would result in this mesage in dmesg:
2068082.010921 AppleUSBCDCCompositeDevice@: AppleUSBHostCompositeDevice::ConfigureDevice: unable to set a configuration (0xe0005000)
...
When plugged in, the dotstar is magenta/fuchsia as soon as it is plugged in and stays that way.
Double tapping reset to try to get into the bootloader just now didn't work, the dotstar is solid light blue and there is no TRINKETBOOT. Single reset also resolves to a blue dotstar after the BOOT attempt until the ruler's cable is remove and re-inserted which makes the dotstar pink again.
Just tried again and the BOOT drive works again, maybe user error.
Let me know if there is anything ...
@meager fog You have me curious. Everything should be her on or before Monday.
@umbral dagger gr8
I noticed the MonsterMask is in the store now(!) but also in the product writeup it says no CircuitPython yet. Does anyone know when a MonsterMask uf2 (even a slow one) will show up on circuitpython.org downloads?
... also, I was wondering how it will work to have 2 displays accessible to CP. Will there be board.DISPLAY0 and board.DISPLAY1 or in a list like board.DISPLAY[0]?
yeah we have not done a mask board definition
so its only in arduino for now
we'll work up a cicuitpy def but...you can't do more than dispayio stuff, like, the eyeball code will not run, its wayyy too optimized
I've been using displayio for text and tilegrids with the other devices and it's great for my purposes. This MonsterMask looks really cool. I just ordered 2. can't wait to play with it. ๐
with 3 jobs shipping out over the next week, I might actually get to return to some cp
yay
I just plugged mine in -- and it went to Magenta. need fairly slow doubletap but got TRINKETBOOT and green Dotstar. Reset went back to magenta - stays magenta even when stopping main.py and going to REPL
@slender iron It looks like I need a way to separately enable audiobusio i2s and pdm. Do you want to see what I come up with, or suggest an approach to me?
or I could just stub it out at the same time, the hardware is there and I'm sure we'll want to support it eventually
@strange cargo I picked one up too to get cp going on it
@onyx hinge stubbed out and raising a not implemented error is fine. you may find that after doing pdm that i2s is easy
@slender iron will do
is still fuming over discovering that he nuked his PDMIn work... if nothing else, i could've saved you some time.
Is this the right place to ask about the CP libraries source?
I'm trying to find the .py versions of a couple of files and when I went to https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases/tag/20190815 and downloaded the source code, there's a lot of folders but no files in them
@magic wing the Source code zip files don't contain the bundle. they are a GitHub release artifact, as i understand it. the adafruit-circuitpython-bundle-py-20190815.zip will contain all of the libraries in pure .py format.
Aha, thank you
One last basic question -- how do I paste a chunk of code or output in Discord and get it to format it as code?
surround it with three backticks:
```
code
```
code
you can even use some pretty printing formatting
```python
>>> foo = "bar"
```
>>> foo = "bar"
hehe. oops.
nice, thank you
This expands functionality across the STM32F411VE and STM32F412ZG Discovery Boards. Specific features include:
- Board, microcontroller and DigitalIO support for the F411
- USB, internal flash, and FatFS support for the F411
- I2C support on both discovery boards.
- Conditionals to support boards without filesystems or low numbers of USB endpoints
- Minor QOL fixes and additions.
@raven canopy Did you ever push the PDMIn work to your fork? (I guess not, but I have an old clone of your fork.)
@tulip sleet added a test job as a prereq: https://github.com/adafruit/circuitpython/runs/194823378
finished and pushed 11 minutes ago
@raven canopy @onyx hinge obviously I'm working on the github ci stuff. looking very promising
- Discover characteristic descriptors during service discovery
- Allow specifying
CharacteristicorDescriptordata length, and allow setting to fixed length. - Add GATTC/GATTS read/write for
Descriptor. - Remove named constants for descriptor UUIDs. Better to just do these in Python.
- change
Characteristicproperties from keyword arguments to bitmask. - Add setting read/write security levels on
CharacteristicandDescriptor. IntroduceAttributeclass as a notional supercl...
interesting discussion about backporting features from another mp port back into mainline: https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo/issues/304
https://github.com/adafruit/circuitpython/runs/194841441 no board builds if tests fail
@tulip sleet i think it was a combination of overzealous stashing while changing branches, and deleting branches. its proper nuked. though, if you have a copy of a branch with I2SOut.c/h...that should be at least close to the most recent.
gotta run to the store real quick
@slender iron I saw, am excited
@tannewt is it possible that this was fixed by the merge of #2063? I reproduced the issue at 583392a5c694c082f6 but not at 485dd8a67.
got my pdm mic breakouts today but didn't play with that, beyond soldering headers on. Instead, I got reasonably far on stubbing out pdm and i2s, and think I follow a lot of the datasheet things in the pdm section better than before
I wonder why they made the way DMA works so different than PWM, it was confusing at first coming from that
also have one of these printing at the moment https://www.thingiverse.com/thing:3457290
'night all!
ben heck's working on a samd51 board https://twitter.com/benheck/status/1162196510701961216
circuitpython when? lol
for all of the boards
Hey @idle owl Should the RFM Bonnet be being initialized in every iteration of the main loop in this example? https://learn.adafruit.com/adafruit-radio-bonnets/rfm69-raspberry-pi-setup
@tough flax That definitely looks like an error . It works but is unnecessary to repeat. It should be done outside the loop. It's the same in the rfm9x_check as well. @prime flower - do you agree? https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/pi_radio/rfm69_check.py#L52 https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/pi_radio/rfm9x_check.py#L51
@slender iron This is interesting; I think it would save RAM, but did you already change how the qstr pool grows? https://github.com/micropython/micropython/pull/3962. tools/mpy-tool: Set sane initial dynamic qstr pool size with frozen mods #3962 This was committed after our last merge from micropython. It's an easy change to mpy-tool.
This fixes a problem with USB MIDI messages 0xc and 0xd and Closes: #2057
@slender iron mpy-tool change above appears to save 180-200 bytes in RAM after importing part of HID on CPX
@tough flax No idea! LoRa is @prime flower's domain. He should be able to let you know.
Great work! Thanks so much for diving into this @jepler
@tough flax @solar whale Yup, looks like an error. Initialization of the RFM9x object should occur outside the loop.
and only happen once
just a history check - looks like encode was enabled for M0 boards at some point? it used to not be in there
for strings
@siddacious or @jerryneedell can you get a backtrace? Maybe load the pyruler board def on a metro m0 to do it easily.
@tannewt does that last error even have anything to do with my changes? It says it can't install python.
I restarted that subjob. Sometimes the Travis instances are flaky.
Tested ble demo examples on feather_nRF52840_express and pca10059.
no issues
@tannewt what point are you looking for a backtrace from? What version of code was this?
API comments. Still looking at common-hal.
Why not just return the discovered services? Is it async? Returning them would allow the user to decide how long to keep the objects around.
I'd just write SECURITY out completely. Otherwise you risk people not knowing what SEC means.
No other comments. Please address the previous set.
Happy I could help, and learn something in the process!
@slender iron I am still looking thru those sdcard issues.. While my sdcard fix does fix the issue with Samsung cards, I do not see where Arduino is doing that.. So why does theirs just work? I am still digging into it.
Maybe I can make some progress on the other sdcard issues as well.. I seem to be learning a lot about sdcards, might as well put it to good use eh? ๐
@swift arrow I haven't looked at the arduino impl recently
I really appreciate your work on it. you've been making good progress
<@&356864093652516868> how can we better track prs with no responses. here's another that's been open 5 days with no response: https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground/pull/66
(I'm looking now)
@slender iron git webhooks and a lambda in AWS that posts to a google sheet?
Or something
or maybe just ping this channel with them?
hey @slender iron I had a question that never got answered and it seems maybe you're not knee-deep in code at the moment. Can I repost?
ya, or link me to it @exotic pumice
@slender iron Or I need to do a sweep weekly but that could leave things unanswered for a week if the timing failed. Could add it to Tuesday/Thursdays as well. So Monday/Tuesday/Thursday I sweep.
I feel like we should track time to reply on issues and prs
the context is busio/i2c uses a pound-def called NO_PIN and idk what it's value is
Or MWF would probably work better for tracking purposes.
and it seems odd that it's only defined in samd51 peripherals not samd21
@idle owl ideally it's more than you just doing it
@slender iron Fair enough but I think I need to take the lead on it regardless. I can start it and start coordinating others as well.
yeah ok, but if you look at the 3rd ripgrep result there, it's in samd51 peripherals, and not in samd21 peripherals, how does that work?
I'd volunteer to do a sweep but I just can't predict my free time well right now.
@exotic pumice I see it in both: ```
ports/atmel-samd/peripherals/samd/samd21/pins.h
40:#define NO_PIN PORT_BITS
ports/atmel-samd/peripherals/samd/samd51/pins.h
41:#define NO_PIN PORT_BITS
@slender iron Do your observations on PR tracking extend to libraries? I put https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/pull/39 in a while ago
This is an implementation of json_transforms described in #38.
Developed for and tested with nasa.py a new version of NASA image viewer from Adafruit Learn: PyPortal NASA Image of the Day Viewer.
T...
but it doesn't really matter as long as it's an invalid pin number
@simple pulsar yup
thanks
@simple pulsar @slender iron I'll take a look at it.
@idle owl @slender iron wasn't this suppose to sorta provide an overview of issue/PR status?
https://github.com/adafruit/circuitpython/issues/1246
and thought there was some adabot work done to highlight number of days?
afaik we only track days with the gap between last unreleased commit and now
@tidal kiln It was moved to circuitpython.org/libraries/contributing . But it runs once/week at the moment, we need it more often.
And yeah the days thing is only for releases.
ah, ok.
GitHub was failing to update that issue anyway. Ran into nothing but issues with it.
issues with an issue? you should open an issue.
so maybe just some tweaks to that webpage? run more often and (if possible) add better visibility for numbers of days?
@idle owl should that issue be closed and sticky removed? leave a comment to check webpage instead?
I did open an issue. ๐
I'll talk to Sommersoft about updating adabot to do better PR/issue tracking
And I thought I did those things, I'll go do them in a bit here. Yes to both questions.
thanks all!
I'm curious to know when the status LED is purple where the code is stuck.
I'd prefer it if the stage library was improved to work rather than adding a separate version. @deshipu is that doable?
ah OK -- I'll try to dig into this over the weekend.
@dhalbert Please merge if you don't want to review.
i'm updating a README in a CP library
OK to delete the "Building locally" section while I'm in there? We removed that, right?
@simple pulsar I'm trying to work on this JSON issue. Got a minute?
Removed. I was going to add the constants that are now in Attribute here, and then changed my mind.
Ok, we'll just wait for fixes from the upstream PR and then merge.
I assume it's REPL because it's the only case where an exception doesn't cause a VM reset. However, I haven't looked in detail yet so I may be wrong.
Sure, throwing an exception works too.
There are a few corresponding changes now in https://github.com/adafruit/Adafruit_CircuitPython_BLE/pull/16.
@slender iron do you have a suggestion on how I should handle the static inline void gpio_set_* functions I can't extern?
I could maybe steal some stuff out of atsamd-hal idk
We would still need to expose the property so the driver can check what itโs set to. Also it would need to fail gracefully if used with an older version of CircuitPython.
@exotic pumice ya, you can just reimplement against the registers directly
okie dokie
it's actually kind of hard to figure out how to write directly to a register with all the hal indirection we both have XD
like, the address to write to
@slender iron itโs very satisfying to test BLE when it works. Probably same for display stuff. Three different devices chugging away here: two talking to each other, one talking to phone
nice!
Is there an arm version? Maybe it's something we add a secret command or character sequence for.
Looking good! Thanks!
28ca05c allow discovery from central or peripheral - dhalbert
83129b8 BLE: peripheral client pairing (not yet bonding... - dhalbert
91d791a cleanup adapter.address; add uniquish suffix to... - dhalbert
ee518b9 Merge remote-tracking branch 'adafruit/master' ... - dhalbert
7ce3776 WIP: rework of Characteristic properties; enhan... - dhalbert
Thnaks. My comments are mostly cosmetic. We can merge this for now and then you can start fleshing things out.
Add newline at end of file.
Are there STM macros for critical sections?
Are you going to move these pin inits to I2C.c?
I actually just realized that I didn't add the information about default buffer size to the documentation. I will do that tomorrow.
Thank you for this! How would you recommend loading the binary? A few comments inline as well.
Is the ports/stm32f4/stm32f4 submodule a mistake?
You may want to disable NVM. The samd size is meant to match an erase sector but STM's are huge.
Raise NotImplementedError here too.
Please raise a NotImplementedError here and in other stubs. (The stubs themselves are fine. Just want to prevent folks from using them.)
There is a single, very buggy one that isn't atomic and does not properly block ISRs. Most engineers entirely rework it. I think we discussed this briefly before - I believe this section is actually called sequentially by the interpreter so it doesn't technically need the critical section? If it's a priority I can revisit.
My plan is to entirely revamp the pin and init system to remove the MSC files and have everything done via the LL libraries, yes.
@slender iron done with CurrentTimeClient review fixes I did manage to cause it to crash by doing an auto-reload while testing. That's what alphas are for. ๐
๐ yup
At the moment, due to the above HAL reliance on the MSC, and not storing enough information about pin capability per pin. It'll require restructuring the pin object to hold more information, and moving everything to the LL functions as opposed to the HAL.
This was intentional, since there's often desynchronized functionality between the two discovery boards caused by USB or other differences. So it regularly gets uncommented and used when adding new features. If you'd like that kind of reference comment committed for PRs let me know.
Yes, looks like some of these snuck in when copying the occasional segment from the HAL docs or CubeMX setup.
@tulip sleet merged. going heads down into eink now
Ok, I didn't look too far into that system. Are there any examples of disabled NVM I can draw from?
I was caught up on email but I'm probably behind already
Yes, see some of my replies in Dan's commentary. It requires moving to the LL libraries but also a big restructuring of how I hold information about modules per pin object. I wanted to bang out a quick version first to get a handle on it but I'm going to rework it before finishing the rest of busio.
That would make the conditionals board specific. That might not be a bad thing, as the low end F4 boards might be the only ones that every encounter this issue, but it's not super modular if that changes. Would it be better to pass in what endpoints to disable in particular, and have that specified in mpboardconfig?
@solar whale jerrynLast Thursday at 2:54 AM @iXiiON#3390 for the benefit of others, can you describe what you had to do to make it work? I put the UF2 bootloader on mine so I don't use nrfutil. -- i'm not aware about an uf2 bootlader for the makerdiary usb dongle. So i used the *.hex file, to make it work you have to unplug the stick, press and hold the button and then plug it back into the usb port then the device seems be be ready to be flashed. nrfutils can then write the *.hex file on the device and ciruitpython runs.
Greetings <@&356864093652516868> Has anyone successfully connected their #circuitpython-dev devices and scripts onto AWS? Other public clouds? Thanks in advance...๐
This looks fine, I didn't spot any problems.
As we discussed on discord, I hope that in the future we can revisit this and reduce runtime memory allocations further (and maybe reduce memory allocated overall) by putting the AudioOut object in the driver's seat. But that work's not started, and this presents a solid improvement right now.
Amazing how little code is needed to get those Digital Pots working... thanks @idle owl @prime flower and everyone on the CP team https://www.youtube.com/watch?v=wt8LbnfXiRM&feature=youtu.be
With the release of Adafruit's new Digital Potentiometer breakouts, we thought we'd take a look at how we could use these to create a virtual joystick. My ap...
I have my J-Link connected to the PyRuler:
I looked at the attempts to change the color of the LED during the boot process and it looks like it is trying to set it as expected but the LED is not responding -- it just stays magenta.
(gdb) mon reset
Resetting target
(gdb) cont
Continuing.
Breakpoint 3, new_status_color (rgb=<optimized out>, rgb=<optimized out>) at ../../supervisor/shared/rgb_led_status.c:168
168 current_status_color = rgb;
(gdb) traceback
Undefined comm...
Goal for the day: dma something from the pdm device into memory on nrf. I think the data comes out as signed 16 bits at 16kHz...
tip: you need to create an event handler in PDMIn.c to handle the buffer pointers from nrfx. ๐
I wonder, whether it's feasible to generate test waveforms for pdm... Or if I have to rely on the mic
Should I be using nrfx "high level" APIs, vs low level register operations? I did the latter for PWM audio out
i'd say that's up to you. as long as the cake comes out, it doesn't matter? ๐
If there is a general preference among the developers I'll try to follow it
Unless nrfx is regarded as buggy, probably better to use it...
@keen ocean @prime flower Would be a good person to ask
Is there any reason why bootloader mode would draw more current than CIRCUITPY mode? iOS 13 iPhone can see CIRCUITPY, but throws a dialog about requiring too much power for bootloader mode.
Note: I am running with current master ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-189-g85d739847 on 2019-08-17; Adafruit PyRuler with samd21e18
The DotStar LED also works if I command it from the REPL.
@crimson ferry only thing i can think of is a difference in the USB descriptors passed in by both modes. iOS may be expecting a descriptor that isn't passed in during bootloader mode, or a descriptor has a value that triggers that "warning".
@raven canopy Thanks, hadn't thought of that. I have a powered connector coming, I'll see if that helps. I'm trying to see if I can update UF2 from my phone ๐
that'll be interesting. and, downright awesome.
We need to remember to do a 5.x lib bundle when we release 5.0.0.
And update circuitpython.org/libraries page to include it.
and maybe drop 2.x bundles? ๐
@raven canopy I know ๐
Hello.
I want to know about esp32 with micropython.
I'm trying to use ble on esp32 with micropython.
I found esp32--bluetooth.bin in Firmware for ESP32 boards`(http://micropython.org/download#esp32)
And esp32 succeeded bluetooth.
However it's CLASSIC Bluetooth.
I want BLE(Bluetooth Low Energy)
Should I??
@timber mango I know that the micropython supports the esp chips, while circuitpython doesn't (circuitpython has chosen to support only devices with native USB support). I don't know whether BLE is technically possible on ESP32.
hm, interesting -- remember when we discussed signed vs unsigned audio samples? It seems like pdmin is set up to only permit unsigned 16-bit samples, hm.
ValueError: destination buffer must be an array of type 'H' for bit_depth = 16
@onyx hinge I'm sorry, question about micropython is not good.
It's OK, we might just not be able to give the most accurate information about it
status: I can VERY FAINTLY hear my shouting over a lot of background noise
(when recorded via pdm and then played back on the speaker)
I would have expected full silence (unchanging PDM values) if I hooked DATA to GND or +3v3, but that's not what I get.
yeah, my signal is definitely there but there's a lot that is NOT my signal. I guess I could /should run this same code on my cpx and see how the quality is, for comparison.
@idle owl There are a lot of modules that need fixing for audiocore too, though we could also still decide to alias audioio.WaveFile et al from audiocore just for 5.x .. (I know, scott disagrees with that)
@onyx hinge It's still worth discussing. Will you be around Monday?
@idle owl I think so, but I haven't checked my work meeting schedule. If I don't have something at that time, I will "take lunch" and join the meeting
@onyx hinge Ok. We can also have a chat outside the meeting.
I should also go ahead and make a PR, just to make sure it's as simple and light on memory as I think it is
We like them early and often. ๐
I hope I got the dimensions right on this bezel. It should look pretty sharp in two colors once it's 3d printed
I believe we should do this because it's easy, and it makes a better user experience, especially if we have any concerns about circuitpython modules not getting updated in time for the 5.x release.
Testing performed: That the shipped .mpy files on a PyPortal (CP 4.x) still work (play audio) with this branch, instead of giving an exception because WaveFile can't be found in audioio.
Flash usage grew by 28 bytes. (I expected 24, there must be some other effect on size/alignment that ...
@onyx hinge To test audio in I play a tone with my phone next to the mic
then you can play it back and capture with a scope or saleae
hmmm - FWIW -- I tried building CP a trinket_m0 and it works normally -- green Dotstar pulsing on boot.
I loaded taht same Trinket_mo image to the PyRuler and it give the steady magenta Dotstar as before...
I then put the PyRuler build on the Trinket M0 and the DotStar LED is pulsing green as normal.
Not sure if this is telling us anything but thopught it might be useful information
hi @meager fog !
I'll head back down to the python cave
I can do at least 40 minutes right now if it's a good time for you
ok, which part of this whole thing do you want to start with?
yah
ok so first up, lets check the clk freq
on your scope/logic - whats the mhz of the squarewave on clk
I know it in general terms, the DATA pin is going to be asserted by the mic according to the edges of CLK and the intensity of the measured sound
yah and you oversample
since its only 1 bit
you need to collect lots o bits
1MHz = 16KHz x 64 bit oversampling
I think in the nrf the hardware is doing that part
there is a register for 64x or 80x oversampling
64 is plenty for now
ok so thats good
when you look at the DAT line
and you blow into the mic, you see it moving more?
nrf_pdm->PDMCLKCTRL = PDM_PDMCLKCTRL_FREQ_Default; // For Ratio64
nrf_pdm->RATIO = PDM_RATIO_RATIO_Ratio64;