#circuitpython-dev
1 messages ยท Page 260 of 1
Hooray closing an issue that was over 1k issues ago! ๐
@solar whale yes, do you want to review it? Scott didn't have time.
i am going to rerun the check because now the sphinx error should go away
ok -- was just going to ask
@solar whale ok build passed now that _bleio is in rtd latest for circuitpython
ok -- just downloaded -- eddystone beacon works!
also tested central/periph demo -- looks good !
@tulip sleet should the current time stuff work with the normal BLE repo or is atha still only in your fork -- having some issues with it.
but my tests may be obsolete
it should work - I tested it, but maybe different test program
i was having trouble with the SSD1306 test, so I changed it to just print
you may need to forget the device in the phone, though I don't think that should be an issue. Or maybe cycle Bluetooth off/on
that works! Thanks
OK -- all my currrent tests still work -- I have not tried HID, but I'll be happy to approve the PR without testing that if thats OK
@tulip sleet would you like me to merge?
Thank you! Yes, so it will be correct. HID is a work in progress. It does work, but I need to add more frills
i'm adding boards to circuitpython.org
OK - merged
@tulip sleet I'm having trouble with SSD1306 as well. 5.0-alpha gets solid green LED with OLED FeatherWing attached to M4 Feather, but my code doesn't start up, nothing on serial/REPL. Tried several working OLEDs. Was working fine with a pre-release S3 build from last week. Everything works fine w/o the OLED.
When I tried an old prog using ssd1306 on CP5.0alpha, it just hung....
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)
``` causes the board to hang
This code causes the board to hang -- run with feather_nrf52840_express and OLED feathering. It was working prior to alpha release
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)
@solar whale yes I had similar problems; not sure if it's a library or a core problem
OK -- I opened the issue in the core, but feel free to close if you want it on the library.
@gilded cradle any idea why this is hapenning now -- I have run this programr many time ins the past but not in the past few weeks. ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.1 on 2019-08-30; Adafruit Feather M4 Express with samd51j19
import slideshow_fs
cat_rug_320x240.bmp Size: 153.7 KB
cats_320x240.bmp Size: 163.3 KB
sibs_320x240.bmp Size: 153.7 KB
skye320x240.bmp Size: 153.7 KB
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "slideshow_fs.py", line 51, in <module>
File "adafruit_slideshow.py", line 200, in init
File "adafruit_slideshow.py", line 323, in advance
AttributeError: 'ILI9341' object has no attribute 'wait_for_frame'
it is a simple use of adafruit_slideshow
DIdn't wait_for_frame() and refresh_soon() get replaced by refresh() in 5.0?
maybe ....
I believe @crimson ferry might be right. I know Scott kept changing it up until he came up with exactly what he wanted.
so -- which library has to be updated?
examples code, certainly
There are a lot of displayio library examples and Learn guides that will need update when alpha/beta settles down
Ok, cool @solar whale
@gilded cradle may take some time -- I found the offending line in adafruit_slideshow.py -- now have to figure out what the new way of doing it is.... reading
hmmm -- just removing https://github.com/adafruit/Adafruit_CircuitPython_Slideshow/blob/master/adafruit_slideshow.py#L323 makes the problem go away -- the slideshow works --- not sure this is the most elegant fix ... I'll keep readin ghte changes and see if taht makes sense.
Maybe you could put it inside a try/except block @solar whale
ok -- looks like it is just not needed anymore in CP5 -- I'll use try/except and put in a PR
@gilded cradle PR submitted -- thanks -- also @crimson ferry thanks for the pointer to the CP5 changes.
Thanks @solar whale
I've run the "playground sound meter" on an Express and a Bluefruit, and it seems to work a lot better on bluefruit. With express it seems like there are frequently noises detected even when the room is quiet. The Bluefruit is also a lot faster at updates, but that is less of a surprise. The spurious noise detections make me wonder if there's a bug of some sort
and then I gave away that cpx to an aspiring young person who's considering comp sci but hasn't programmed yet. what?! how is that a thing!?
Added:
- circuitplayground_bluefruit
- metro_nrf52840_express
- hallowing_m4_express
- pyportal_titano
- monster_m4sk
- robohatmm1_m4
metro_nrf52840_express and pyportal_titano have placeholder .png Eagle board diagrams for now, with minimal descriptions
hmm -- that metro_nrf52840_express sounds like fun ๐
@crimson ferry @solar whale doc is updated, e.g. https://circuitpython.readthedocs.io/en/latest/shared-bindings/displayio/Display.html#displayio.Display.refresh
๐ค
you're welcome! yes, I think so, but there are only 699 assets in the github asset list as opposed to 783 for 4.1.0. Did you adjust .bin vs .uf2 or anything like that? Just finished adding boards to circuitpython.org. You could approve https://github.com/adafruit/circuitpython-org/pull/265 if limor doesn't get to it in a minute: it's just some typo fixes after the bigger new boards PR that she approved
will look at that soon. I bet we're missing some
looks like some of the builds actually failed in upload
rate limit exceeded ๐ฆ
ya, it was a whirlwind but I chatted with all the folks I hoped so it was good
I'll poke those now to see if they work
s3 should have all of the assets already
can you just space out the uploads a bit in "Upload to Release" or is it per hour or something?
it's per hour I think
1,000 afaik
by swapping keys we can get it to 4,000 I think though
Only clue I can add is that I reported on Discord on 8/26 that the latest 5.x build was working fine with OLED FeatherWing... I believe that would have been the 8/22 build 1d973a0. But 5.0 alpha stops user code from starting up if OLED is attached: no serial/REPL/^C. Solid green LED on M4.
8/22 build 1d973a0 re-confirmed works with OLED.
Subsequent builds all have 5.0 alpha behavior.
Between each of the following, I reloaded the working 8/22 build 1d973a0:
8/27 build 42956a6 : user code runs to a point, OLED gets blanked, then hung
8/28 build 7cbae3d : user code runs to a point, OLED gets blanked, then hung
8/29 build 193df55 : user code runs to a point, OLED gets blanked, then hung
8/29 build 8d14266 : doesn't blank the prior OLED display, then runs up to a point, ...
I connected a J-Link to the feather_nrf52840 and OLED -- and rebuilt 5.0alpha with DEBUG=1
The code appers to be executing, that is, it does not hard Fault but the display is blank and
it won't respond to any keyboard input (COntrol-C) does not work
Here is a screenshol of the call stack after loading the oled.py test progrram

this was the REPL
...
well that feels like an hour wasted, still haven't gotten gdb to my metro m4 going, using segger's software or openocd ๐ฆ time to take a break then use print-debugging like a peasant.
I'm certain I did this in the past, but if I did I destroyed the evidence
yay finally got it working. breakfast helped ๐
@onyx hinge working on the PDM noise disparity?
@raven canopy no, I am looking at https://github.com/adafruit/circuitpython/issues/1992
it's weird.
every statement the reporter made where I said "they MUST be mistaken about that" has been true when I checked it. For instance, it actually IS dependent on the samples themselves, even though nothing can possibly depend on that.
Reproduced on Metro M4 express. On my scope, the one trace slowly moves with respect to the other one at a constant rate. Just to add to the findings, if I decrease the sample rate enough (24 * 1000) the problem goes away, at least for this sample data. As the original reporter states, somehow this is dependent on specific sample values, too, which really is a problem for any explanations I might have put forward. Debugging hasn't yielded any insights yet.
Not only is it data-dependent, but for some data combinations the order of relative movement is reversed!
I'm not saying this is related but there's more unexplained, weird stuff going on with these DACs: Adafruit Forums: SAMD51 M4 DAC has problems getting it up
CircuitPython does not intentionally enable the oversampling or dithering modes.
fwiw your stair step on 0-to-65535 I can also reproduce, and the "data dependent" nature of the problem seems to be that when the "stair step" is going on at the moment the buffer flips over, the problem doesn't manifest. weirder and weirder.
Smaller reproducer:
import board
import audioio
import array
import time
X = 8191
Y = 65535
data = array.array('H', [0, 0, X, X, X, Y])
sample = audioio.RawSample(data, sample_rate=200 * 1000, channel_count=2)
a = audioio.AudioOut(board.A0, right_channel=board.A1)
a.play(sample, loop=True)
while 1:
time.sleep(1)
Change the single Y back to X and the waveforms stay in sync. Change another X to Y and the waveforms stay in sync.
With 3 samples per channel and a sample rate of 200kHz, the observed frequency should be (200/3) = 66.7kHz. Instead, I measure ~55.5kHz with [0,0,X,X,X,X], and 12.8kHz with [0,0,Y,Y,Y,Y].
I'm using MicroPython on my ESP32 and would like to use https://github.com/adafruit/Adafruit_CircuitPython_Motor with MicroPython. Is that possible?
@unreal marsh the Adafruit_CircuitPython_Motor library accepts "pwm" objects that are created with "pulseio" which I don't think you have access to in MicroPython
@onyx hinge crawling through the DAC setups between cirpy and arduino, is it possible that this is "simply" missing a 1 (12MHz vs 2MHz)? https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h#L84
@solar whale r/ihadastroke, but thanks
@raven canopy hm I don't see any uses of that macro though
I suppose I can change it, rebuild, and see if it makes some difference unexpectedly ๐
its the initial config for the DAC
i needed a distraction from researching intrinsic CMSIS functions. ๐
OK, let me try it
@unreal marsh I don't think I understand your comment, I may be incorrect so I hope someone else will comment and correct me if I am.
@raven canopy sadly, didn't seem to make a difference.
๐ฆ
Hello..... I am back... I got successful on sound reactive on Neotrellis M4 board. Simply copied the code from https://learn.adafruit.com/sound-reactive-neopixel-peace-pendant/circuitpython-code and edited to suite the board. mic_pin = AnalogIn(board.MICOUT) and n = int((mic_pin.value / 65536) * 1000). The only problem is cannot hear from headphone, just speak into microphone as pixel colors show. I added the line "audio = audioio.AudioOut(left_channel=board.A1, right_channel=board.A0)" ... No luck. How do I get the sound in headphone?
Testing setup: A0, A1 into o'scope. Put some.wav and code.py on CIRCUITPY.
Initially, A0 and A1 both display a signal, but after a short time (2-3s?), A1 stops showing signal. At next soft reboot, A1 gets a signal for the same length of time again.
Tested in 4.1.0 and master on a Metro M4 Express.
Code to create wave file:
import array
from numpy import ndarray
import scipy.io.wavfile
X=4000
Y=65535
a = ndarray((16384, 2), 'h')
print(a)
for i in range(0,16384,2):
...
More testing: I am not having trouble with enumeration with PyRulers on MacOS Mojave 10.14.6.
I added
CIRCUITPY_BITBANG_APA102 = 1
to boards/pyruler/mpconfigboard.mk and rebuilt, and now I appear to get correct colors for CircuitPython (given my limited color vision). The pulsing DotStar when the REPL is running is rather rough-looking: I don't see the same issue on a regular Trinket when setting CIRCUITPY_BITBANG_APA102 = 1. This may have to do with the particular batch ...
This sounds related to the "refresh" needed on the SAMD51 DAC's. Their output needs to be refreshed explicitly by forcing a reconversion, or else the charge will decay away. If you put various pulldowns on A1 I have a hunch you'll see it decay faster depending on the value of the pulldown.
Turning on refresh is done in ports/atmel_samd/asf4_conf/hpl_dac_config.h: CONF_DAC0_REFRESH and CONF_DAC1_REFRESH are both set to 2. But the symptoms above sound like that value is being changed. ...
I will check into that, but doesn't this apply only to static signals? The value is being changed a nominal 100,000 times per second between 0 to 4000 continuously.
Good point. Is the loss of signal abrupt or does it fade down? Abrupt would sound like a DMA problem (if DMA is being used here).
There's also another setting about current (CONF_DAC0_CCTRL and CONF_DAC1_CCTRL). I've not experimented with this, just came across it in the MicroChip docs. Mentioned on: Adafruit Forums: What's fastest practical sample_rate for M4 DACs?
.
This a minimalist SAMD51-based game console board. More information at https://hackaday.io/project/165032
How would I build Adafruit_CircuitPython_PyPortal for circuit python 5.0 ?
@cerulean sparrow you mean the accompanying .mpy files? I am not sure, but I'll try to help.
something I know about generally is that build instructions are in the ".travis.yml" files, so I started by looking at https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/blob/master/.travis.yml
It looks like the key steps are to get the git source, install the dependencies, and then run the circuitpython-build-bundles command
- pip install circuitpython-build-tools Sphinx sphinx-rtd-theme
...
- circuitpython-build-bundles --filename_prefix adafruit-circuitpython-pyportal --library_location .
Just for now, could I just replace the adafruit_pyportal.mpy with an updated adafruit_pyportal.py and skip the compile
In general, yes, you can remove a .mpy and put a .py in its place. The main thing to be aware of, it can increase memory (RAM) usage.
and it looks like on some systems you will have to use "pip3" not "pip", in case "pip" refers to python2
I updated the initial comment with new code and an oscope grab. And just when you got things weird enough, I got this one too:

@cerulean sparrow fwiw I followed those instructions and got a file called bundles/adafruit-circuitpython-pyportal-4.x-mpy-3.1.2.zip -- this file should work on 5.0.0-alpha as well.
I was on a linux computer, it looked like the steps involved compiling software which might only work on linux systems.
@onyx hinge Thanks for the help, I am getting ImportErrror: cannot import IO_HTTP when I run on device even after changing the refresh_soon lines in PyPortal.
You might have to update another bundle called adafruit_io, or go back to an earlier version of adafruit_pyportal.py. I'm 100% guessing about this, but lines referring to IO_HTTP were added recently, on July 23. from adafruit_io.adafruit_io import IO_HTTP, AdafruitIO_RequestError and maybe the copy of adafruit_io on your pyportal is older.
as a note, there are pre-compiled versions of mpy-cross available in this release: https://github.com/adafruit/circuitpython/releases/tag/3.1.2 (it still works with CircuitPython 4.x [and i expect with 5.x])
ugh, almost daily on this computer, subsequent to a circuitpython hard fault, the whole computer stops seeing usb hot plug events and I have to restart. (linux, some old AMD box I had laying around). kernel messages implicate efi.
and it's happened again, so a reboot is in store before I can click anything
yeah bad usb can ruin your day
it makes me wish for a PS2 mouse (my keyboard is a PS2 "Model M" still plugged in on that vintage connector)
nice
I'm using an ibm ps2 keyboard but not a model m lol
a govt surplus near me has boxes of old mice and keyboards
you could probably find a ps2 mouse easily enough at a thrift store or something
Moved the dithering logic as suggested in previous PR to the ColorConverter. This will allow dithering to be done on any 24 bit source bitmap. It can easily be turned on by using the python code board.DISPLAY.dither = True, and uses the ColorConverters bitdepth to correctly add the dithering.
Further testing:
I changed the pins used for MICROPY_HW_APA_MOSI and _SCK to be the pins assigned for board.MOSI, and board.SCK, and took those pins out of general use. I attached an external DotStar strip so its first DotStar would take the place of the onboard one. It appeared to work fine, and pulsed green smoothly.
I went back to the onboard DotStar and tried changing the SPI clock rate up and down by one and two orders of magnitude, and tried other combinations of polarity ...
I forced the MOSI and SCK lines to high drive mode, and I get the stuttering green pulsing. This makes sense, because bitbangio uses DigitalInOut, which forces high drive.
Most interestingly, if I probe the clock line with a jumper or other lead, but unconnected, then the pulsing also settles down to a somewhat weak pulsing. I think the added capacitance is reducing some noise or ringing. Doing the same on a regular Trinket M0 has no effect.
This makes me pretty suspicious that this is ...
I think the SAMD51 has a pseudo-differential mode for the DAC pair? When I saw that in docs I realised bugs around that area could be a cause of _som_e of these coupling-related oddities but there seem to be so many strange quirks that defy an obvious explanation. I did a quick check of the SAMD21 on a CPX a few months back and it's so clean and predictable! It's as if there's a poltergeist in the SAMD51's DACs.
I wonder if we should take Malvin's advice and start at the beginning? Even at first use the SAMD51 DACs used from CircuitPython behave strangely with #1991 .
@prime flower I have the ESP_ATcontrol library now working with adafruit_requests. All of the examples work and I have tested some of the AdafruitIO examples to without any problems (http/simpletest and weather work). I have also modified the ATcontrol examples to only have the Argon configurations. I think any other boards should use the ESP32SPI firmware. I think I'll go ahead an PR this later to day after a few more tests. I also want to add the get_MAC function, but that can be a separate PR. Next, I was going to take stab of adding ESP_ATcontrol to the miniMQTT library. I'll let you know how it goes.
@tulip sleet We need to create a 5.x bundle now that 5 is released. Not sure what goes into that.
I'll look at that sometime soon, maybe today
@tulip sleet Sounds good. Please let me know when you do, I have a guide waiting on it. (No rush, would simply like to know.)
@tulip sleet @idle owl we could possibly extend the VERSIONS dict to include an option for pre-release, and pass that into the build script: https://github.com/adafruit/circuitpython-build-tools/blob/master/circuitpython_build_tools/target_versions.py
Oh hmm. Yeah.
oh...and this was already done: https://github.com/adafruit/circuitpython-build-tools/pull/47 ๐
just needs a merge.
@raven canopy ๐
as it stands though, that won't include the pre-release BLE library (just to clarify).
afk: its waffle house time with the kiddo & nephew
@raven canopy Delicious!
made a quick issue before leaving: https://github.com/adafruit/circuitpython-build-tools/issues/49
@idle owl how do you feel about dropping the 3.x bundles as done in https://github.com/adafruit/circuitpython-build-tools/pull/47?
@tulip sleet I wasn't sure if we should wait until 5.0 is actually released or not. We plan to support "one previous version" but since 5.0 is still alpha, I'm not sure it count yet.
the latest wave of I2C changes still work on 3.x, right?
Oh I don't know. Scott makes a good point on them not working.
I'd say let's dump it. I already changed all the warnings to "latest" instead of a particular version number.
We're going to dump it in a month or so anyway.
LET'S BREAK EVERYTHING.
i'll ask again after you've had lunch.
๐
We'll need to create the Troubleshooting/FAQ section for CircuitPython with static links to the last set of builds.
we could also add that to circuitpython.org/libraries
i kind of agree that 5.0 alpha is barely a version yet
but we do want to encourage testing
That was my thought. On both counts.
I think having easy access to the last 3.x bundle is a good compromise, for people who need to update but can't move on to 4.x yet for whatever reason (like they have 30 CPX's in a classroom or whatever)
OK, so steps:
- accept #47 to start 5.x bundles and stop 3.x bundles
- Notify support.
- Put links to last bundle in circuitpython.org/libraries (PR) and guide (edit)
the order to do might not be that order
i have to go out for a few hours; should we try to do this today or not?
the 5.x bundle will be imperfect (like wrong BLE), but that's a hazard of being an alpha tester and the solution is not easy
@tulip sleet I think we can do it today. I'm on a train until 13:15 and then again from 14:20-18:20 so we can look at it later and figure out everything.
Hi all, just a reminder that our weekly meeting is a day later than normal because Monday is a US holiday. So, the meeting will be on Tuesday September 3rd at 11am Pacific / 2pm Eastern here on Discord. Everyone is welcome to attend. If you are unable to make it and want to drop us notes, the notes doc is here: https://docs.google.com/document/d/1r-F78z5lRl91G4kM6VzajSn2i7hdUUyp-jCiegHs7MA/edit?usp=sharing Thanks! <@&356864093652516868>
Unfortunately, I've been unable to find any audio issues that are resolved by this PR. Given this, is it worth getting this out of draft status?
Hi All, thank you to this channel for the help with my latest project, a LoRa remote running CP. I posted it on Reddit with all of the details, like the current source, 3D printing files, etc. Thank you to the entire Adafruit Discord group- this is an awesome community! https://www.reddit.com/r/3Dprinting/comments/cy3c72/i_made_a_3d_printed_lora_remote_control_details/
hmm are my expectations for the debugger too high? (gdb) p $1->DACCTRL[0] $60 = {bit = {LEFTADJ = 1, ENABLE = 1, CCTRL = 1, FEXT = 0, RUNSTDBY = 0, DITHER = 0, REFRESH = 2, OSR = 0}, reg = 519} (gdb) p $1->DACCTRL[0].bit.CCTRL = 0 $61 = 0 (gdb) p $1->DACCTRL[0] $62 = {bit = {LEFTADJ = 1, ENABLE = 1, CCTRL = 1, FEXT = 0, RUNSTDBY = 0, DITHER = 0, REFRESH = 2, OSR = 0}, reg = 519} (gdb) I can't seem to modify CCTRL. some register accesses definitely happen, such as writing to the DAC register directly $1->DATA[0].reg = ###...
though attempting to read back DATA[0].reg also results in an unchanging value
try disabling the DAC, changing the val, then re-enabling the DAC? sheet says that the register is enable-protected.
oh that makes sense
only knew to look because i've fought it before ๐
Okay! CCTRL does affect the weird stair-steppy thing
CCTRL=0
CCTRL=1
CCTRL=2
Switching to bandgap reference reduces the number of steps, they each have the same absolute (voltage) height
ahh! i was missing a link with my DAC frequency suggestion yesterday. it should match the CCTRL range. ๐คฆ
DAC under arduino (should be same time scale)
yeah same time scale
so something must be wrong that is fixable in CP
the only difference i could really see was that frequency setting (2MHz vs 12). both use DFLL as the source...
where is the code that actually USES that #define you pointed out? Is it getting called / used at all in CP?
OK, is that a part of the source code where grepping for that identifier should have found it? That's how I usually find things, and came up empty..
or is it something that is generated in some other way?
DAC0.CCTRL: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/asf4_conf/samd51/hpl_dac_config.h#L54
DAC1.CCTRL: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/asf4_conf/samd51/hpl_dac_config.h#L93
DAC GCLK FREQ: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h#L84
after changing that last file, is there something beyond a normal "make" to do?
not that i know of.
when I made this change, CP still built...! ```diff --git a/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h b/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h
index 41efca755..08eec2663 100644
--- a/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h
+++ b/ports/atmel-samd/asf4_conf/samd51/peripheral_clk_config.h
@@ -81,7 +81,7 @@
- \brief DAC's Clock frequency
*/
#ifndef CONF_GCLK_DAC_FREQUENCY
-#define CONF_GCLK_DAC_FREQUENCY 2000000
+#define CONF_GCLK_DAC_FREQUENCY "I don't believe sommersoft"
#endif
// <y> EVSYS Channel 0 Clock Source
yes
๐ค maybe that's all unused now?
I can confirm that file is still included in places
and some similar #defines are used common-hal/analogio/AnalogOut.c: _gclk_enable_channel(DAC_GCLK_ID, CONF_GCLK_DAC_SRC);
GCLK5 is 48MHz/24 = 2MHz
there are two config locations. atmel-samd/asf4_config & atmel-samd/asf4/config. i could've sworn that the first is used in lieu of the second.
#define CONF_GCLK_GEN_5_DIV 24
asf...such a layer cake. ๐
Only LEFTADJ and CCTRL registers (within the DAC) differ
scrolled past this like 6 times: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/Makefile#L76 so its weird that "I don't believe sommersoft" didn't throw an error.
well if I change say the CONF_GCLK_GEN_5_DIV line to say "I do believe summersoft", it gives an error where the macro is used.
but setting that divisor from 24 (48/24 = 2MHz) to 4 (48/4 = 12) didn't make a difference either
time to take another break from this ๐
breaks are good.
assembly math is not as fun as it looks. especially when you only have a rudimentary understanding of binary. thank the deities for mp_printf.
hmm. well, 16bit unsigned multiplication is working. but the amplitude is higher than its signed counterpart. progress, i suppose.
@onyx hinge @raven canopy other people's DAC difficulties: https://www.avrfreaks.net/forum/help-getting-dac-working-samd51 also maybe drag @simple pulsar into this ^
@onyx hinge @raven canopy don't feel constrained to using the ASF library. If you want to code it in straight registers, that is fine. We'd like to gradually move away from ASF
@tulip sleet you got a moment? i have a "is it worth it" question wrt to audiomixer & asm/CMSIS functions...
sure
ok. so, i've got all of the addition functions using intrinsic CMSIS. but, for the multiplication, there really aren't any options for non-16bit & unsigned. since i have the C functions working, is it worth it for me to push on [learning] the asm equivalents? (they could conceivably be used with arm-v7 and arm-v6)
when is multiply used? I think it's not important to do the asm stuff now, and you can also ignore the C functions for M0, since we aren't planning to enable mixer for M0
multiply is used to adjust the level/gain of an individual voice.
it's pretty easy to check that multiply is out of range and limit it, right? You are always multiplying by a positive number, so there's less sign-checking
yeah, they have boundary checks, according to signedness.
using <limits.h>, so SHRT_MAX, SHRT_MIN, etc...
The q is just whether to mess with
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 #16" : "=r" (val) : "r" (lo), "r" (hi)); // pack
kind of stuff?
right. that one, 16bit signed, has a armv7 shortcut (SMULWx) . but there's nothing for 16bit unsigned, or 8bit anything.
i have 16bit unsigned "working"...but its super loud. ๐
I think it's fine to omit the asm stuff. You could comment it out as "not working on M4" or something if you don't want to lose the info
which is ironic, since the space/time savings benefit M0 more. hehe
yes, but we can barely do audio in M0, and we are just running out of space constantly
alright. i'll remove audiomixer from M0 altogether then. i was only chopping off the overruns board-by-board.
and combing armv6 instructions...i have less hope:
The only multiply instruction supported in ARMv6-M performs a 32x32 multiply that generates a 32-bit result, see MUL on page A6-143. The instruction can operate on signed or unsigned quantities
in the long run these functions might be in their own library (not Python library, but a separate file), or even a separate repo.
I'm not sure if you can use these: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
Using the GNU Compiler Collection (GCC): Integer Overflow Builtins
whether you can use 16-bit types or not with those
whether type1, type2, type3 can be <32 bits, but I think so
@raven canopy this compiles with arm-none-eabi-gcc:
#include <stdint.h>
uint16_t f(uint16_t a, uint16_t b) {
uint16_t c;
__builtin_add_overflow(a,b,&c);
return c;
}
so you can use those functions, check if they return true or false. If true there's been an overflow and you can range-limit
i don't know how efficiently they are implemented, but hopefullly it's good
i imagine the add/sub compile closely to the armv7 instructions. e.g.:
uint32_t __UHADD8 ( uint32_t val1,
uint32_t val2
)
This function enables you to perform four unsigned 8-bit integer additions, halving the results.
Parameters
val1 first four 8-bit summands.
val2 second four 8-bit summand
the muls will be the possible benefits. i can def give it a whirl.
you could try them for the addition cases too, but the built-in saturation operations should be a lot faster, since there's no checking. But these would work on M0 with checking if we ever wanted that.
been reading. thanks for the pointers and discussion, @tulip sleet!
thats up to @tannewt im ok either way
Based on this looking "right" in an Arduino environment, I am hoping there's just some spot of setup that we've missed. Unfortunately, I think I've ruled out everything in the DAC's registers. Moving on to clock setup now, h/t @sommersoft
well this comment seems wrong``` // SAMD21: This clock should be <= 12 MHz, per datasheet section 47.6.3.
// SAMD51: This clock should be <= 350kHz, per datasheet table 37-6.
_gclk_enable_channel(DAC_GCLK_ID, CONF_GCLK_DAC_SRC);
New state of things accounting for all of this, plus the move to audiomixer:
audiomixeris turned off completely for M0. This is a breaking change toaudioio.Mixer.- ARMv7M intrinsic functions are used where available (all addition functions, and 16bit signed multiplication). Also changed the pre-processor flags; the intrinsics used are in CMSIS-M, not CMSIS-DSP.
- C functions are used where intrinsic isn't available. They are also available as alternates to supported ARMv7M int...
This is ready for another look. I'm going to update the original PR comments with a summary for release notes.
@jepler please take a peek!
Fixes #2064. New batch of DotStars on PyRulers didn't work with old code. Previous DotStars were much more tolerant of non-spec writes.
- Trailing 0xff bytes were omitted in previous DotStar writes. Now 4 are used. Could maybe get away with 1 (Arduino library does, after experimentation), but safer to use 4.
- Add constant for write buffer size and length of writes. Previously some writes were 8, some were 12.
- SPI polarity corrected (doesn't work on PyRuler DotStars otherwise).
- Incr...
didnt test on hardware, but looks good to me!
Turns out not a board hardware problem, but new DotStars were not tolerant of off-spec writes.
@siddacious If you still have enumeration issues on MacOS, could you open another issue? Thanks. Dropping that from this issue.
Tested on PyRuler (two samples), Trinket M0, Itsy M0, and Itsy M4.
Debug print snuck in! Will be removed in next push...
You are likely to have already observed it or read it, but when I last looked it wasn't clocked fast enough to get the higher rates, 3rd post in https://forums.adafruit.com/viewtopic.php?f=60&t=153797#p759051
@tulip sleet will the dotstar fix go into master soon? Just curious if I should do it locally or wait for merge.
@solar whale I was going to prepare a merge soon - was going to check if there was anything else to add to 4.x and then merge back
Thanks -- no rush -- just curious about the plans -- Nice job - finding/fixing that! ๐
Tested on PyRuler and Gemma_M0 -- works fine!
This improves the behavior around #1992. The samples stay in sync now, though full scale changes still behave erratically.
Testing performed: On a Metro M4, with both analog channels going to a scope, I looked for synchronization and waveform shape.
Original reproducer: Stays synchronized.
https://github.com/adafruit/circuitpython/issues/1992#issuecomment-526847786 reproducer: Stays synchronized and plays at the nominal 100kHz sample rate. However, waveform peaks are "regularly irre...
Obviously I feel quite uneasy about this and wish I had more answers.
Here's how the DAC looks with the sequence [0,65535] repeated forever:

Something's obviously still quite wrong with how the DAC or its clocking is set up.
lol - out of curiosity, do you have a 'mimic' set up with arduino for this kind of output? what if you do [0, 1000] is it the 65535 thats messing it up?
@ladyada The screenshot above is from a CircuitPython program with my patch:
import board
import audioio
import array
import time
X = 4000
Y = 65535
data = array.array('H', [0,0,Y,X])
sample = audioio.RawSample(data, sample_rate=100 * 1000, channel_count=2)
a = audioio.AudioOut(board.A0, right_channel=board.A1)
a.play(sample, loop=True)
while 1: time.sleep(1)
My arduino program:
void setup() {
pinMode(A0, OUTPUT);
}
void loop() {
analogWrite(A0, 0);...
๐คทโโ i just play 20khz max audio thru this thing :D
The rise/fall rate seems to have to do with the CCTRL register:
Bits 3:2 โ CCTRL[1:0] Current Control
This field defines the current in output buffer according to conversion rate.
One thing I notice is that when doing analogWrite, Arduino does this:
while ( !DAC->STATUS.bit.READY0 );
while (DAC->SYNCBUSY.bit.DATA0);
DAC->DATA[0].reg = value; // DAC on 10 bits.
in CP Analog...
@ladyada I think 20kHz sample rate audio works pretty good, especially if it's also mono. Stereo, very high sample rates, and unusual waveforms are where the problems @kevinjwalters reports seem to enter the picture.
hum now what do I do? After returning from Arduino to CircuitPython, my files are gone (OK, not a surprise) and storage.erase_filesystem() isn't giving me a sane filesystem to work with (ouch) ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-282-ge7c3017c9-dirty on 2019-09-02; Adafruit Metro M4 Express with samd51j19
import storage
storage.erase_filesystem()
cu: Got hangup signal
Disconnected.
jepler@soba:~/src/circuitpython/ports/atmel-samd$ cu -l /dev/ttyACM0
Connected.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-alpha.0-282-ge7c3017c9-dirty on 2019-09-02; Adafruit Metro M4 Express with samd51j19
import os
os.listdir('.')
['\x02\x0b\x0b\x10\x1b\x0b\x11\x10.\x10\x18\x10']
Any suggestions?
hm, flashing back to 4.1.0 got me a CIRCUITPY device. hmmmm
something to do with my clocking changes? sigh/argh.
something generally wrong in master branch, ditto
afk
@onyx hinge running an Arduino program on an Express board should not generally disturb the SPI flash chip, so yes, something else. It may have gotten corrupted earlier.
Updated the link to the store where it is now possible to buy uChip and the picture with the final revision.
looks like there's a conflict - once its fixed we can merge :)
Thanks for the support!
I noticed that the folder structure for the pictures changed since the last commit we did.
Should we change our branch accordingly or is someone else already proceeding?
Thanks
you'll need to change your branch/commit
@tulip sleet Considering that _bleio shouldn't be used directly anymore should a function be added to adafruit_ble to return the MAC address?
@subtle sun sure, please file an issue in the library
i expect there will be other such things
Will do
Tested with a board I'm working on :)
The build failed but that doesn't seem to be my code's fault :sweat_smile:
msgfmt: error while opening "build/genhdr/en_US.mo" for writing: No such file or directory
../../py/py.mk:320: recipe for target 'build/genhdr/en_US.mo' failed
make: *** [build/genhdr/en_US.mo] Error 1
Seeing an interesting bug, need to investigate more:
>>> import board, busio
>>> uart = board.UART()
>>> uart2 = busio.UART(rx=board.RX2, tx=board.TX2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid pins
** reset **
>>> import board, busio
>>> uart2 = busio.UART(rx=board.RX2, tx=board.TX2)
>>> uart = board.UART()
ah i see, so uart2 can only be on 1 sercom but uart can be on 2, so if i init uart first then it uses the sercom that uart2 can use but the other way around uart just uses the second one
hope that made sense heh
so it can't really be fixed cause it's kinda board specific
like could reorder sercom lookup table but then it might break other boards that use a different pin config
Had some cycles, so dug a little deeper into item one of #2021.
In looking at the html source, the docs/static/customstyle.css wasn't being used, which explains why the override workaround wasn't working. Verified this with a local build.
This change produces an inclusion of the custom CSS in the html head:

@indigo wedge limor calls it "pin sudoku" (also applies to choosing which pins to expose on a board with limited pins)
@arturo182 I simulated the build on my own machine and didn't see this issue. I re-ran the build a couple of times and now it's failing even earlier, not being able to find a commit. I'd guess there are some issues on the GitHub Actions side; we can try again in the morning.
@minor plume @plucky flint is working on a cli updater. repo for it is here: https://github.com/ntoll/circup
@slender iron I will take a look next week after my move, and see if it is something I can contribute to. No point reinventing the wheel.
we've got lots of things we could use help on so no worries there ๐
Iโm looking forward to getting more involved, once I have this move behind me. ๐
Sounds good. ๐
No worries, this is not a high prio commit, just wanted to have it here so I don't lose track of it :)
Sorry for not being up to date, but when is CP V release planned? So I can make sure my board gets in there ๐
@slender iron @minor plume please don't hesitate to give feedback, critique and ideas. Thanks! ๐
Apologies to those module maintainers for whom I've created a bunch of __version__ and __repo__ metadata issues and PRs on GitHub. Please feel free to ping me with questions if that would be helpful. Thanks!
good morning! I hope I'll make it to the weekly meeting today, but it depends if somebody at DAY_JOB thinks they already have me scheduled at that hour.
I don't see a 5.0.0alpha1 built for PyPortal (I just see one for the titano)
I tried re-rerunning this morning and the check-run again failed trying to find a commit. I made a trivial typo fix to force a new commit and new check run, and it worked.
Thank you for the addition!
@umbral dagger the uploading of builds to S3 got rate-limited, so there are some missing build. You can try a newer build of master; it should be fine
@indigo wedge there is no schedule for CPy 5: we have some goals we are shooting for (like BLE workflow) that are a stretch. But submit your board when you can and you should probably have a usable build with the new displayio updates, since the instability will be in areas that you probably aren't relying on.
yeah i just pulled master yesterday and flashed that, worked without problems ๐
oh you merged, nice, thanks ๐
Same issue as reported in #2064. Didn't fix itself.
hah just spotted this in the draft meeting notes. jealous, @solar whale "@solar whale (not able to attend -- off in a canoe)"
What version are you running now? I was unable to reproduce on a Macbook with USB-C-to-USB-A adapter, running 10.14.6. And is this latest master or 5.0.0-alpha.1, or 4.1.0?
Does it work fine on other machines? Do you have another Mac to try it on?
@stuck elbow stage q on the forum: https://forums.adafruit.com/viewtopic.php?f=60&t=155961
@tannewt somehow capturing the rotation (for later return via the property) got lost. This PR fixes that.
@slender iron thanks
doh... https://github.com/ntoll/circup/issues/7 (I've fixed this now)
@onyx hinge hihi lemme nkow when ur around
@meager fog what's on your mind?
@meager fog let me get signed in and look...
@meager fog You mean, do I have suggestions for new items to add?
those both sound like good ones so far
I went ahead and added "M4 DAC Weirdness". Not sure if you were following the progress, but I started to find some difference between Arduino and CP and fixing them made CP better...
not sure how far down the road you want me to look, but I think there are some things around time measurement and timekeeping that would be good to look into
my yet to be posted meeting notes include the exact term "M4 DAC weirdness". coincidence? ๐
No, it's an unseen hand guiding us both
@meager fog just based on my time availability between now and mid-november, these 3 items might account for it all
Should I feel free to add items to this list, then?
@onyx hinge yes! its for u!
OK, I figured it was for you
its for both of us ๐
so for the M4 weirdness... if the same weirdness happens in Arduino its probaly cause the DAC itself is weird
because it is a little weird. its got errata
Actually under Arduino with AnalogOut, the DAC seems to work pretty well
ok
do you want to try to keep hacking on that for the next few days?
i put in a few other dac/adc-y issues
the specific "stair step when setting DAC from 0 to full scale" doesn't happen on Arduino and it is a cause of at least one other issue (audio synch)
I actually wanted to switch gears to I2S Out as soon as I got the hardware, because I banged my head on the DAC all weekend and didn't get very far
though I did start to make some progress, as I mentioned, it's still bleeping weird
@meager fog would you prioritize the dac bugfixing above nrf I2SOut, assuming I was sure I could bring one or the other to a conclusion before my travel starts late this month?
@onyx hinge ๐
back!
in the context of the samd51 errata, what does 'efp' mean?
(errata are divided into 'efp' and 'non-efp')
enhanced floating point? ๐คท
@slender iron @meager fog @idle owl quick question about naming conventions for release tags for CircuitPython module repositories... such tags will always be valid semver values..?
excessively fiddly procedures
@plucky flint They should be yes, if they are not, they should be fixed.
....and somehow (how? CI presumably) the __version__ in the actual source file is updated from 0.0.0-auto.0 to the value of the semver tag.
right, it's in the bundle building python scripts
@idle owl ๐
Hi all. I wonโt be fully on the call today, but I want to throw out an idea about a directory of the CircuitPython community. Maybe an online spreadsheet with: whoโs working on what, relationship to Adafruit, general bio, professional and personal, twitter handle, YouTube channel, LinkedIn profile and the like, geographical location. Opt-in, community-maintained. To help a newcomer like me get oriented and make connections for collaborating, contributing, and the like.
Aha... @tulip sleet where are these scripts (just so I can check how it's done, so the result is correctly handled by circup)..?
defer to @raven canopy here
@plucky flint for version specifically: https://github.com/adafruit/circuitpython-build-tools/blob/master/circuitpython_build_tools/build.py#L90
lurking today
@raven canopy stonking! Thanks!
I keep being impressed by the toolng around CP that I didn't even realize existed...! @raven canopy
gonna go grab more water
brb as well.
(lurking,)
water refill. good idea...
meeting starting momentarily
@raven canopy cool... it's nice and simple... ๐
๐ฐ
lurking
@onyx hinge i've mosly only added to stuff. Scott did most of the original stuff akaik
Hi all
lurking
I'll be lurking today also
and hello
We can hear you @slender iron
@slender iron It turned out that the storm stalled out over the bahamas so it is not going to directly hit us in wpb
hurries to finish bowl of crunchy cereal
Do you think it would speed up cirpy if it had type hinting?
** lurking ** (but will decloak for in the weeds)
Go to adafruitdaily.com to subscribe
@marble hornet with my understanding of type annotations/hinting, no. they aren't actually "used" by CPython to enforce static typing. they're more for allowing people & IDEs to help identify type mismatches.
Meet Device Simulator Express:
https://www.microsoft.com/en-us/garage/blog/2019/08/adafruit-and-microsoft-garage-interns-team-up-to-create-device-simulator-express/
https://www.microsoft.com/en-us/garage/profiles/device-simulator-express/
https://blog.adafruit.com/2019/08/29/meet-device-simulator-exress-pythonsim-a-msftgarage-project-built-by-garage-interns-that-makes-it-easier-to-program-the-adafruit-circuit-playground-express-in-python-with-or-without-a-physica/
This summer 16 groups of Garage interns tackled interesting engineering challenges ranging from making apps more accessible to VR solutions for cybersecurity. One of them was sponsored by the Python Tools for AI team and electronics paragon Adafruit to and set out to make pro...
Device Simulator Express is a VSCode Extension that allows people to program and simulate an Adafruit Circuit Playground Express device in python as well as deploy the code to the device if the device is present.
@raven canopy i see what you mean. Iโm sure the people at pypy make great use of it too
Lurking. And getting excited about this Device Sim Express.
Awesome Jeff
I'll be writing up some more on device sim in the next day or so
Dave
Great, Mike. I look forward to it. I was gonna install Mu Editor for my classes, but perhaps VSCode with the new plugin is the way to go.
@slender iron I'll need to leave in 10mins (it's 7:30pm here and I need to pick up kids from places at 8pm)
+1
thank you
Funnily, I'm kind of liking Mu Editor.
@onyx hinge that's the one... thank you!
Ethernet! Great work @prime flower
@turbid radish Blocked on it! But once it gets unblocked, it'll be finished pretty quickly ๐
All good!
@wild flare thank you..! ๐
@onyx hinge thought i heard "M4" and "DAC" oddness?
๐ ok folks, I have to shoot off for dad taxiing duties. Hopefully next time I'll be around longer..! Take care folks.
@ionic elk I am also working on a general PR for turning USB and USB HID devices on and off for a particular build. Hope to submit this soon.
motivation is to support a particular gamepad for assistive technology
not done yet (need to do some more work on more flexible definition of HID report buffers, and removing Report ID when there's only a single device
@tulip sleet gotcha! That should be handy I'll take a look.
We should also check in with Thach about the status of USB on the 412
@idle owl please run for a bit
@slender iron Already on it.
nRF datasheet: "Important: For more information on Standard drive, see GPIO โ General purpose input/output on page 155. Low frequency I/O is signals with a frequency up to 10 kHz." wow that really is less than ideal
it's not that those pins don't work at higher frequencies - it's that they add noise to radio reception
ah, interesting
so it's a recommendtaion
they are too close to the antenna pins or internal circuitry or something
right, that's what I was thinking
** IN THE WEEDS **
- NeoPixel related:
- remove bpp?
- is the automagic white channel thing good?
you mentioned sequential in a port but if bit-bang, doesn't need to be sequential, right?
@pastel panther have you seen the arduino multi-tasking learn guides?
@onyx hinge llol ๐
@pearl notch ๐
hang on
๐ฟ
@onyx hinge hi back for 30 min if u have any questions
Good place for the directory? Google Drive? Github requires approvals and merging, might be too much overhead?
@pearl notch GitHub would be ideal, and would create a situation where we have an approval process, but we could also add collaborators to it so it's not on one person to merge everything. Google Drive would also work though - probably the simplest option for now.
Actually Japanese works on gameboy
they just have around 90 characters for it
hiragana only
Also GitHub would require understanding Markdown or something to format the info.
For Hack the Future we create a Drive sheet and mentors signing up for an event add a row with their info, filling in whatever theyโre comfortable with. Works well. Has versioning.
@pearl notch as kattni sez, anywhere would be a good start but something with tie-ins to something else and a approval process to prevent defacement would be nice
the trick is to spell out the kanji characters in hiragana
Weโve had no abuse at HTF, but this is a more visible community.
@pearl notch If you're feeling fancy, could do a Google web form or whatever they call it that dumps into a spreadsheet.
Thatโs nice, I use those with students. Have to deal with duplicate rows. Letโs consider.
@pearl notch You're starting it, you get to decide on where to start ๐
4180 bytes free in flash out of 188160 bytes ( 183.75 kb ). (english)
1676 bytes free in flash out of 188160 bytes ( 183.75 kb ). (zh_Latn_pinyin)
Adafruit should create the document under its account (rather than mine).
msgid " File \"%q\", line %d"
msgstr " Wรฉnjiร n \"%q\", dรฌ %d xรญng"
@pearl notch I don't see this getting so unwieldy that would prevent manual curation/merging, at least not anytime soon
Good point, @pastel panther
And ideally by the time it does, we have a lot of collaborators on it who are willing to help.
@idle owl maybe you could create a Drive folder under an Adafruit Google account, and give me access, to create the form and the sheet within.
we can use a different character encoding, like shift-jis for the japanese
utf8 is very bad for Japanese and Chinese
@pearl notch I'll look into it. Please send me an email with the details.
can we compress it away anyway? @stuck elbow
sure, but with such short strings I'm not sure how well it would work
right
arguably using a different encoding is a kind of compression ;-)
true true
@idle owl if you prefer Iโll create it under my account, and we can transfer ownership later (if the experiment succeeds).
bye everyone!
@pearl notch No I think it makes sense to begin it on an Adafruit account. Simply a matter of which one.
thanks everyone! have a great week!
@meager fog thanks but I'm already pushing my day job schedule today. I have plenty to keep me busy for now and we can figure more out down the road if that's okay with you.
@onyx hinge yep all good
@slender iron The basic example for NeoTrellis (the neopixel 4x4, not the Express) fails with Traceback (most recent call last): File "code.py", line 49, in <module> File "adafruit_neotrellis/neotrellis.py", line 89, in sync File "adafruit_seesaw/keypad.py", line 74, in count File "adafruit_seesaw/seesaw.py", line 372, in read8 File "adafruit_seesaw/seesaw.py", line 383, in read File "adafruit_seesaw/seesaw.py", line 383, in read File "adafruit_bus_device/i2c_device.py", line 96, in readinto OSError: [Errno 5] Input/output error
Failing on the trellis.sync() call. If you add a red LED lighting up to the main loop, it still lights up even if it's after the sync call, implying to me (I think) that it's not failing on the first time through the loop. Which feels familiar as a bug we dealt with before, but I can't place it. Ring any bells for you?
no bells here
blergh. Ok.
I thought I2C failing on subsequent loops was a bug we ran into with something.
Faint recollection anyway.
ya, maybe
need me to get back to work on
busio.i2c? ๐
woo cp5...does it have timer intr callback? ๐
jk, my first attempt is a direct translation of the C which probably has few if any safety benefits
@slender iron I had JP try it on 3.1.2, the code works. It fails on 4.x and 5.x. Do you think it's a lib bug or a CP bug? Trying not to do what usually do and make assumptions here.
Why introduce these two structs? The output contains no new data and the input could be params instead.
Thank you for this rework! I like having dither as part of the color space but am not sure it should be a writable property. A kwarg to the constructor would be enough.
One question about the added structs.
@ruby lake no, no concurrency
mm
@idle owl could be a CP since it works on 3.x
I think it's an improvement and that we should just submit it.
I wonder if the issue is due to RAM contention where cp is waiting on a conditional bool value and starving the audio dma. I think the gameboy suffers from this.
Hooked up a NeoTrellis board to a Feather M4, tried basic NeoTrellis example code found here: https://learn.adafruit.com/adafruit-neotrellis/circuitpython-code
Code runs through the light test, then hangs, or allows a couple button presses before hanging.
Error:
Traceback (most recent call last):
File "code.py", line 49, in <module>
File "adafruit_neotrellis/neotrellis.py", line 89, in sync
File "adafruit_seesaw/keypad.py", line 74, in count
File "adafruit_s...
Please add it to the list of boards in .github/workflows/build.yml. Not sure why it didn't run for you at all.
Thanks! Have you done a diff of the DAC's registers between CircuitPython and Arduino? I'd be curious if it shows anything.
@tannewt don't merge yet, I think this change may have adversely affected sqpi flash I/O and need to do further checking to exclude that theory. Yes, I do have a diff of DAC registers but it's not handy. Ping me again if I don't attach it.
Kk, looks like it didn't run the checks either...
Thanks! Have you done a diff of the DAC's registers between CircuitPython and Arduino? I'd be curious if it shows anything.
Huh I wonder why it didn't run checks.
@slender iron is it because my PR is from before the switch to gitlab actions (has a .travis.yml file)?
ah, ya. could be
hello
ok, so this worked out before, we got "code + community = CircuitPython" ... so let's this again!
@idle owl ...
๐
these will be for Circuit Playground Bluefruit
Circuit Playground Bluefruit is our third board in the Circuit Playground series, another step towards a perfect introduction to electronics and programming. We've taken the popular ...
everyone else feel free to chime in ๐
Get the BLUES! Circuit Playground Bluefruit ๐
Adafruit + Bluetooth = Bluefruit + Adatooth?
hah
this is for the banner we'll do, so we need to say what it is and maybe something fun with the fact it's wireless, BLE
๐
Fun without boundaries?
coding untethered
I will do that, but it seems like the stage library stopped displaying anything in the latest version, so I need to debug that first.
@river quest BLE is on a roll; it's a Bluefruit Playground;Bluetooth at the Playground; Bluetooth on the Playground [or BLE or Bluefruit]; BLE Merry-Go-Roundl BLE Carousel
@slender iron any idea what might have broken stage this time?
@tulip sleet the oled still isn't happy. found it with the hidden testing
@stuck elbow which pr broke it?
i didn't test it; i thought you probably had done so
the displayio overhaul, I assume
I tested that it no longer hanged ๐
but it doesn't correctly show anything. I got a negation wrong
I didn't test every PR, I will try to narrow it down tomorrow, but I was hoping you would have an idea
@stuck elbow I was hoping my changes were enough to keep it working but obviously didn't test it
obviously
which display are you using and what bus?
ST7735 4wire
if you don't have a suggestion, I will do a proper debugging session with a logic analyzer tomorrow
it keeps displaying the console instead of the things I'm sending to it
so it's similar to how it was last time
ah, how do you turn the console off?
as if the display didn't get any commands
well auto refresh will keep sending the console to the display unless you turn it off
I did turn it off
how?
1.0f, // brightness (ignored)
true, // auto_brightness
false, // single_byte_bounds
false, // data_as_commands
false, // auto_refresh
20); // native_frames_per_second
but wouldn't there be at least blinking?
I'm more suspicious about:
display->core.send(display->core.bus, DISPLAY_COMMAND, CHIP_SELECT_TOGGLE_EVERY_BYTE, &display->write_ram_command, 1);
what is that CHIP_SELECT_TOGGLE_EVERY_BYTE for?
it's for some displays that need a cs toggle every command byte
I believe we were doing that for everything already
so shouldn't it depend on the display, and not be hardcoded?
then why is it a parameter?
it is to send because data doesn't get toggled
@slender iron Yeah, I2C is funky in latest S3 build e92b5f7. OLED works with terminalio but seems to break when displayio kicks in. Also seemed to mess up my I2C RTC. I can isolate and test more if you need.
@slender iron I will debug it tomorrow, it's already too late today, thank you
@stuck elbow k, sleep well. sorry for breaking it
you can make an omelette etc.
I love omelettes
@crimson ferry this is the fix: https://github.com/adafruit/circuitpython/compare/master...tannewt:displayio_hidden?expand=1#diff-09099cb6669a91a8dc5e4495e0a35e7dL100
OK, cool thanks. I'll check it at next S3 build.
This allows for one to preserve ordering within a Group while
hiding something temporarily.
Fixes #1688
Also, are there any hubs between the Mac and the device?
Note the SAMD51 has a Public Key Cryptography Controller (PUKCC) that is meant to help with these algorithms.
We may be able to do M4 but I doubt it'll fit in M0.
I'm trying to use the builtin NeoPixel on the Feather nRF52840 Express. Here's my code:
pixels = neopixel.NeoPixel(board.NEOPIXEL, 1)
while True:
pixels[0] = (255, 0, 0)
sleep(1)
The NeoPixel flashes between red and green. I assume this is because the semaphore system is interfering.
Looks like the builtin NeoPixel is not be shared correctly.
yes! and other chips don't, having generic C is fine and for large chips only
Make it easy to enable and disable which USB and USB HID devices to include at build time, using two makefile variables. Defaults are:
USB_DEVICES = "CDC,MSC,AUDIO,HID"
USB_HID_DEVICES = "KEYBOARD,MOUSE,CONSUMER,GAMEPAD"
For instance, in mpconfigboard.mk, you can define those variables:
USB_DEVICES = "CDC, MSC" # Omit MIDI and HID
USB_HID_DEVICES="KEYBOARD" # Use only keyboard
A couple of new HID devices have been added, but are not in the default set. The en...
@slender iron https://github.com/adafruit/circuitpython/pull/2115 is not running checks at all - might this be due to #2112??
Will approve without the bool:1 changes if you want.
I did some gedanken experiments about hiding and unhiding nested objects in odd orders, and I wasn't able to generate inconsistent states. Looks good!
Store as one-bit booleans?
Is it worth storing these as one-bit booleans to save space in the long run?
@tulip sleet was #2112 running when you pushed #2115? is the job rate limit what you estimate kept #2115 from starting?
no, the check is not even pending
#2112 changed a token, but maybe it did something else?
i just pushed to Mixer. job started right up...
2115 is an enigma. it would make sense to me that there were already 20 jobs running on the repo, which would keep 2115 from starting. maybe GH is still working out the bugs on the queue system... ๐คท
Usage limits
Exceeding usage limits may result in jobs queueing, failing to run, or failing to complete. Limits are subject to change.
- You can execute up to 20 workflows concurrently per repository.
- You can run up to 20 jobs concurrently per repository across all workflows.
@raven canopy it should still be queued, that's the weird thing. I can understand it might be wiating, but there's no box about checks in the "Conversation" tab
If you click on the "Checks" tab, it's not quite blank, but there's nothing there to try to restart or monitor.
yeah, was just about to mention the "Checks" tab showing your commit...and blankness. that's kind of what nudges me to GH's queue system being the culprit.
it also doesn't show up in the "Actions" tab at the top. its just...everywhere and nowhere at the same time.
and unfortunately, the only way to "manage workflows" is in the "Actions" tab.
I can try closing and submitting a new PR with the same branch.
or try the old empty commit trick?
I tried that, I just made a trivial change; that is the d3cb103 commit.
ahh. commit message makes total sense now. ๐
GitHub Actions is not initiating a check run on this.
let me try to close and resubmit
Make it easy to enable and disable which USB and USB HID devices to include at build time, using two makefile variables. Defaults are:
USB_DEVICES = "CDC,MSC,AUDIO,HID"
USB_HID_DEVICES = "KEYBOARD,MOUSE,CONSUMER,GAMEPAD"
For instance, in mpconfigboard.mk, you can define those variables:
USB_DEVICES = "CDC, MSC" # Omit MIDI and HID
USB_HID_DEVICES="KEYBOARD" # Use only keyboard
A couple of new HID devices have been added, but are not in the default set. The en...
@raven canopy, ok I merged from master and re-pushed, and now it's going
Maybe because this PR was started before the switch to GitHub actions.
Mixer only has 9 jobs still running, so no "proof positive" on my theory. ๐ฆ i'm not sure the Actions switch would be the cause. Mixer switched mid-stream, as well.
at any rate. its running now! ๐
the wording on that new github "feature" that dismisses reviews when changes are subsequently pushed could better. its so rude... hehe
@onyx hinge that'd be an interesting way to do something rosie-like
But it doesn't support other libraries - only cpx
so it's a very high-level simulation I guess
I didn't look into it very far at all
When I was interviewing at verypossible.com they mentioned another ARM simulator that is Python powered, now I can't remember the name. Commercial product.
The displayio_output_pixel_t opaque was added to remove ambiguity with the return value, so it clearly defines the intent. The display_io_input_pixel_t was added to reduce the number of input arguments into the functions to make for cleaner code, and reduce the amount of data copied onto the stack.
A kwarg to the constructor would be enough.
I added as a writable property because it can make testing easier, and there are strong cases where you might not want to have dither enabled all the time, or even at all.
Also, move the rendering setup code to shared-module from
shared-bindings.
In CP 5.0, displayio_display_core_set_region_to_update now starts
its own transaction, so it has to be moved outside of the transaction
started by the render call.
Use remote libraries data stored in s3 so daily updates of the libraries file can be performed. Will need to build site using GitHub Actions as there is a new plugin that is not supported by the default github-pages builds.
Prior to merging this:
- [ ] Enable GitHub Actions for daily builds at a specified time
- [ ] Move libraries.json automated builds to the adafruit-circuit-python s3 bucket. Currently have it located here: adafruit-circuit-python/adabot/web/libraries.json
We're working on getting the libraries.json automated builds to the S3 bucket. Thanks for getting this PR set up!
It appears some assets are missing from the release such as the Metro M4 Express.
Yup, we ran out of API quota. Will release today hopefully to validate that the new token fixes it.
In the meantime, they are available on S3: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/metro_m4_express/en_US/
Hi @gentle bronze, was wondering if adding F412 USB support is still on your radar. It'd be very nice to have that for adding QSPI flash support, since the F411 Discovery doesn't have a QSPI chip.
I know you've got a lot on your hands with the BLE stuff.
@ionic elk I am going to do it next, was fixing an bug with qspi flash on Arduino ๐
Which part? I removed the shared-bindings/rtc/init.h as I haven't done a deep dive into the RTC common hal yet, and I've been trying to clean up commented out material in favor of simply re-introducing it when the feature is added. power_warning_handler is an nrf implementation feature that I confused for a common hal component and left there, removing it shouldn't do much.
Hi folks, if anyone would like to try out, break and give feedback for circup I'd be very grateful. Just follow the "Developer Setup" instructions here: https://github.com/ntoll/circup
Sneak peak of updating a CPX. Thanks to @tulip sleet for a really cool approach that simplified and sped things up. ๐
Right... I'm off to play my tuba in an orchestral rehearsal this evening. Catch you tomorrow. ๐ ๐ต
@plucky flint Have a good evening! I'll take a look today ๐
yay!
Thank you!
Please give feedback via GitHub issues (forgot to mention)
I've tested it on Linux and Windows, if you have a Mac it might be helpful to check too. Thanks... (what does it do..? Once installed just type circup to get the details)
-> AFK
@tulip sleet what android do you use for testing?
checking...
android 9 on a samsung tablet, SM-T510, reasonably priced and the latest android available when I bought it at Best Buy
Thanks for moving the logic into shared-module too!
Will approve without the bool:1 changes if you want.
I did some gedanken experiments about hiding and unhiding nested objects in odd orders, and I wasn't able to generate inconsistent states. Looks good!
@dhalbert Done and done.
@tulip sleet took a look at your HID PR. Looks like a much cleaner solution than my cdc_and_msc_only flag - should I simply remove that from my current PR, and then we merge yours?
that sounds fine, yes, the idea was to generalize the possibilities
An additional note that should be considered is that the MSC endpoints need to change to support low endpoint devices. @slender iron, you were correct that setting both MSC endpoints to 0 results in issues on the SAMD21 (51 is fine).
๐
I was going to add a flag operation there to sort it out, but dan's PR will mess that up, so I'd suggest we
- merge my PR, with all endpoint stuff removed, accepting that it'll break the STM32 port for a short while
- merge Dan's PR,
- I can integrate dan's code into the MSC endpoints
Do you want STM32 included in that? I don't figure there are many people using it, but the F411 won't work unless the MSC stuff is properly configured.
I'm fine leaving it broken but it's up to you
nah, lets shoot for the next alpha
Ok. It should be done pretty quick
np, I want to pick the release pace back up
@slender iron if you could take a quick look at my port.c comments, we should be done for this PR.
yup, have it queued up in my tabs
will look in the next hour tops. I'm in "get through email" mode atm
The supervisor may be setting the green color even though the neopixel should be used by the user's code.
Low endpoint devices such as the F411 will still have issues with the descriptor file, as they need the MSC endpoints reduced from 2 to 1. Could we introduce a flag or other condition for this case?
It looks like the stage library grew too big to fit in the ugame10 and pewpew_m4 builds for some languages.
Thank you so much for adopting this PR! Looks good!
Alternatively, we could do it the other way and have a "MSC_DUAL_ENDPOINT" flag that only forces two MSC endpoints for the SAMD21.
My old PR had a USB_CDC_AND_MSC_ONLY = 1 flag here, which was then used to reduce the MSC endpoints. The MSC endpoints only need to be reduced for the F411 and other low-endpoint STM32 boards, but reducing the endpoints will only fail on the SAMD21. Could we put in either a new flag like MSC_SINGLE_ENDPOINT, or have the MSC endpoints both reduced to 0 if MIDI and AUDIO are both turned off?
What do you think about moving the dither property to the ColorConverter object itself? That way one could turn it on for individual elements rather than just the whole screen.
Ok, let's remove the return value completely if we want to replace it with the output struct. Otherwise we risk them getting out of sync.
Ok, looks like a good start to me!
@hierophect once this is submitted, please follow up with a PR to get these boards building with GitHub CI so that builds are made available automatically for testing.
@hierophect once this is submitted, please follow up with a PR to get these boards building with GitHub CI so that builds are made available automatically for testing.
would that just be an empty PR of the same commit? Or do I need to make changes to support GitHub CI?
Changed link to Itaca Shop and updated pictures
@ionic elk #2065 is not testing because it needs to get merged from tip of master to pick up the new CI settings:
git fetch adafruit # or upstream if that's what you call the remote
git merge adafruit/master
# resolve conflicts
git push
@tulip sleet getting rejection on the push ! [remote rejected] f411re-feature-buildout -> f411re-feature-buildout (refusing to allow an integration to create or update .github/workflows/build.yml)
did git merge adafruit/master say there were merge conflicts?
no
@ionic elk it's odd, it worked for me, do you have a circuitpython/.github/workflows/build.yml locally?
I believe I do, am I not supposed to? I'm seeing similar problems from other projects that say you have to delete that the rejected workflow file from git in order to push. Is that something that should be excluded during the merge process in some way?
i don't know; I did exactly the above and it worked, but the message clearly implies not
are you using git: or https urls for github?
I am using https
@slender iron it does not
https
even deleting the file is resulting in multiple other yml files pushing the same issue
@stuck elbow ok thanks, removing it to free up space for .hidden
apparently it might be able to be solved by pushing to a git url?
that's what they said, but I'm not sure, and I never use those. I wonder if it's because I have admin privs on the repo.
Hi, it looks like you replaced the different sized images with 3 images of the same size. It would probably work better to leave the images as they were and update just the link. Thanks.
@ionic elk still looking @slender iron are you following this PR push problem?
Ok, looks like a good start to me!
Ok, I deleted a couple files and it seems to have pushed now, but I don't know if that's going to cause a conflict
@tulip sleet I don't have any brilliant ideas. I've never seen it before. I'd probably rebase the whole branch on latest master
it appears those files are required for it to run tests as well
the whole idea of removing those files seems wrong
@ionic elk I guessed it might be a security issue about uploading possibly malicious actions (see https://github.com/renovatebot/config-help/issues/192), but these issues are old, from March or earlier, so I don't see how to fix this problem
i am not sure that has to do with it; the basic issue is that GitHub doesn't want people pushing malicious .github/workflow/*.yml files in a PR, but that seems to conflict with the idea of triggering an action on a PR push
@ionic elk https://github.com/desktop/desktop/issues/7079 notice it was reopened yesterday ๐ฆ
Yikes
are you pushing from linux or windows?
Mac
This rebase is really awful, should I force revert back to before the merge?
We shouldn't have issues since basically all the changes were approved by travis, but I don't know if that's against protocol
ok, do that for now. I really don't think the rebase is going to fix anything - it's not a merge issue, it's a policy issue we're running into
meanwhile I am going to keep reading. @slender iron has an inside helper at github who responds to twitter queries, and we can ask him once we understand it clearly
@ionic elk are you using github desktop or just cli?
cli
Yeah the PR only affects two files outside the port and both of them were tested back when we had travis
and how are you authenticating to github?
It should be safe to merge
Https, I guess? However it sets itself up?
Wait hang on I think it's probably osxkeychain helper
this appears to be the clearest explanation of what's going on, and it's a lot more recent: https://github.community/t5/GitHub-Actions/Can-I-edit-the-main-workflow-github-actions-file-locally/m-p/26265
@ionic elk maybe turn off the keychain helper for a bit and have the cli prompt you for a password. But we can defer this and just merge the PR as is, and test all this later
I'll see if that works.
I think @slender iron is all set so we should be good to go once you're done.
Ok, @dhalbert this passes all of the checks now.
OK, let's merge this even though the CI is messed up at the moment.
merge party!
lunchtime for me
Hi, it looks like you replaced the different sized images with 3 images of the same size. It would probably work better to leave the images as they were and update just the link. Thanks.
Hi Melissa,
alright thanks. We will provide correct picture for each size soon.
I will proceed only with the link update.
@ionic elk could you try a very simple PR: get your repo up to date (reclone if necessary and get all the submodules up to date), and then make a new PR that adds the two stm32f4 boards to the build. That can test whether a new PR from you with the workflow stuff is pushable or not. I will add details in the basecamp to-do
if there is still a github problem we'll pout that on hold and you can work on the pin table stuff. How does that sound for the next small step?
Sure. By adding to the build you mean the github action build?
right, there are several files to modify, because this is a brand new port. I'm just writing it up.
I think what I actually need is a new fork
since I can't push anything to my current one
i don't think it's the particular fork, it's that this restriction about changing the workflow files is tricky
when you used the osxkeychain manager, did you type your actual github password in or download a token from github? I am using a linux credentials manager and I think I had to get a token
as opposed to some OAuth thing like your Google login?
But if I have a new fork, it'll sidestep the issue - I can't make alterations additions or removals of workflow files, but if I just start from a new fork, I won't need to
you can make all the changes but the actual build.yml, maybe
do you have 2FA on github?
which worked, a new fork?
I thought I'd been able to modify it but deleting the credential worked
I can push the changes now
if you have 2FA on you need to get a token. We require 2FA for staff.
that top link is a bit broke
@ionic elk how are the endpoints allocated right now on the '411? Do you need MSC to be only one endpoint at the moment?
Yes, if it takes up two, the way it is now, we don't have enough for HID, MSC and CDC at the same time
Or wait, not even HID I think. Let me double check that
0 is control, 1 and 2 need to be bidirectional CDC contorl and data, that leaves only one more bidi eiether for MSC or HID, or drop CDC and have MSC and HID
HID is less important - people can use other boards for that
Yes that's right. Just checked as well
ok, i will add the flag to my PR, just wanted to make sure it was needed right now
did you see the notes I added to basecamp about what files to change for the automated build?
@tulip sleet The capacitive touch on the nRF isn't built into the chip, right? How is it done?
Yes I did. I've been temporarily evicted from my desk due to construction but I'll be right on it after
@idle owl the code sets a DigitalInOut to out to 1, and then switches it to input, and sees how long it takes to decay to zero. The must be a 1 megaohm pulldown resistor on the pin
@tulip sleet hmm.... ok. need to translate that to beginnerese. Thanks!
@raven canopy hey #2080!
@idle owl "On Cortex-M4 chipsets (SAMD51, nRF52840), touchio does not use the built-in touch controller. It uses a 1MOhm resistor as a pulldown to detect capacitive touch." better? ๐
@raven canopy well done
"To function properly, a 1MOhm resistor must be connected from the IO pin to GND"?
^^^^
(I assume these are built on on CPB?)
Yeah all built in
it treats the pin and whatever it's conencted to as a capacitor. It charges the capacitor, and sees how long it takes to discharge. It needs a 1MOhm resistor connected to ground to provide a discharge. It is mearusing the size of the capacitor by measuring the disharge time.
so... WAY too much info there
Something touching the pin increases the capacitance
This is for the "guided tour" page. It's a "here's the basics of your CPB." type thing
hehe. "To understand touchio on the CPB, please proceed to the nearest University and acquire an electrical engineering degree. k thanks!"
hah!
"Pins A1, ... A6 can be used as touch sensors. Although the principle is slightly different from CPE, they function the same in CircuitPython programs"
"CIrcuitPython can do capacitive touch on any nRF pin that supports DigitalInOut, but because there is not built-in circuitry for this, the pin must be connected to a 1MOhm resistor whose other end is connected to ground."
also, looks like they're 330kOhm on the CPB
marking says 310 but I was measuring around 330k
@onyx hinge latest schematic has 1M
okay
maybe you are measuring leakage through the chip? try reversing the probes and see if its' the same
.365M and .335M measuring from GND to A1 on my CPB.
"310" marking doesn't even make sense to me, but I get about that same .3XX M reading across one of them
OK, 01E would be 100 x 10000
maybe the fault lies with my multimeter then
not sure I care enough to track down a bare 1Mohm resistor right this second, sorry for the distraction!
i am getting 1M with mine ๐
adds a new meter to the shopping list
This PR should add CI capability to this and future stm32 port submissions.
I see it yells at me for not including the F412zg board. What would I do if I wanted a board to be intentionally excluded from test?
I don't recall entering that board into any other config file. Does it search through and insist that every single board is included?
ya, it insists. why not build it?
<@&356864093652516868> any objections to an alpha 2?
Nope.
no, the HID/USB cmpile-time stuff can wait
None from me
newp
None
i never got a chance to try alpha 1 ๐ฆ
k, will kick it
@slender iron no, assuming there will be an RC
awesome
RCS - never forget
@simple pulsar oh my, I'd rather forget Revision Control System, assuming that's the RCS you mean.
@slender iron a bit late, but go for it!
๐
there are worse things than RCS, Team Foundation Server anyone?
Automated website update for release 5.0.0-alpha.2 by Blinka.
Happily, I never used any version control software from Microsoft
904 release assets!
yowsers
It broke with adafruit-blinka but works now.
Alpha 2 has all 904 assets so the token fix worked!
AutoLinks happen when a bare URL is included in the source markdown.
@raven canopy @idle owl either of you run adabot regularly to set Travis credentials?
@slender iron ok, yah SAMD21 is flaky with MSC endpoints on same pair. It works after reset but not when first plugged in. Still trying to find where we wrote this up or found it on the web.
I think I just moved on
you can merge #2120 unless you want sommersoft's review too
@ionic elk re needing two endpoint pairs for MSC on SAMD21, did I tell you that or did you find it out elsewhere? I just want to make the right choice for the non-SAMD21 boards. a single endpoint pair seems to work for all boards except SAMD21, but I have yet to find clear doc of that
@slender iron i do not. would it even work with my credential?
What do you think about moving the dither property to the ColorConverter object itself? That way one could turn it on for individual elements rather than just the whole screen.
It seem to make more sense calling:
board.DISPLAY.dither = True
vs
pyportal._bg_sprite.pixel_shader.dither = True
I also couldn't find any examples of using more than one pixel shader. Dither could be move to a writable property and added to the constructor of ColorConverter to future proof the feature...
@slender iron How do you mean?
@idle owl run adabot with -t/--travis-github-token argument, so she sets the Travis token if it isn't set.
I added a USB_MSC_NUM_ENDPOINT_PAIRS makefile variable and corresponding arg in gen_usb_descriptor.py. It defaults to 1 and is set to 2 for SAMD21 boards.
I tested this on M0, M4, and nRF boards, and checked the generated descriptor as well to make sure it was choosing right.
It is indeed the case still that SAMD21 needs a separate endpoint pair. Otherwise it will sometimes enumerate (sometimes works after a reset) but sometimes not (if plugged in fresh).
@tannewt Ready for review, I've done my testing.
@raven canopy I'm happy to give the password to you if you like
Hmmm...
Failed to download action 'https://api.github.com/repos/actions/setup-python/tarball/v1'. Error Response status code does not indicate success: 401 (Unauthorized).
morning ๐
middle of the night ๐
afternoon ๐
Heh.... as an old time IRC user, my timezone is always UGT (http://www.total-knowledge.com/~ilya/mips/ugt.html) ๐
as an old time IRC user, I never heard of UGT before now
@onyx hinge heh... I can't remember how I heard about it, but once it was explained to me (perhaps 20+ years ago), it made prefect sense. I've been an advocate ever since -- simply because it's fun and rather silly in a friendly sort of a way. ๐
Hi folks, so I've done a bunch of updates to the docs for circup (see the README here: https://github.com/ntoll/circup/ -- or better clone the repos, install the deps into a virtualenv and make docs to generate what'll end-up on ReadTheDocs). All feedback most welcome..! Note, since I'm working in London today (I'm due to run a code dojo in a couple of hours) I've only got my Linux laptop with me. I don't think any of the changes I've made should break it working on Windows or OSX, but if they do, please ping me. I'll be testing x-platform tomorrow.
But right now, I'm off for a (very) late lunch. I'll be online later to pick up any feedback if need be. Thank you!!! ๐
good luck with the dojo!
I see a few forks of the AMG88xx driver. Is anyone working on supporting settable rotation?
@tulip sleet @slender iron just saw your messages in livebroadcast - my testing yesterday found that there was no impact of a single MSC endpoint on the SAMD51, but that it prevented code writing on the SAMD21 (though no other USB features were inhibited). I don't have a nordic board so I wasn't able to test that.
@ionic elk Ah, ok, I didn't realize you tested it thoroughly from scratch. I think Scott discovered this independently when he was first doing MSC for SAMD21. There are hints of the problem in various Atmel forum posts, but nothing definitive. The latest version of my PR does the right thing. If you're willing to finish the review for that we can get it in.
are you finished with the stm32f4 build PR? I can look at that.
I will switch right back to that. The stm32f4 build PR is done, the latest check just failed for some internal reason (unrelated to code) so I had to restart it. An earlier build that differed only by a redundant comma passed just fine so it should be set to review.
Looks good! Thanks for including this.
@tulip sleet Could you take a look a the build PR check error? It's throwing some git thing, related to Run for exp in *.exp;?
sure
@ionic elk it looks like the test build checks out the version to test in a different way than the board builds. This causes the test build to fail, I think maybe whenever a new merge has happened while the test is in progress. This has happened to me a couple of times. If I merge from upstream and push, then it works. I'll look at the workflow .yml flows
@slender iron ^^ looking at this
What would you suggest for this test? Do I need to update anything or should I just restart one more time?
Ideally I can fix it. Or as a temp fix, fetch from adafruit, and merge adafruit/master, and push again
I think that cause it to work unless there's another PR merged before this one is
go ahead and try that and may vet my theory
they both use actions/checkout@v1, hmm...
fetched and merged... let's see what happens
let's mark your to-do as done after it's merged
OK, looks good! Still having CI problems, but not due to these changes.
@tulip sleet https://github.com/actions/checkout/issues/27
@slender iron yup, that looks like it, so maybe just a re-run is good enough, as long as master is quiescent during that time
it's a bug that should be fixed, no comment yet from github folks
ok, yet another repo to keep track of. I was looking around for the right place to search, didn't know it was github/actions
ya the actions/checkout is actually a repo name
@v1 is a tag, iguess
but if it's buggy, then we will need to advance to @v2? or should we leave the tag off?
so we pick up any fixes?
or will they advance the tag?
๐คท
I'd expect a v2

