I even thought I remembered you mentioning subregions when I started working on it
#circuitpython-dev
ionic elk
onyx hinge
ooh I got something to appear on the SDIO "CMD" pin on samd51
slender iron
@idle owl yup! maybe add "in both human and machine readable forms"
idle owl
Will do, thanks
slender iron
@ionic elk ah, I think it's in the arm architecture docs
(I'm renaming master to main at the moment)
ionic elk
@slender iron if you're referring to this: https://developer.arm.com/docs/ddi0489/d I haven't found it to be very informative. But I guess I'll just do trial and error.
slender iron
I think so but the PDF is easier to read for me
ionic elk
the PDF download is identical, as far as I can tell looking at it
slender iron
ya, I'd expect it to be
slender iron
<@&356864093652516868> Heads up, the master branch is now available as main and all PRs have been updated
charred flare
Anyone know if the new STM32F405 board supports nvm? It's not in the product support matrix which is the only place I know where to look to find out, lol
tulip sleet
@slender iron what should we do with our forks and our local copies?
ivory yew
@tulip sleet you can git fetch main, git checkout main and then git branch -D master.
solar whale
@charred flare it does not appear to be implmented...yet --- ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.4.0-beta.0-450-ge8d8004da-dirty on 2020-06-02; Feather STM32F405 Express with STM32F405RG
import microcontroller
dir(microcontroller)
['class', 'name', 'Pin', 'Processor', 'RunMode', 'cpu', 'delay_us', 'disable_interrupts', 'enable_interrupts', 'nvm', 'on_next_reset', 'pin', 'reset']
len(microcontroller.nvm)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object of type 'NoneType' has no len()
microcontroller.nvm[0]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not subscriptable
Aww, thanks @solar whale
tulip sleet
@ivory yew but I need to set the default branch in my fork, etc., too, I would hitnk
ivory yew
ah for the fork you'll just need to git fetch upstream main, then git push fork main, then you can edit the setting in github.
replace upstream and fork with whatever you named your remotes
tulip sleet
Thanks, and the Hanselman blog entry @slender iron mentioned helps too: https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx
charred flare
I'm having the HARDEST time finding a board/wings/etc that do what I want and do them well, lol.
Started with M0 proto (cause I had it) and bought a bluefruit LE, couldn't get it working for some reason and ran out of memory for CP, iirc
So I got a 32U4 Bluefruit and @tulip sleet helped me with some bluetooth stuff but ultimately I decided to scrap BT and go with wifi for updates.
So I bought a ESP32 Airlift and got that connected but it wouldn't reliably connect to my normal Wi-Fi but I got it working most of the time with an old router.
So I bought a RaspPi Zero Wi-Fi with the intent of using it with a fadecandy board but the abandoned that Idea.
So I bought a ESP32 Huzzah that had everything and got it running MP (since no CP) easily enough and found a great Wi-Fi manager (https://github.com/tayfunulu/WiFiManager) that's worked flawlessly. But turns out MP on the ESP32 can't drive neopixels without random flickering, yet.
So... now I'm out looking again, lol.
slender iron
@tulip sleet I don't use my fork's default branch at all
tulip sleet
don't you update it from time to time git checkout main; git fetch adafruit; git merge adafruit/main
slender iron
@charred flare what are you trying to do
no, I just always start from adafruit/main
tulip sleet
i try to keep my main in sync, and then i branch from it
solar whale
just curious if there has been thought given to migrating "all" the Adafruit repos to "main" ... yikes...
slender iron
@solar whale I mention it on the issue
solar whale
sorry -- will read it now
slender iron
np, all I did was mention it
charred flare
Oh, just make neopixel animations and talk via the internet. I have a working prototype with the 32U4 and airlift - it's just got that annoying wifi issue (I forget what exactly the problem is). I was also hoping to play with threading in MP to have it check online while keeping the animations going instead of having to pause.
tulip sleet
@charred flare The thing that sounds like it's worth fixing is "ESP32 Airlift and got that connected but it wouldn't reliably connect to my normal Wi-Fi"
we would like to know if you have some idea of what the issue was
charred flare
Right, I'm using it now. I don't recall why it was cranky with my normal AP. It works - mostly. But I'd like it to work always and on my normal wi-fi network. The same ESP32 chip running MP and that wifi manager worked great.
we all talked about it here a while ago. rssi was fine, etc. shrug
Does this https://github.com/tayfunulu/WiFiManager look like anything close to being usable in CP and the Airlift?
Out of curiosity
slender iron
I think working always will be really tough
fixing sporadic issues is challenging
Ok, 5.4.0 Beta 1 is fully released and blogged
charred flare
lol well I guess I meant working on my normal AP as well as it works on the others.
tulip sleet
wifi manager expects to store data locally. In CIrcuitPython, you'd have to store it on the SD card unless you remount CIRCUITPY to r/w. In MicroPython there is nothing to prevent both MPy and the host computer from writing to the filesystem simultaneously (and causing corruption). So we disallow that.
what is your AP brand and model?
you could file an issue against the ESP32SPI library with details of the router and the errors you're seeing. We might not be able to debug it right away, but other people might chime in if they're having similar troubles.
charred flare
Yeah I read about the r/w stuff. Interesting, you can write to SD though in "normal" mode in CP? Shame I don't have a SD card slot! lol
Uh... Netgear WAC104. It's working on a Netgear N600 though.
Let me see what I can do about that. π
prime flower
@charred flare Have you updated the firmware version on your ESP32 AirLift board? (not your CircuitPython board)
charred flare
Hmm... I don't believe I have. That could be an idea.
prime flower
@charred flare The ESP32 runs its own firmware (nina-firmware) which handles the wifi "stack". It communicates over SPI with the CircuitPython board.
We have a guide on updating nina-fw over here: https://learn.adafruit.com/upgrading-esp32-firmware
charred flare
yeah I supposeit could be older firmware - who knows when this board was flashed
thanks! I'll see
prime flower
Adafruit ships with an older version of nina-fw, as far as I know. The latest nina-fw version is built on ESP-IDF v3.3x (LTS).
charred flare
Hmm. Wonder what's on the ESP32 Huzzah. worth a try though!
P.S. it's working fine on my normal AP at the moment π€£
before it would only connect about 1 in 10 tries and now it's connected 100% of tries
literally just changed the ssid in secrets.py
prime flower
Ok, I've had less connection attempt issues when updating the nina-fw version.
charred flare
ah! it just did ti
'failed to connect' 'no such ssid'
I'll go try the update and see if that fixes it
tulip sleet
also you might check about any firmware updates for the AP itself
solar whale
I concur with @prime flower - the number of failures is reduced with the updated NINA FW. Still good to catch the exception and retry.
they do still happen, but much less frequently
ionic elk
@charred flare NVM on the STM32 is on my todo list but hasn't been high priority so far. It's a little complicated by the STM32 flash system, which makes it more complicated to implement then on the other ports.
onyx hinge
@gilded cradle @idle owl hmm I wonder why this library is not enable for blinka (setup.py.disabled)
charred flare
Now that's an idea @tulip sleet
@ionic elk well if you can write to the SD card in "normal" mode I can just do that. I just need to save variables and preferences between reboots
gilded cradle
@onyx hinge which library?
ionic elk
It's actually technically in already, but it takes currently requires entire flash sector (16kb minimum) which is kind of ridiculous for most boards, so it isn't defined on most of them.
onyx hinge
@gilded cradle https://github.com/adafruit/Adafruit_CircuitPython_Debouncer/blob/master/adafruit_debouncer.py
yeah telling you which one would be helpful wouldn't it
charred flare
How's touchIO coming on that board? That's the only other missing feature I need
ionic elk
hopefully Jeff will get SDIO working cleanly on STM32 soon
gilded cradle
I'm not sure @onyx hinge. Maybe due to https://github.com/adafruit/Adafruit_CircuitPython_Debouncer/blob/master/adafruit_debouncer.py#L59 ?
charred flare
Oh right, I remember reading that now
onyx hinge
@gilded cradle getting rid of const() would be a small price to pay
gilded cradle
@onyx hinge I think putting it in a try/except block can get around that. I'd imagine there's probably a CPython equivalent for const.
onyx hinge
there's really not
well, I don't know of one
gently backtracks from acting omnicient
gilded cradle
Ah, then yeah. Makes sense to just remove the const. Perhaps a little refactoring is in order
onyx hinge
anyway, it's not vexing me, but I just noticed it
gilded cradle
At the moment, I'm testing displayio drivers and converting them release on PyPI .
onyx hinge
π
slender iron
@tulip sleet do you know if the read and write methods of uart should be async?
meaning write returns before everything is transmitted
tulip sleet
i'll look
slender iron
it's a bit weird because we use stream to provide the apis
tulip sleet
the common-hal routines busy-wait until the write is completed
io_write() is non-blocking, but then we loop until the write is completed
slender iron
what port are you looking at?
tulip sleet
atmel
tulip sleet
same thing in nrf; they both call RUN_BACKGROUND_TASKS while waiting
in common_hal_busio_uart_write()
slender iron
kk
tulip sleet
we could reconsider that, in the long run, since it could be pretty slow
slender iron
happy to match other impls at this point
simple pulsar
I have some displayio code that's competing with some audio that's playing from a wav file using WaveFile class and the audio is suffering on 5.3.0 on a Circuit Playground Bluefruit with TFT Gizmo (i.e. PWM audio). Was there a recent improvement/tweak to the buffering for audio? There is something going on with https://github.com/adafruit/circuitpython/pull/2879 but I've not looked inside that yet.
manic glacierBOT
raven canopy
@lone axle @tulip sleet @slender iron this is what I'm seeing with the CSS mentioned in #3022.
slender iron
I have no idea. CSS boggles my mind
raven canopy
yeah...same. i learned a few months ago that it is Turing complete. like...wha?
lone axle
That looks pretty good to me except the blue class boxes going over it. I wonder if there some z ordering that can help it. Definitely same here though on CSS boggling the mind π
I'm gonna go for a walk here in a minute but maybe I'll try to poke around some with the chrome inspector when I get back to see if I can get those blue boxes going behind
The grey boxes for properties seem to be affected as well:
raven canopy
its related to the display: table setting. messing with that will likely destroy the page. like, explosions.. π₯ π
lone axle
lol π
(I never knew about position:sticky before this is a neat trick to trow in the bag)
charred flare
hey @prime flower you still around?
raven canopy
@lone axle z-index: 2 seems to work for the box. good thinking!
idle owl
@charred flare Sorry about that. The bot tagged your post. We've had a massive uptick in spammers so we've enabled a lot of automated moderation things to try to help.
charred flare
was it the #'s?
idle owl
I'm thinking probably, based on what of your message I could see
raven canopy
@lone axle thoughts?
idle owl
@charred flare But I'm not certain what part of it triggered the bot.
charred flare
was told it was the excessive #'s lol - it's all good
manic glacierBOT
lone axle
@raven canopy looking good! I like it
raven canopy
π time!
lone axle
I've got an unfortunate incident involving a door to attend to π« Washing machine walked itself forward enough to block the door closed.
crimson ferry
so much for smart appliances
ruby atlas
maybe it had a plan when it walked itself around.
lone axle
I can now say that I've ripped a door off the hinge and only be exaggerating a tiny bit π€£
ionic elk
@raven canopy Can that warning be closed? Not that I ever need to use old docs, personally, but if someone actually did I imagine it'd get pretty annoying if it can't be banished somehow.
raven canopy
@ionic elk i imagine it could be, at least with some JS. Django's, to use the example in the issue, is a little nicer since its a full-width banner and doesn't take up as much vertical space. we'd be getting into a whole new theme at that point though, i think. π
lucid solar
@ionic elk I'll take a look at the STM32 PR later today, I'm a bit behind with what's been happening.
ionic elk
@lucid solar sorry, I had a CI failure for the 746 that happened after I stopped work. Putting in a fix now.
lucid solar
ok! Let me know when it's done and I'll test...
ionic elk
@lucid solar Ok fix is in, should be ready as soon as CI wraps up. Thanks for helping to test!
lucid solar
Ok..I'll test it in a few minutes..
ionic elk
whoops I was editing the Nucleo by accident. should be in for real this time.
onyx hinge
@tulip sleet did you look into https://launchpad.net/gcc-arm-embedded/+announcement/22902 yet ? looks like it's a minor update (does not bump gcc version according to their list of notable changes)
pastel panther
@raven canopy @trim elm any word on the adabot arduino lib count mismatch?
raven canopy
@pastel panther its...unexplainable. at least, for me at this point.
pastel panther
fair enough!
raven canopy
i think i've ruled out authentication differences, though it did highlight that there are problems there (filed an issue already).
pastel panther
ah, that was going to be my guess. I know I've had mysterious adabot adjacent issues due to cached/default creds
raven canopy
and to note, adabot's nightly run shows the same non-ladyada results that we get.
the confusing part for me is that ladyada gets valid results. if they were garbage, i think this would be easier to narrow down. π
pastel panther
I feel like it's got to be credentials, right? Like, we tried using her token and still got different results
raven canopy
the only differences i can think to explore are run environments (OS, python, etc) and repo settings.
pastel panther
so either:
- we weren't using it correctly
- she wasn't actually using it
- they're sending diff results for the same credentials based on...?????
raven canopy
yeah, the different results with the same creds is what has me π€―
pastel panther
I'm going to go ahead and declare that the creds are different
like, I want to see the actual bytes going across the network before I believe differently
I'll settle for raw TCP, I suppose
raven canopy
could be. maybe verify with her how the ADABOT_... env vars are set on her system?
pastel panther
I'll ask in a bit
raven canopy
but that would also make me lean further into the repo settings, since different creds would yield different results.
tulip sleet
@onyx hinge No, I did not see that (I have been looking for an appropriate mailing list to get notified of these updates). I see they did bump from gcc 9.2.1 to 9.3.1. I looked over the buglist briefly of fixes and didn't see anything that looks like we could use it. We could wait for 5.4.0 final and then switch.
pastel panther
since there's a range of factors in GH settings that could affect how different creds change results, I think it would be wise to settle on verifying same creds before going further
raven canopy
unrelated: why didn't i use pytest to start with? π€¦
(.venv) ~/Dev/rosie_pi/RosiePi:$> rosiepi itsybitsy_m4_express 1234
=============================================== test session starts ================================================
platform linux -- Python 3.7.4, pytest-5.4.3, py-1.8.1, pluggy-0.13.1
rootdir: /home/sommersoft/Dev/circuitpython
collected 1 item
../../circuitpython/tests/circuitpython/rosie_tests/test_digitalio.py b"['__class__', '__name__', 'INPUT', 'OUTPUT']\r\n"
. [100%]
================================================ 1 passed in 0.10s =================================================
========================= RosiePi ==========================
Initiating rosiepi...
------------------------------------------------------------
- Date/Time: 10-Jun-2020,10:04:31
- Test commit: 1234
- Test board: itsybitsy_m4_express
============================================================
Connecting to: itsybitsy_m4_express
------------------------------------------------------------
Connected!
Board info:
- Serial Number: 44B26E5A3335833502020253035450FF
- Disk Drive: /media/pci-0000:00:14.0-usb-0:3:1.2-scsi-0:0:0:0-part1
sorry. wall-o-text...
ionic elk
Ok, recap, is there a guide or list of instructions or something on what to do with this whole main business?
So far it seems like :
git fetch upstream
git checkout main
git branch -D master
and then something about the default branch settings?
manic glacierBOT
slender iron
@ionic elk what are you trying to do?
I recommend doing git checkout upstream/main if you want to be on upstream's main branch
tulip sleet
@ionic elk I found https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx to be quite helpful
manic glacierBOT
It looks like SCLL and SCLH are just counts for clock cycles in the low and high states. My guess is that they delegate to CubeMX because they assume folks don't understand the source clock value.
manic glacierBOT
solar whale
@tulip sleet If I want to add a library to the frozen directory - how do I do that so it becomes a submodule?
tulip sleet
you add it like any other submodule to the frozen dir, and then add it to mpconfigboard.mk for the particular board
cd circuitpython/frozen; git submodule add ...
solar whale
ah -- looks simple enough -- thanks
ionic elk
@slender iron Just took a look at how stm32duino handles I2C timing calculations and holy shamoly they've got like 500 lines of code dedicated to it. So, question for you, would you rather we:
a) skip this, add a parameter in mpconfigboard.h for I2CTIMING and tell H7 and F7 board creators to use CubeMX the way the docs do
b) copy in the stm32duino stuff as best as possible with attribution
c) recreate it from scratch (might take a while)
I'm leaning toward a) for now this seems kind of ridiculous for 4 boards. Or even 10 boards.
main meteor
Reminds me of the time I wanted to replace a lookup table with Boolean expressions "to save gates". It may have done so, but it sure isn't a model of clarity!
ionic elk
Yeah I really hate directing people to "JuSt UsE CuBemX loL" but at a certain point I just wonder if it's worth the testing pain. Even if I implement this I'm not sure I'd be able to fix it if something went wrong.
Or rather, I could, but it'd waste time I could be spending on new modules
left mirage
I am trying to add support for Set_Report to allow for getting the current values of capslock. numloc, etc but it seems like https://github.com/adafruit/circuitpython/blob/main/shared-module/usb_hid/Device.c#L86 this callback isnt being run
i successfully added a propert report to Device but it isnt updating to the value
void tud_hid_set_report_cb(uint8_t report_id, hid_report_type_t report_type, uint8_t const* buffer, uint16_t bufsize) {
usb_hid_device_obj_t* hid_device = get_hid_device(report_id);
if ( report_type == HID_REPORT_TYPE_OUTPUT ) {
// Check if it is Keyboard device
if (hid_device->usage_page == HID_USAGE_PAGE_DESKTOP &&
hid_device->usage == HID_USAGE_DESKTOP_KEYBOARD) {
if (bufsize) {
hid_device->report = buffer[0];
}
}
}
}``` this is my version of the functionbut even c void tud_hid_set_report_cb(uint8_t report_id, hid_report_type_t report_type, uint8_t const* buffer, uint16_t bufsize) { usb_hid_device_obj_t* hid_device = get_hid_device(report_id); hid_device->report++; } doesnt do anything which leads me to believe it isnt being called at all
if anyone has any ideas why that callback isnt being called please ping me
manic glacierBOT
tulip sleet
@left mirage this was worked on in the past but there were still some things to fix up, which you may have encountered too: https://github.com/adafruit/circuitpython/pull/2366
left mirage
i actually hadnt seen that pull request but i was looking at https://github.com/adafruit/circuitpython/pull/2366/commits/ad6cee833d5b2b7d924614fddeee7c760aacb455
i did notice the tinyUSB report_type error
but i was still unable to test even that because it seems that now the callback is not being called by tinyUSB at all
tulip sleet
I don't remember if the issue was in TinyUSB or some setup issue in CircuitPython. This whole thing is on our to-do list, but we haven't looked at it in a while. Thanks for taking a look, and open an issue in TinyUSB if you think there's an issue there.
left mirage
im gonna take a look at the tinyUSB code and see if something changed for those call backs
tulip sleet
@timber mango maybe of interest to you ^^
stuck elbow
@left mirage that pull request worked back when I tried it, but only on samd21 and not on samd51, so I suspect there is some missing machinery in tinyusb itself
left mirage
@stuck elbow i'm using a trinket m0 so thats the samd21 but that pull request failed now so im thinking maybe some commit on tinyUSB broke circuit python's callback
marble hornet
@tulip sleet in regards to the bus-device timeout PR, while it cannot fix the I2C hang I've found it useful for detecting when the device is hanging and have it reset itself. do you think it would be better to close the pr or leave it open? I defer to your judgement
tulip sleet
@marble hornet I 'd rather fix the underlying problem in the long run, so we don't have to add a new workaround API. What we hope to do is to detect the stuck bus and then unstick it (if you toggle the clock line 8 or 9 times that usually works). But if it's working for you now, of course, keep the code for yourself until we get a chance to fix it. Which board are you using?
marble hornet
@tulip sleet Iβm using my custom watch board. It is (very!) electrically similar to the nrf52840 feather express. I get about 0 to 1 spi and i2c hangs per day. I also notice it happens more when editing code on the device
marble hornet
Do you think it is a Nordic silicon problem or a low level software one?
rare geode
@slender iron Hey! I just published version 0.7.1 of the Atom CircuitPython package, and subsequent to our chat last time, started a blog! https://josephbanks.me/atom-circuitpython-v0-7-1?utm_source=discord&utm_medium=adafruit
manic glacierBOT
mental nexus
I am planning to update my memory-sipping textMap class to add vertical text scrolling capability. I would appreciate any suggestions yβall have to consider incorporating on text scrolling usage. @lone axle and @onyx hinge especially since you two have seen the evolution of this. https://github.com/kmatch98/CircuitPython_textMap/issues/11
lone axle
@mental nexus Sweet! I actually just found myself wondering about whether that supported scrolling the other day. I want to make a PyPortal script that will fetch a readme.md from github and then render it using your markdown tool. I think my only really suggestion is try to keep the interface generic enough that it can be adapted for use with a touch screen as well as D-Pad up/down buttons.
If the developer can do something like text_box.y_scroll += 1 or text_box.y_scroll -= 1 I think it could cover both scenarios.
Rotaray encoder scrolling sounds fun too, albeit perhaps a bit awkward
mental nexus
Thanks for the suggestions. Let me think on it a little more and give you a proposal on the class functions to see if it will fit your needs.
tulip sleet
@marble hornet if you have the timeout code running on your board, and you get a timeout, can you retry and get the peripheral or do you lose the peripheral until reset or power cycle? The I2C fix I was refererring to is to catch devices that are completely stuck and try to reset them.
simple pulsar
I've been getting into sample playback on the CPB and it's reminded me of just how noisy the PWM vs PAM8301 combination is. I've found another forum post with essentially same observations. Was this combination used for testing during the development of PWMAudioOut? https://forums.adafruit.com/viewtopic.php?f=60&t=166318
solar whale
I'm trying to find ways to improve the memory usage of the rfm9x library and I ran across this ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.4.0-beta.0-300-g37a7cf993 on 2020-05-24; Adafruit Feather M0 RFM9x with samd21g18
import gc
gc.mem_free()
21808
import adafruit_rfm9x
gc.mem_free()
6448
gc.collect()
gc.mem_free()
12112
Fantastic @idle owl! Thank you π
slender iron
@solar whale interesting! I'd be curious to see the memory changes done. It could be something about the state of the stack because the mark process is imprecise
@mental nexus I'd love to support native display scrolling but it's usually aligned horizontally rather than vertically
solar whale
@slender iron the big problem is that on the M0 boards -- there is not enough memory for the initial load -- i suppose I could import then force gc. - do you have any suggestions about where to look to try to minimize that?
slender iron
imports should forces a gc after
but maybe a stack value hasn't been cleaned up at that point
mental nexus
@slender iron I tried scrolling some text and itβs less than satisfying. For now may have to fall back to page redrawing instead of scrolling. Understood that builtin scrolling may be necessary to achieve smoother behavior. FYI this is a 240x320 external display connected via SPI.
I see that PyPortal has DMA. Too bad I canβt pry mine away from my daughter. π
slender iron
ya, scrolling without display help is tough because you have to re-send every pixel again
mental nexus
Got it. Will come up with another way for now.
arctic lily
Just FYI, I recently set my touchpad to turn off when I have a mouse plugged in. I just plugged my CPX in, and my touchpad stopped working.
Apparently the CPX is detected as a mouse.
mental nexus
The PyPortal scrolling is a lot better, but a little bit of stutter. Since the PyPortal uses DMA it has a big impact on redraw speed of bitmaps.
pastel panther
Heya @ruby smelt, I got word that you were having an issue with your Feather Sense where you had to set a data rate to get accelerometer and gyro measurements. I wasn't able to reproduce the issue running the same demo on my feather sense, however we recently released an update to the Adafruit_CircuitPython_LSM6DS library that runs the gyro and accelerometer to address an issue that some CLUE's were having, so that may have fixed the issue you saw.
Please download the latest bundle for your version of CircuitPyhon here: https://circuitpython.org/libraries and copy over the updated adafruit_lsm6ds.mpy into your feather's CIRCUITPY/lib folder and try again.
@ me here to let me know how it goes, or leave a comment in this issue https://github.com/adafruit/Adafruit_CircuitPython_LSM6DS/issues/18
Thanks! Sorry for the hassle
manic glacierBOT
slender iron
@prime flower keep a closer eye on this thread: https://forums.adafruit.com/viewtopic.php?f=60&t=166139
if the learn guide no longer works then we need to fix it
solar whale
@slender iron that was why I have been looking at the memory usage of the rfm9x lib.
ionic elk
@slender iron right now the only board that has to define the I2C definitions is the F746 discovery, since it has overwritten clock values. I don't think that's excessive since getting clock values from CubeMX is pretty standard anyway. Finding timing best-fit from clock frequency values is about 500 lines of code for stm32duino which is why I felt it was overkill for only one non-adafruit board, but I can spend some time next week working on it if you'd prefer.
onyx hinge
@tulip sleet I thought maybe using an Atmel START project on grand central would be a feasible way to verify the SDIO functionality with "known good" code. However, I am extremely tripped up by clock generation in START and so I can't get past initialization. Do you have any advice? Is this not such a great way to approach the problem?
tulip sleet
@onyx hinge it is basically terrible. I was not able to get a clock generation setup that corresponded to ours without showing errors.
onyx hinge
i'm not so much bent on it necessarily matching cpy, but something that works on the HW would be nice
tulip sleet
You might look in their forums, e.g. this search (https://community.atmel.com/search/site/atmel start samd51 clock setup), e.g. https://community.atmel.com/forum/samd51-trouble-sdhc-using-internal-clocks?skey=atmel start samd51 clock setup
there might be some more general help there with a sample setup as well. Also there are example projects in atmel start you could start with
onyx hinge
right now my problem is not even getting through the clock tree initialization in my START project so that's ... at least 2 questions down the road
tulip sleet
There is another tool that comes from the MicroChip side of the company, which I haven't looked at: https://www.microchip.com/mplab/mplab-harmony
orchid basinBOT
tulip sleet
@onyx hinge https://start.atmel.com/#examples/sdio includes a SAME54 example which is basically a fancier SAMD51. It would include a clock configuration in the example.
ionic elk
@slender iron would it be possible for us to make @onyx hinge's practice of listing the commits included in each release a standard practice for all releases? It's super handy for quickly tracking what fixes are included in each version when helping people out.
slender iron
@slender iron Finding timing best-fit from clock frequency values is about 500 lines of code for stm32duino which is why I felt it was overkill for only one non-adafruit board, but I can spend some time next week working on it if you'd prefer.
@ionic elk This wasn't my suggestion. Can you get the bus value and simply map it over rather than compute it?
slender iron
@slender iron would it be possible for us to make @onyx hinge's practice of listing the commits included in each release a standard practice for all releases? It's super handy for quickly tracking what fixes are included in each version when helping people out.
@ionic elk I don't know what you are referring to.
onyx hinge
in one set of release notes I had links to PRs not sure if that's what is indicated
ionic elk
@slender iron I think I still need a better idea of what you mean. The idea with the clock overrides is that the frequency can be overwritten to any value, and the I2C timing "code" will be different for every frequency. So there isn't really a generic way to map it unless we pick some specific frequencies to favor over others.
@onyx hinge yeah I just thought it was a nice touch, it's been handy for helping people find the best release to use for a given bug they were encountering. Saves digging into git. I don't know how much extra work it is though, no worries if it's a pain in the butt π
@slender iron back on the I2C thing I definitely agree it isn't ideal to have the I2C timing codes in a board def, but I'm still trying to get a handle on how essential the entire clock override thing even is, it was kind of a bonus feature/cleanup I fit in alongside some required LSE and speed fixes. I think implementing the best fit code would be a lot of work on a need that isn't really verified, which is why I've been suggesting "shortcuts" even if they're a little crude.
onyx hinge
this will get you the PRs themselves by number: $ git log --oneline --first-parent 5.2.0..5.3.0 | grep -oE '#[0-9]+'
lucid solar
@ionic elk @slender iron I can see the timings listed in the cubemx data files...maybe we can extract them?
onyx hinge
which you kinda need to know to write the section, making it a link is just including the PR# itself
ionic elk
@lucid solar I mean I guess one way to do it would be to have a big lookup table for every frequency at every I2C speed... but still, I'm just wary of spending more time on this without explicit request from @slender iron , every other board uses the max speed right now so this is all just kinda for the F746Disco if implemented?
slender iron
@onyx hinge yeah I just thought it was a nice touch, it's been handy for helping people find the best release to use for a given bug they were encountering. Saves digging into git. I don't know how much extra work it is though, no worries if it's a pain in the butt π
@ionic elk Ah! Ya, maybe. Release notes are a bunch of work but adding the PR numbers may not be. I was already looking at similar data.
onyx hinge
I think you could do more scripting on top of it, use the API to retrieve the name, the author, the reviewers, etc.
slender iron
@ionic elk I'd prefer to standardize the clock speed rather than trying to support every configuration.
@onyx hinge I agree but think it should be edited. I don't like release notes that are just a dump of commit messages. We already have a source for that.
onyx hinge
PR titles are hopefully good though
slender iron
ya, at least a good start. autogen -> edit makes sense to me
orchid basinBOT
ionic elk
@slender iron so, just to recap - clock speed and I2C timings now standardized by default for every board that doesn't explicitly override it, like the F746Disco (and even for that board the override is kind of an experiment with this RAM thing). So right now this I2C timing thing is totally optional, it's only required if you want to mess with your clock settings for some reason. Are you ok with keeping it in in the current form, in that context?
slender iron
I don't think the 746 should be special
ionic elk
Ok that's a different thing then.
onyx hinge
@raven canopy any idea whether this data can be accessed from the github API? I didn't find it yet. Screenshot from https://github.com/adafruit/circuitpython/pull/3026
ionic elk
Right now it's kind of an example for how theoretical clock-overriding can work. I figured it'd be the most useful for people who are creating boards that they want to hit a very particular power-profile with. But again all of it is optional.
onyx hinge
(it's just coincidence that I'm also talking about an STM PR, it was the first one with a linked issue I found)
slender iron
@ionic elk I think it makes things more complicated than it needs to be
ionic elk
@slender iron could we chat about this for a sec? I'm not really getting what your goals are
in amelia?
slender iron
sure
raven canopy
@onyx hinge not that i know of. i peeked in the API docs, and i didn't see anything. looking at the page source, it seems JS-powered. but the source target isn't an API endpoint.
onyx hinge
@raven canopy interesting. I didn't find it either.
raven canopy
i wonder if the v4 API has it...
lucid solar
@ionic elk what's the current status with stm32 and master? because it seems nucleo_f746zg is crashing now.
solar whale
@lucid solar not sure what issue you are having, but just to make sure, did you know about the transition of the top branch from master to main?
lucid solar
@solar whale nope...missed that one...
solar whale
yes -- try checking out main
lucid solar
ok...do you know the reason for the change?
solar whale
see https://github.com/adafruit/circuitpython/issues/3021 historical meaning of "master"
lucid solar
ah...does it mean history as in 'master/slave'?
solar whale
yes- exactly
lucid solar
ok...I see...then I support the change π
manic glacierBOT
simple pulsar
Is my understanding correct on variables prefixed with _ not being visible outside of that library? I was just having a look at an mpy file and noticed they appear as is inside there.
tulip sleet
they only disappear if they are in the top level and are in const(...). Then the compiler removes them. Otherwise it's just a convention.
simple pulsar
I thought there was one solitary area where python enforced this but I must be confused. It could have been using const() has caused that confusion.
tulip sleet
if you do tab completion you don't see the _ stuff unless you expliclity type a _. But yes, const() is special, and is specific to micropython/circuitpython
simple pulsar
@tulip sleet Yes, that's it, thanks. I've just updated my description in https://github.com/adafruit/Adafruit_CircuitPython_BLE/issues/83
idle owl
@tulip sleet With that code being out of date you mean it's using the from adafruit_circuitplayground.bluefruit import cpb ?
tulip sleet
no, see discussion just a few mins ago in #help-with-circuitpython re Animation.group, etc.
I'll make it clearer
onyx hinge
I just noticed this, maybe we can get rid of some of the gyrations in our github actions checkout: https://github.com/actions/checkout/releases/tag/v2.2.0
Fetch all history for all tags and branches when fetch-depth=0
fathom trellis
Hey folks, x-posting from #general-tech.
I'm be chatting with Scott today at 4pm PDT.
Details on tuning in: https://twitter.com/nnja/status/1271557967150641152
ionic elk
@onyx hinge how hard would it be for you to set up your STM32 with RGBMatrix again?
I'm having a really hard time getting decent behavior out of mine and I'm starting to worry it's not just a connection issue
onyx hinge
It's not how I wanted to spend my friday evening
onyx hinge
I can put it back together, mention it to me in the monday meeting if I don't say something first
ionic elk
Ok, I'll send you a ping then.
When you were assembling yours, did you find that you could get usable performance using jumpers? Or was soldering a perfboard an absolute necessity?
onyx hinge
I breadboarded it.
ionic elk
no flickery pixels or anything?
onyx hinge
I'm trying to remember if it was this one or nRF that I never actually wired up all the address lines though
https://blog.adafruit.com/2020/05/10/testing-out-rgb-matrix-support-in-circuitpython-for-stm32f405-st_world-stmicroelectronics/ It worked for limor
ionic elk
I'm more just asking from a possible EMI or noise perspective, so that would be any chip
onyx hinge
double image but that's more an artifact of the camera shutter than bugs
both nrf and stm I just breadboarded
ionic elk
yeah that looks just like my setup... HMMMM
My Feather M4 express works fine to but I haven't tested it with my jumpers yet... If it is a code thing I wonder what could have changed.
onyx hinge
you could try at the specific commit where the support was merged, or the specific commit that was the last commit in the pull request. Making sure that the protomatter submodule matches with git submodule update.
it seems to me that if both of those fail, it's an indication that it's not some unidentified code change.
ionic elk
Good idea. Just tested the M4 Express with jumpers, and it has no problems, which seems like a preliminary indication of code problems
I'll try the old commits and narrow it down tomorrow.
crimson ferry
Has anyone figured out which build to use to test ESP32-S2 I2C? It seemed like esp32s2_busio branch of tannewt's repo, June 3rd commit being the latest successful one (WROOM en_US build of "Build CI #216: Commit c447c9f pushed by tannewt"), but: CircuitPython 5.4.0-beta.0-390-gc447c9f35 on 2020-06-03 I2C Initializion Error: name 'busio' is not defined
simple pulsar
For displayio I assumed it only updated parts of the screen which changed? Is that the case? I've discovered something bizarre I can do with a TFT gizmo where the person holding it (me) can act as a conductor and pass signals between pins accidentally. You can see the effect on the display in https://www.youtube.com/watch?v=h5VPk8JsDXk - I can make it draw on parts of the screen where the object (sprite) is not supposed to be. If displayio was only updating the real sprite position then I'd expect it to leave debris on the display? The real sprite position is vertically central and on the left.
tidal kiln
maybe the signal corruption is also causing the location skewing?
manic glacierBOT
simple pulsar
@tidal kiln They are bizarre but I'm okay with the position changes. What's weird is they get cleaned up when I take my fingers away from the pads. I'd expect the debris to be left on screen if displayio was only updating the true area/location of the sprite, i.e. a 48x48 patch on the middle left.
manic glacierBOT
manic glacierBOT
manic glacierBOT
lone sandalBOT
lone axle
I have a Git question: In order to make a PR on a library I fork the library, then clone my fork locally. I make a new branch and make the changes in it, then push and make my PR to merge from my new branch to the Adafruit forks main branch. The PR gets accepted, so now adafruit\main has those changes but foamyguy\main does not. What is the proper (or easiest) way to get those changes into my fork's main branch? So that if I make other new branches in the future for other PRs I can be starting from the same place as adafruit\main.
Deleting the fork in github and making a new one works, but takes a while. If there's a way for me to get my fork updated that would be ideal. I could merge it locally and push but I think this would make extra commits if/when I made a new PR. I'm thinking either squash, or rebase can help with this. But I don't know much about them to be honest, and don't want to mess anything up for the main fork.
solar whale
After the Adafruit repo has the megred PR, I do the following git fetch upstream master git merge upstream/master git push origin master
that updates my local copy of the upstream (adafruit) master -- then merges it in to my local master -- the pushes that to my fork
I'm still using master for the libraries since thay have not been ported to main...yet
lone axle
Perfect. Thank you, and yep same here but I'm anticipating that coming
Do you think there is likely to be trouble with this PR? https://github.com/adafruit/Adafruit_CircuitPython_PyBadger/pull/33 The fork it's from is 2 commits behind adafruit\master
in the changes I do not see removals of the things added with those commits (a button debouncing example) so I think it shouldn't get removed when/if this PR is merged.
But I didn't notice that it was behind until a few minutes ago.
solar whale
I think - if there was a conflict, it would tell you
lone axle
Okay thank you π I am working on another update now to add support for the Pew Pew M4 which has a similar screen to PyBadge and similar button set, plus a handy little badge clasp cutout at the top.
solar whale
As long as the things that were added are not touched by your changes, it should not matter
Thanks for doing these updates! As usual a simple change mushroomed into more than you bargained for!
lone axle
Yep. I'm happy to work on it, am learning lots about this library and how it is structured to work with all of the different devices.
Oh, I need to add the unsupported exception to the acceleration property
onyx hinge
yes, the way I do things is to have both my fork and the repository I will submit pull requests to as "remotes" in get terminology. I tend to use "origin" for where I'll submit PRs to, and "jepler" for myself, remote names can be whatever you want. So I start a new branch with git fetch origin; git checkout -b newbranchname origin/main^{} which is a bit of an arbitrary incantation but works well. Later, I git push --set-upstream jepler newbranchname before submitting the pull request.
I don't "maintain" the main branch of my own fork, it just sites whereever it was when I forked it
simple pulsar
@tulip sleet If you're doing work in the BLE area, you might want to take a glance at https://github.com/adafruit/circuitpython/issues/3030 - I can reliably cause disasters with start_scan() and playing looping audio at the same time including hard fault / safe mode / random errors but only when supplying a buffer to WaveFile.
wise shard
Wow this whole time I never scrolled down on the sidebar and thought there were only help channels not language-specific channels. π
static jay
@wise shard learn much can you by lurking here Obi wan (sorry Star Wars is on)
manic glacierBOT
lone axle
are the "latest" docs pages intentionally 404 for some modules? For instance this page works: https://circuitpython.readthedocs.io/en/5.0.x/shared-bindings/os/__init__.html but this one does not: https://circuitpython.readthedocs.io/en/latest/shared-bindings/os/__init__.html
lone axle
I see. Will the links built into the version dropdown at the bottom left fix themselves eventually or is there something required on our part to get those back to working?
onyx hinge
the "versions" links just change the /5.0.x/ -> /latest/ component, they don't fix other parts of the URL which may differ.
lone axle
I wonder if it's possible for the "latest" one to behave slightly differently and change more of the URL. The way the docs get built is still a bit of a mystery to me honestly. But I'd be happy to spend some time trying to get that "latest" link fixed if possible. I keep clicking it and winding up on 404 pages π
onyx hinge
Hm it's not as simple as "renaming" things to appear under /shared-bindings/ instead of /autoapi/ -- for instance, TileGrid used to get its own page: https://circuitpython.readthedocs.io/en/5.0.x/shared-bindings/displayio/TileGrid.html but it became just an anchor on the overall module page in main: https://circuitpython.readthedocs.io/en/latest/autoapi/displayio/#displayio.TileGrid
huh that is weird. The source says: ```shared-bindings/displayio/Palette.c://| palette[1] = b'\xff\xff\x00' # set using 3 bytes
the 5.0.x docs say: palette[1] = b'\xff\xff\x00' # set using 3 bytes
so far so good
the latest docs say: palette[1] = b'ΓΏΓΏ' # set using 3 bytes
somehow the escape codes have been interpreted into characters
onyx hinge
@lone axle fwiw I appreciate your remarks about doc paths and agree with them, I just don't see a way to get 100% compatible with the old version links... I'll continue poking around. Thanks for raising the issue again.
lone axle
Thank you for looking into it π
solar whale
@prime flower @slender iron I am about to give up on finding a way to use feather_m0_rfm9x board for anything more than the examples in the library. Adding a sensor like the bme280 in the example that started this, may not be feasible any more. How hard do we want to try?.... the only way i was able to get a stripped down version (no reliable datagram) to fit was to remove "math" but that is needed by the bme280 lib.... As to reducing the rfm9x library size, I have found a few hundred bytes, but we need much much more than that and the same goes for the bme280 lib. Perhaps we should talk "in the weeds" tomorrow about the planned support for M0 boards going forward - especially the non express boards. Should we just to update the guides and remove the M0 boards at this point. This is the guide that has prompted this https://learn.adafruit.com/multi-device-lora-temperature-network I think we were still in 3.x when it was written
simple pulsar
@solar whale @prime flower @slender iron Is the "base free memory" tracked per board for new versions of CP to see how it varies?
solar whale
@simple pulsar Not sure if this is what you have in mind, but it is reported with the build -- not sure if it is tracked ```jerryneedell@jerryneedell-ubuntu-macmini:~/projects/circuitpython_jerryn/ports/atmel-samd$ make BOARD=feather_m0_rfm9x
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
Note: compression increased length 'USB Busy' 8 9
185568 bytes used, 2592 bytes free in flash firmware space out of 188160 bytes (183.75kB).
8940 bytes used, 23828 bytes free in ram for stack and heap out of 32768 bytes (32.0kB).
Converting to uf2, output size: 371200, start address: 0x2000
Wrote 371200 bytes to build-feather_m0_rfm9x/firmware.uf2
third line from last
simple pulsar
I was just tihnking it's a key metric as it's needed to verify that intended changes have the desired effect and make sure there are no unintended changes. Software seems to generally bloat over time and can make the M0 boards less viable over time. In this case it's invalidated Learn Guides like the one in question here mentioned in https://forums.adafruit.com/viewtopic.php?f=60&t=166139 (assuming this one is simple case of interpreter growth in memory usage). I've bought CPX boards for most of my friends and a few Gemma M0 too so I have an interest in this too.
solar whale
I'm not sure memory has been impacted that much as CP has grown, but the memory usage of some libraries has. I think that is the problem with the rfm9x example. The m0_rfm9x can run the current rfm9x library and its examples, but it can't handle adding a big sensor or display which people often want to do -- and was done in the impacted guide. So the board is not "useless" limited in application with CP..
Sorry -- I have to go AFK for the evening -- Happy to discuss this more tomorrow.
simple pulsar
@solar whale Sure, have a good evening. One set of datapoints from REPL: I had a CPX nearby still running 4.1.0 and that has mem_free() showing 21680. Just upgraded it and 5.3.0 is 20880
onyx hinge
It is not systematically tracked. I did notice that there is a script that is supposed to help you locally build selected commits and track how size is affected, but it probably has not worked in a very long time: tests/codestats.sh
the default stack size is something that was increased during the v5 development cycle, so the proportion of your e.g., 23828 bytes that are allocated to each one is different than it used to be (more for stack)
slender iron
@lone axle I don't bother keeping my main branch up to date. When I start a new working branch I just use adafruit/main
lone axle
Ah, that makes sense. Thank you
onyx hinge
(I managed to not work on circuitpython for nearly 1.5 days out of my 2-day weekend ... then it all came crashing down and I did work)
simple pulsar
@onyx hinge https://www.youtube.com/watch?v=UPw-3e_pzqU
onyx hinge
hehe
manic glacierBOT
simple pulsar
Can the main code in CircuitPython be deployed as code.mpy ? I see there's an old issue for this: https://github.com/adafruit/circuitpython/issues/145 It just struck me that it might help with getting that Feather + Sensor + Radio code working again.
lone axle
@simple pulsar quick test on a CPX makes it seem like no to me. I mpy-cross'd a code.py file and dropped it in CIRCUITPY but it does not get run when the device boots up.
simple pulsar
@lone axle Interesting. It's fairly easy if a little unnatural sometimes to punt out loads of the code into another file, mpy-cross that and just import it, of course.
tulip sleet
lone axle
yep, we've used a similar process for devices that are getting deployed in fixtures.
being able to launch code.mpy directly without the extra file and import would be nice though π
simple pulsar
It does start to obscure the code so it's not all positives. This sort-of came up in the discussion on https://forums.adafruit.com/viewtopic.php?f=60&t=165419
prime flower
@simple pulsar I fwd'd the lora radio+bme info. to ladyada. I'd like to update the guide to use a more powerful feather (m4) and the radio featherwing instead. imo adding code as a mpy would obfuscate the code :\
onyx hinge
@simple pulsar I looked into it at one point and didn't find a way. However, you can reduce your code.py to 'import realcode' and have your realcode in a .mpy file.
I don't think that just adding .mpy to a list of extensions worked
btw for squeezing into limited RAM, did you investigate reducing stack size via boot.py?
simple pulsar
Me? No.
onyx hinge
It was increased to fit the do-everything library on cpx; you might be able to decrease it for your particular use-case, or it might be ineffective.
(apparently, importing large mpy files takes a lot of stack)
tulip sleet
the stack size increase for the CPX library was needed because of a 5 or 6-level-deep call chain during __init__(). __init()__ for the main class gets called during import because of the assignment to the singleton cp.
We had this assignment before, but the addition of a subclass in the CPX library and I think some additional nesting in some device libraries caused the stack overflow
thorny jay
@tulip sleet In current state of CP bleio, is it possible to be an HID keyboard (or mouse) for multiple computer simultaneously? The CP board would keep advertising itself, and accept other client. When I read example code, everything seems so easy, but I don't see where I specify what connection to use for those HID message. I am learning by example right now because it lack a bit of documentation right now.
tulip sleet
@thorny jay You would need to create multiple instances of HIDService, and refer to the .devices for each one, e.g. https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/master/examples/ble_hid_periph.py#L34. I think the nRF softdevice can handle only one set of advertising at a time: you can't start up multiple separate advertisements. There may be other restrictions or bugs that are not obvious π
thorny jay
Thank you, I'll give that a try. So I can advertise one, get a connection, then advertise a second HIDService. Do I need two "ble = adafruit_ble.BLERadio()" or iterate on the ble.connections. There seems to be dragon everywhere. There are very few lines of code, and still behind you can feel that some complex stuff are going on in the library.
onyx hinge
Hi all and especially <@&356864093652516868>! The CircuitPython weekly meeting will be in about 15 minutes. If you have a chance to update the notes doc with your hug reports and status updates, that would be excellent https://docs.google.com/document/d/1CZOWdmPGYcvt9WVl_NBxi-M3RXRtTklC13YtziBAu_Y/edit?usp=sharing
If you're going to be "lurking" (that is, you'll be in the audio channel but will not contribute during the round robin sessions), we need to know that. You can let me know here in the chat by saying "lurking", but adding it to the notes doc is even better.
If you're not yet a circuitpythonista but would like to be informed of meetings, let one of us know and we'll add you. We also have a calendar that you can view online or add to your favorite calendar app https://raw.githubusercontent.com/adafruit/adafruit-circuitpython-weekly-meeting/master/meeting.ical https://open-web-calendar.herokuapp.com/calendar.html?url=https%3A%2F%2Fraw.githubusercontent.com%2Fadafruit%2Fadafruit-circuitpython-weekly-meeting%2Fmaster%2Fmeeting.ical&title=CircuitPython Discord Meeting schedule&tabs=month&tabs=agenda
turbid radish
I've got a huge Python on Microcontrollers newsletter cooking and it'll be in mailboxes Tuesday morning. If you'd like to subscribe, go to www.adafruitdaily.com and click on the Python on Microcontrollers newsletter
ivory yew
GMail already refuses to show the entire email. π
turbid radish
Yes, we include a "click for browser view" at the top of each one
Contributions to newsletters gratefully accepted, you can submit a GitHub PR on the latest at https://github.com/adafruit/circuitpython-weekly-newsletter/tree/gh-pages/_drafts
manic glacierBOT
old smelt
Lurking
prime flower
Lurking
tidal kiln
lurking
onyx hinge
maybe you can use ffmpeg to convert all the pitches up an octave or two?
turbid radish
lurking
trim elm
lurking
ionic elk
The chipmunks are eating our garden strawberries, you can have them
simple pulsar
lurking, may run off briefly to get some food too
errant grail
Text only today.
thorny jay
Lurking
uncut nexus
lurking today
onyx hinge
@turbid radish that last one's a twitter handle right?
turbid radish
yes
onyx hinge
@gilded cradle I guess the displayio work is reflected in some other repo than the main blinka one?
gilded cradle
Yes @onyx hinge https://github.com/adafruit/Adafruit_Blinka_Displayio
onyx hinge
the stats underrate you tragically
gilded cradle
Yeah, it would be nice if it included all the Blinka-related ones too
raven canopy
that should be fairly easy. just need to add the repo for collection.
as will be in my status, i'll be giving some attention in that area, so feel free to put up a new issue
onyx hinge
@slender iron If you have a link to the Python Tea video that'd be great. I just went poking for 30 seconds and didn't find it -- https://www.twitch.tv/nnjaio/videos says it can't show me a list of videos for some reason
raven canopy
hmm. i just watched it a few hours ago. twitch is now reporting "temporarily unavailable". changed the filter from "Featured"...there they are!
Β―_(γ)_/Β―
turbid radish
I review guides
onyx hinge
ooh congrats on your guide @lone axle
onyx hinge
@inland tusk so please close your camera
inland tusk
I
slender iron
π
inland tusk
I am lurking
slender iron
@inland tusk gonna hop back in?
lone axle
Same here with text selecting
inland tusk
Yes I am but I am going to be lurking
slender iron
kk
thorny jay
Did we loose recording because we lost @idle owl's computer?
turbid radish
Con-Kattni-ate
thorny jay
DΓ©jΓ vu.
inland tusk
It will not let me into video chat
slender iron
ya, we're not doing it anymore
onyx hinge
inland tusk
okay
slender iron
because it limits the number of people who can join the meeting and most folks don't use it
solar whale
raven canopy
def test_available_members(board):
""" Verify the attributes and members available in ``digitalio``.
Expected result: ['__class__', '__name__', 'DigitalInOut', 'Direction',
'DriveMode', 'Pull']
"""
expected = {'__class__', '__name__', 'DigitalInOut', 'Direction',
'DriveMode', 'Pull'}
with board:
board.exec("import digitalio")
result = board.eval("dir(digitalio)")
final_result = set(result)
assert not final_result.difference(expected)
Doh! I knew I was forgetting a hug report π . Thank you for working on that sommersoft!
prime flower
@onyx hinge lol! no π
onyx hinge
simple pulsar
Would be interesting to hear in a sentence or two why the adafruit_ble is useful on a desktop? (I have never tried BLE programming on there).
tulip sleet
so you can talk to BLE devices (both CircuitPython and others) from ordinary host computers. For instance, you can now use our CircuitPython library code to talk to, say, a heart rate monitor from the host computer.
Note that the bleak implementation can -only- act as a central, not a peripheral
raven canopy
status-update-afterthought-screen-grab:
simple pulsar
onyx hinge
@simple pulsar how do the results change if you double the time between announcements?
thorny jay
It is frequent for "networked" device to be "synchronised" in their behaviour.
onyx hinge
I don't know enough BLE to know if this "fills" the available time, letting some device starve instead of being able to send, which is why I suggest doubling the time
ivory yew
Sorry I missed today's meeting, but I'm excited to be a mod and help out! π
solar whale
Glad to have a new mod!
errant grail
There may be a "sub-culture" of folks modifying existing libraries to work better on the M0. I've done that with a few that were critical to older projects. How about creating a community-based repo for those?
idle owl
I think the Community Bundle works.
errant grail
Indeed. Not obvious in this case, but will be something I'll consider now.
lone axle
Maybe the guides could be expanded upon to show the use Featherwings and Feather M4s
simple pulsar
I wonder about the CPX synth stuff I did with adafruit_midi - that was very tight on memory - https://learn.adafruit.com/cpx-midi-controller
thorny jay
Do we need a Trinked M4?
onyx hinge
@thorny jay there's not a SAMD51 in the right package, I think
you need to go up in footprint to itsy bitsy
tulip sleet
Trinket M0 uses a 32-pin package; SAMD51 only has 48 pin and up
thorny jay
I recycle Trinket M0 to do USB host thing.
tulip sleet
it could conceivably be done with a BGA package, but those are harder to manufacture, and the ItsyBitsy is still pretty small
ivory yew
the qfn samd21s are really small.
tulip sleet
USB_DEVICES
ivory yew
not much incentive to go to bga unless you already have a bga part and you're paying extra for that manufacturing cost anyway
onyx hinge
Thanks Kattni!
lucid solar
@tulip sleet @ionic elk @slender iron I'm debugging an issue with USB not working on the STM32F7 after the VCP code was added. It turns out that a variable is being optimised out. Which is why it worked on my machine as I had debug enabled. Do you know how we can stop it being optimised out? https://github.com/adafruit/circuitpython/blob/9285252fbcbe4db654bc69621210883380fb6981/ports/stm/common-hal/busio/UART.c#L43
tulip sleet
@lucid solar is it the "optimized out" you see in GDB? That doesn't necessarily mean it's gone completely, just that its lifetime/scope is narrowed and it is not available. Maybe you need to make it volatile? That's often a debug/non-debug build difference. The debug version is sometimes accidentally volatile.
lucid solar
Hmm...I've added volatile and it didn't fix it.
Now it seems to not be optimised out though....
tulip sleet
another difference would be that it is not being initalized properly, and so the debug version accidentally works due to a different random initilaization
lucid solar
When I check the variable, it seems to contain the correct data, even in non-debug version
solar whale
@tulip sleet sorry -- I'm just missing something -- where do I ahve to set USB_DEVICE to turn off USB_HID and USB_MIDI?
tulip sleet
@lucid solar are you seeing that it's being read incorrectly? this may be a red herring; for instance, debug/non-debug can also cause timing differences which might cause working/nonworking
solar whale
I was just setting CIRCUITPYTHON_USB_MIDI=0 in mpconfigport.mk
tulip sleet
@solar whale set USB_DEVICES="CDC,MSC,HID". The default is "CDC,MSC,AUDIO,HID". (order doesn't matter)
lucid solar
@tulip sleet if I remove lines 69 and 70 (https://github.com/adafruit/circuitpython/blob/9285252fbcbe4db654bc69621210883380fb6981/ports/stm/common-hal/busio/UART.c#L69) it works just fine...but that's a hack, not a fix.
It really feels like it's something totally unrelated, and it's just this where it fails.
tulip sleet
yeah, i'm not sure what uart has to do with USB here
lucid solar
I agree!
tulip sleet
is there a check to use UART for output if USB is not present, or something like that?
lucid solar
They are linked in supervisor/serial.c
What's weird is it doesn't crash, it just usb doesn't work...the uart works fine
tulip sleet
@ionic elk may have some inkling, sorry. did you make both never_reset_uart[] and reserved_uart[] be volatile? Or maybe it's a race condition?
lucid solar
I tried with both as volatile
@tulip sleet thanks for your help so far. I'm going to watch Brian Lough's stream now...so I'll get back to it tomorrow.
ionic elk
If it doesn't crash, how do you know the point at which it fails?
lucid solar
@ionic elk going through all the code disabling it line-by-line.
solar whale
@tulip sleet sorry to keep bugging you on this - is there an example board where USB_DEVICE is used like that - I can't find one.
ionic elk
Yeah I'm not sure what's up with that one line causing that level of issue
@solar whale most STM32 boards have incomplete lists of USB devices due to limited endpoints, you could check them out
tulip sleet
@solar whale ports/stm/boards/stm32f412zg_discovery/mpconfigboard.mk
solar whale
just wondering why pewpew10 works as is?
ionic elk
@lucid solar my intuition for anything that disrupts USB is usually a clock or timing issue. When things start failing at random points, I usually worry that flash is being overwritten or the debugging link is being shut down. Do you have a debugger?
other than the STLink, I mean
lucid solar
I use the STLink on board...why would it be different?
ionic elk
I don't think there should be any reason, just wondering.
lucid solar
I've got an external STLink v3...I guess I can try it...maybe it's a power thing....as the device doesn't really shutdown.
solar whale
@prime flower @slender iron @tulip sleet woohoo! major breakthrough - I have built CP for the m0_rfm9x board with the current library frozen in -- I had to take out a lot and can now see what I can put back --
prime flower
@solar whale Nice! Does BME280 fit as well?
solar whale
have not tried -- yet
idle owl
@slender iron The first half of the video doesn't have anyone else's audio even though OBS was hearing it - so apparently the crash corrupted one of the audio tracks. The second half of it has both. What should I do here.
solar whale
I doubt it
prime flower
@solar whale out of curiosity - were the removals mainly the new features (crc, node addressing)?
idle owl
I was hoping the same thing that happened last time it crashed would happen - where converting the vid for YouTube saved part of the whole thing, but there's not even anyone else's audio on the original, so there's nothing to convert.
Concatenate it and post it without half the audio? Post the second half? Skip the video this week?
solar whale
I did not remove anything for rfm9x -- from CP i had to remove several modules (analogio,rtc,rotaryio,touchio,midi,hid,neopixel_write)
@prime flower with a smaller rfm9x -- I should be able to put some back
prime flower
@solar whale ah, ok I misread. That is exciting!
solar whale
Yes -- renewed my enthusiasm!! I have to go AFK for now but will continue on this tomorrow.
prime flower
sweet - let me know if you need help splitting apart the RFM9x library.
ionic elk
@onyx hinge might I ask why primary/secondary was selected for the I2C terminology? Is that following a standard set by another project?
When I was looking around I thought that name combos like manager/subordinate and monitor/subsystem had the advantage of keeping the acronym, and also retained good information about the device relationship. Seems like they might be good for beginners who are looking at mixed documentation about their devices.
onyx hinge
@ionic elk I am mostly just trying to follow along with others' best recommendations. I thought we were going towards main/secondary, since those conserve the letters m/s as initials, leaving MOSI and MISO "intact", but it's possible as always that my wires got crossed
ionic elk
main/secondary is definitely better! Though I still feel it doesn't really reflect the actual relationship between the devices so much. I really like manager and monitor because they reflect the actual information pathways even better than master did - it implies a two way reciprocal flow of information.
I don't know if there's a particular reason why git used master at all, but it doesn't seem to me like we need to be married to main for everything - it's a great name for a repository but I don't think it says much about communications.
ivory yew
git's master came from the same etymology as a master recording, but it's such an arcane derivation that clearer alternatives should definitely be used. π
onyx hinge
Etymology is a rabbit hole I find myself falling down frequently.
ionic elk
yeah I see a big bonus of all this is that all these old terms were never very descriptive or useful anyway. Like "slave" devices rarely even have that role, it's actively misleading
ivory yew
just remember that etymology is useful for history and not a rulebook. :3
onyx hinge
The last one I fell down was: Why is french "fromage" when so many western European languages are similar to "cheese".
ivory yew
Yeah like most SPI/I2C devices are fully independent devices.
ionic elk
anyway I'm just brainstorming, as long as the acronyms stay the same that's the big thing for me. I'd like to ease guides and introductions for beginners as much as possible.
ivory yew
Yeah keeping MISO/MOSI the same is good.
Though we can drop the SO and call it "Main in", "Main out"?
onyx hinge
No, you need to keep it, just in case you have the lesser-used connections SOSO and MIMI
ivory yew
Suz used something in her guides that was good and kept the acronyms. Let me find it.
ionic elk
wanted to put in my two cents and some of the alternatives I found. manager/subordinate is my vote, if it counts for anything. A boss and employees seems the closest to the actual relationships my devices have
slender iron
@idle owl I think all video even though some audio is missing
ivory yew
this is good: https://twitter.com/noopkat/status/1256795369301700608
slender iron
(sorry was at lunch)
idle owl
@slender iron Ok. Thanks.
onyx hinge
Never apologize for lunch.
ivory yew
unless it's a bad lunch
slender iron
do you have multiple audio track setup during the recording? maybe it's just not the one that gets played
ionic elk
@ivory yew oh neat that's a nice comic, so there is some precedent
ivory yew
Yeah and Suz is great. I'd listen to her over me any day. π
idle owl
@slender iron I tried looking to see if there was another track anywhere, VLC isn't seeing one on either video, including the one that worked properly.
Single track only.
slender iron
kk. how about recording a head up and concating it at the start
that way podcast folks will know what's up
idle owl
um... ok. will do.
slender iron
if that's too much work then notes-only is fine
onyx hinge
Anybody want to help me workshop this possible new text for our design guide document, docs/design_guide.rst? ```
Terminology
As our Code of Conduct sates, we strive to use "welcoming and inclusive
language." Whether it is in documentation or in code, the words we use matter.
This means we disfavor language that due to historical and social context can
make community members and potential community feel unwelcome.
Two specific terms to avoid except where technical limitations require it are
"master" and "slave". In general, prefer the terms "main" and "secondary",
though other terms may be preferable in specific circumstances. Note that
"technical limitations" refers e.g., to the situation where an upstream library
or URL has to contain those substrings in order to work. However, when it
comes to documentation and the names of parameters and properties in
CircuitPython, we will use alternate terms even if this breaks tradition
with past practice.
Redlst/Greenlist has been suggested.
onyx hinge
yeah we have something called service_uuids_whitelist at least
ivory yew
meh, colors have different meanings in different cultures (streetlights in some countries are blue, not green). Allowlist/Denylist is getting some widespread adoption.
idle owl
fair enough.
ionic elk
blocklist clearlist came up for Rails
they went with allowlist/denylist though: https://github.com/rails/rails/issues/33677
onyx hinge
Terminology
-----------
As our Code of Conduct states, we strive to use "welcoming and inclusive
language." Whether it is in documentation or in code, the words we use matter.
This means we disfavor language that due to historical and social context can
make community members and potential community feel unwelcome.
There are specific terms to avoid except where technical limitations require it.
+----------------+-------------------+
| Preferred term | Deprecated term |
+================+===================+
| Main | :strike:Master |
| Secondary | :strike:Slave |
| Denylist | :strike:Blacklist |
| Allowlist | :strike:Whitelist |
+----------------+-------------------+
Note that "technical limitations" refers e.g., to the situation where an
upstream library or URL has to contain those substrings in order to work.
However, when it comes to documentation and the names of parameters and
properties in CircuitPython, we will use alternate terms even if this breaks
tradition with past practice.
looks good
idle owl
@slender iron it's fine. I think I got it.
slender iron
thanks @idle owl
I don't that we need to use the same terms for SPI as I2C
the other thing I was thinking about was the role of who controls the clock
clocker vs clockee
ivory yew
yeah tbh "Controller" and "Device" are good terms, but they absolutely break the acronyms for SPI.
slender iron
π
ionic elk
I think you could mention that these terms are actually more technically descriptive as well
It's not the point but it rounds out the argument. These were never good names to begin with and code makes more sense when they're changed.
onyx hinge
Main/Secondary for SPI, Main for git, Controller/Device for I2C, and allow/denylists for General ?
ionic elk
wouldn't it be better to keep I2C and SPI the same? Since they're interchangeable for many devices?
Lots of screens can be either I2C or SPI, it seems more beginner friendly to be consistent
onyx hinge
fwiw I agree, I was trying to interpret what @slender iron was saying above about the terminology not necessarily needing to match
- @ivory yew 's contribution of the controller/device terms
ionic elk
Yeah I'm just thinking of a prospective new user with an SSD1306 moving from SPI to I2C and finding all the terminology about the protocol changing
ivory yew
Eh. I don't know. The cognitive overhead of two separate protocols is more significant than the overhead of differing terms.
In fact, differing terms may help them more quickly identity which protocol is being used.
But it's hard to say without actual user studies
ionic elk
that's true. It's only a concern where the two protocols are interchangeable, such as for the screens.
onyx hinge
We can also take a step in a good direction now, and refine the suggestions later
ivory yew
Screens are pretty confusing altogether. Some even support parallel interfaces. It's gonna be hard and it isn't going to be because of pin labeling.
Agreed.
ivory yew
Also, more than anything a glossary helps and actively linking to the glossary when jargon comes up is super useful.
Idk how the Adafruit learning system works but I've written lint checks for things like that before.
(fwiw documentation and developer experience is my area of expertise)
onyx hinge
I don't think it has checks like that but there is a lot about Learn I don't know
ionic elk
Man little popups for glossary terms would be a spiffy feature
ivory yew
π€
slender iron
I don't think main/secondary are great terms but do keep MOSI and MISO working. I'd rather not see MOSI influence naming for other protocols
ivory yew
I still like host/peripheral.
ivory yew
Only because HIPO and HOPI are a lot of fun to say.
ivory yew
MController / SDevice.
onyx hinge
Mackerel / Sardine
onyx hinge
whoo .. that's more time than I intended today, working on things that are not SDIO. Important things to do, I believe, but .. not SDIO
thorny jay
What is Philips/NXP recommendation for I2C alternative naming?
slender iron
I like Host/Peripheral @ivory yew
onyx hinge
@thorny jay If you're interested in helping, why not investigate and let us know.
thorny jay
I do not wish to participate in newspeak. I just want to highlight that there is a great benefice in all the industry using the same name. If new protocol can avoid using those words, that is fine. But it will not be possible to remove it from all the documentation and memories. But anybody new comming into electronics will have to know both names, the politically correct and the previous ones. Does this help with learning electronic... I am not sure. But then again, I am not a native English speaker and not from the US (yes I believe this is mostly an US issue). So those names are just technical terminology to me.
PS: CP may also have an issue with translation if those words are use in error message. French was mostly done already, when I wanted to help... so I have no clue if there are a lot in there.
slender iron
@thorny jay These terms are not a political question. This is about inclusiveness. Please see the full draft from Jeff above for full details
onyx hinge
I accept others' reports that these terms hurt them, and I am acting to make things better. Perhaps you can accept that there is a uniquely American reason that these things need to be done, and at least stand aside and let us do it.
Speaking of standing aside, I'm 10 minutes late for an online meeting. β°
thorny jay
When I say "politically correct" (maybe a false friend from French) is not about politics, it is about using a new/other word when the old one is becoming controversial. Maybe you call that "respectful term"?
manic glacierBOT
slender iron
@thorny jay "politically correct" is a charged term to me as well because some use it to undermine the discussion. We are knowingly changing terms to be more inclusive and also more specific where we can. It will cause some confusion but we'll document it and teach it.
solar whale
@prime flower I did not "freeze" the bme280 lib - I don't think that is a good idea since other sensors may be used but the demo code from the guide does run with my modified build. I finnally found my bme280! I will now work on seeing what I can ad back to the CP build and what I can do to reduce the size of the rfm9x lib... so far I have re-instated analogio and neopixel_write
onyx hinge
(though of course it will fail .. there seem to be a bunch of boards that differ that I did not find in my pre-push checks .. mostly it looks like CIRCUITPY_USB_MIDI is enabled when USB_DEVICES doesn't have audio)
lone axle
I am trying to make a build of circuitpython for the cpx with an edited version of the circuitplayground library frozen into it. When I ran make I got these fatal outputs, but it did generate a firmware.uf2 file. Do these outputs indicate a problem?
onyx hinge
Basically, the build process is checking that the version of each frozen module being included is a tagged release
if this is deliberately not the case and is printed just as a warning, I think you can safely ignore it
lone axle
And/or is there some other step I need to take in order to make a test build beyond putting my edited code at frozen/Adafruit_CircuitPython_CircuitPlayground and running the make?
onyx hinge
I think it says "fatal:" but doesn't impede the build finishing
lone axle
I got a uf2 file and put it on my device but it seems like my changes aren't there.
Okay cool. I will poke around some more. Just wanted to make sure that wasn't telling me that it won't work.
Got it figured out, deleting the old build and starting fresh did the trick.
manic glacierBOT
onyx hinge
@ionic elk I'm encountering a hardfault on stm32f405 feather .. it looks like a hard coded number of ports doesn't match the hardware... I think I can fix it, but I just want to make sure I'm not out on left field. ```>>> import microcontroller
import digitalio
digitalio.DigitalInOut(microcontroller.pin.PD02)
at this point the serial connection drops and then if you're lucky you getYou are in safe mode: something unanticipated happened.
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.```
It seems that some code is configured to assume there are only 3 ports, but PD02 really is on the package and really is needed for SDIO.
The schematic shows that there are also a couple of "PH" pins but those have a dedicated function and should not be exposed via microcontroller.pin afaik
ionic elk
Oh shoot I totally missed PD2
it's the only D bank GPIO on the 64 pin packages
and yes, on everything but the super high pin count packages, H bank GPIOs are used for the oscillators only and aren't appropriate to expose
Anyway that's almost certainly the issue.
onyx hinge
thanks, building and testing now
what's an example of a UFQFPN48 , should I double check if it has any oddball D bank pins?
STM32F411CG
and I don't spot a random D-bank pin anywhere there
no PD2 for sure
lucid solar
@onyx hinge I've checked a couple of them also...didn't find any D-Bank...but F was for the OSC...
onyx hinge
Thanks @lucid solar !
hm my first stab at it didn't work
must be gremlins, I re-powered jlink and the board and it does work. so yay for small victories
ionic elk
@onyx hinge sorry stepped away. Nice!
I think PD2 is just one of these little easter eggs STM32 likes to leave in their everything
manic glacierBOT
manic glacierBOT
ionic elk
So, I'm trying to checkout https://github.com/adafruit/circuitpython/pull/2918 with github CLI, and it's checking out something completely different???
Oh, I see, it's a micropython PR.
onyx hinge
@ivory yew hey I'm chasing down some stuff about USB devices and I found this: ports/atmel-samd - winterbloom_big_honking_button: ../../supervisor/supervisor.mk:138: *** Computed USB devices '"CDC,MSC,AUDIO"' different than hard-coded USB devices '"CDC,MSC"'. Stop.
I think that AUDIO indicates MIDI-over-USB. If so, should big honking button have it, or not have it?
onyx hinge
okay, noted, I'll address it.
ivory yew
thanks. :3
since Winterbloom stuff tends to be pretty specialized, I'm pretty aggressive about disabling features.
ionic elk
@indigo wedge I haven't really touched mimxrt ADC yet, so this could be a dumb question, but why are pins B0_12 to B0_15 labeled ADC1? The RefMan says they're ADC2.
indigo wedge
you mean in 1021?
i didn't make that pin def π https://github.com/adafruit/circuitpython/blame/241ef528417c266fd396f61763fdc65be99229bb/ports/mimxrt10xx/peripherals/mimxrt10xx/MIMXRT1021/pins.c
@ionic elk looking at the 1020 RM some pins can be used with ADC1 and ADC2
ADC1_IN2 GPIO_AD_B0_15
ADC2_IN2 GPIO_AD_B0_15
ionic elk
@indigo wedge no, the 1060. I'm working on the 1050 atm
indigo wedge
ah sorry
i'd assume same situation
or i screwed up
very much a possibility π
tulip sleet
@slender iron hi, do you have time for a vid chat re Blinka_bleio and ESP32 BLE?
slender iron
@tulip sleet yup!
simple pulsar
@tulip sleet I'm not sure why it works but I've introduced a small degree of application level jitter into the Advertising and I can work around the bug/phenomena that I mentioned in yesterday's meeting. I put a graph comparing the two in a second post on https://forums.adafruit.com/viewtopic.php?f=60&t=166440
tough flax
Hmmm.. anyone on the Blinka team know if mouse & keyboard can be read/reacted to on RPi?
onyx hinge
@tough flax I don't know whether it's "built in" yet or not. If not, I have some Python code that works with general mouse/keyboard on Linux systems but it's not aligned to blinka yet
just some code from my far, far past that could be relevant
it's probably old enough that it needs python3 conversion
https://gist.github.com/jepler/f4bbcc5c1667753506ab994f36040a52 It's all my code, I will relicense it under the circuitpython license if it is of value to the community
tough flax
Thanks! I have a user who is trying to use a touchpad (t650) to control a device. It seemed easier to use blinks than to try usb host mode with two devices.
onyx hinge
I haven't used it with a mouse / trackpad in a long time, it may or may not work.
onyx hinge
looks like it needs adaptation for current systems and python3
onyx hinge
version that works with python3 (yay) https://gist.github.com/jepler/3fbf1ed75ae435361c38ce57838d8019
manic maple
hey
fiery urchin
ho wont to go to voice chat?
lucid solar
@gentle bronze I'm having an issue with USB and the serial console on a nucleo board. When I run it in debug mode it's fine, but when it's using optimization the USB stops working. Do you think you could help me debug the issue?
simple pulsar
For the RSSI stepping I mentioned in Monday meeting I just tested some boards from power-up and they appear to somehow synchronise within 8-11 seconds https://www.youtube.com/watch?v=TezUYj9Bobs
ionic elk
@slender iron having been looking at the conversations online (there's a lot of them now that Github has swapped over from Master to Main), main/secondary is by far getting the most traction. Even the wikipedia page for SPI has it as a suggestion right now.
lucid solar
@slender iron I still think mark/scott is better π
@ionic elk I've nearly traced this bug with the nucleo. It seems that it's likely down to some alignment issues. Does it sound right to you? any thoughts pop up from related/past issues?
ionic elk
I've never had alignment problems, sorry
@slender iron Gitlab and Rails are already using Allowlist/Denylist, so I think there's better precedent there as well.
lucid solar
Ok...basically when I enable the middle line it causes the issue...it seems any time I access the i var. It's somewhere else in the code it fails...but this must be the trigger.
reserved_uart[i] = false;
} ```It doesn't fail exactly...but it causes something else to not work. I've disabled all the lines that use reserved_uart...but left it inside the loop...and USB now works again.
I had an alignment issue in Zephyr that also caused something to stop working that was unrelated to the code I added.
Arm+Alignment+Optimization = headache
ionic elk
Sounds like the right approach. This is definitely a weird bug, because reserved_uart is basically only used for resetting the USART peripheral on a soft reboot?
Wait no, that's never reset. This is just for reserving UARTs from being used over each other
lucid solar
uart_taken = true;
continue;
} ```that's the first time it uses it...and it fails there
ionic elk
You aren't actually calling any of this from python, right? It's created entirely within C
lucid solar
correct...the only thing python does is blinky...
ionic elk
and this is disabling USB somehow?
ionic elk
so right now, you've got a build where if you just don't reserve the UART, both VCP and USB work
lucid solar
something like that...but if I totally disable VCP...it still doesn't work.
ionic elk
What I'm trying to figure out here is whether it might simply be that VCP being on is causing the timing issues with USB, and that by removing the reservation system, you are breaking VCP in some way that is enabling better USB timing.
lucid solar
I thought that...but it can't be...I totally remove VCP and it still doesn't work.
ionic elk
Because there is an existing "bug"/missing feature in UART which is that the writes are blocking and don't service tusb while running - if you write a very large string, it might take so long that it breaks your USB connection.
lucid solar
I'm 99.99% certain it's not that.
ionic elk
Just double checked the routine. Can you check the state of the reserved_uart array before and after the problem?
or after the uart_reset function runs, I mean
lucid solar
Yeah...
ionic elk
Because yeah, definitely weird that writing all 0 to an unused array is causing USB to crash
lucid solar
@ionic elk so...if I delete the 2 lines from the if statement it works...if I add one back...either of them...it doesn't matter...then it breaks the usb again
ionic elk
Is there any difference from that and what you said before? Did you find out what the array was before and after?
lucid solar
It doesn't matter...it's not the value of the array that counts...it's the fact it reads that memory.
The value of the array is correct π I did check.
ionic elk
So it's 0 before and after? I asked because I was thinking maybe it was pointing to the wrong location in memory somehow
and overwriting something
@lucid solar basically, what I'm trying to figure out is whether this section of code is actually doing anything at all that could even possibly be causing a problem under normal circumstances. If it is in fact taking an array full of 0s (which it should be, in both the line 69 and 70 cases, if there are no UARTS declared as never_reset), setting some values to 0 again (thus changing it not at all) and still crashing USB, at that point I would say you probably have memory corruption. Maybe a dangling pointer somewhere.
slender iron
@ionic elk can you reply on the PR so we can have the discussion there?
ionic elk
in which case you could check out where it's allocating the i variable to in memory and set a watchpoint on it or something
lucid solar
@ionic elk I fixed it!!!!!!!!! π π :)
STATIC bool __attribute__((aligned (4))) reserved_uart[MAX_UART]; Just had to add the aligned attribute to that.
ionic elk
huh
lucid solar
I guess it gets joined with some memory that's USB related...and then it freaks out...I wonder...do we enable the MPU at all on STM32?
ionic elk
We have the MPU on the F7 and H7 series, yes, but only for broad swaths of memory
I'm not sure why it would be worrying about the distinction between USB and text flash
lucid solar
I believe my 'fix' isn't the right one...meaning that the USB memory should be aligned...not this one. But at least I'm getting closer.
lucid solar
This is a diff between the memory maps of before and after the fix. It should help to find the memory that's not aligned correctly.
lucid solar
@ionic elk @slender iron So, the issue is...after using the reserved_uart variable (so it doesn't get optimized away), the memory is shared with the claimed_pins or never_reset_pins. Which means that the USB's reserved pins get reset at some point, so obviously it fails. Having those aligned to 4bytes...fixes the issue.
Expect a PR quite soon!
ionic elk
Wait, so the optimizer is causing an overlap of arrays? That sounds like a dangling pointer
lucid solar
@ionic elk no...it's static memory...
ionic elk
So why are they allowed to overlap?
lucid solar
They're not overlapping exactly...one sec...
ionic elk
The answer shouldn't be alignment, this kind of overlap should never be happening in the first place.
lucid solar
Can we video chat? should take only a couple of minutes for me to explain...
ionic elk
Sure, I'd like to get a sense for whether this could be affecting other STM32 boards
lucid solar
Ok...I'll go to my other computer (mic doesn't work on this..)
ionic elk
I'm in amelia
lucid solar
tulip sleet
@ionic elk @lucid solar as one of you mentioned, I would be suspicious that something else is unaligned (or the wrong length), and is overlapping into one of those arrays, not that the compiler needs it to be aligned. My very first PR to circuitpython was fixing a USB thing (in atmel-samd) that was mistakenly not aligned to a 4-byte boundary. https://github.com/adafruit/circuitpython/pull/118
ionic elk
@tulip sleet can you help me to understand what the conditions of this kind of overlap are? I'm just struggling to understand the context in which static arrays would need this kind of alighment protection
With a bug like this I like to understand why it came about and how to avoid it in the future and I'm really not sure of either in this situation.
tulip sleet
@ionic elk i don't think these arrays themselves need alignment. I think some other storage adjacent or near to them is smashing them, perhaps due to misalignment. E.g., an on-chip peripheral is expecting an aligned block of storage, and it's not aligned. Or, the length of such a block is not a multiple of 2 or 4 or something, but should be, and so it gets overrun.
In other words I think aligning the uart bool arrays is a red herring, and is a second-order bug
lucid solar
It's the claimed_pins that are being problematic....not the uart arrays...
Which means USB pins gets reset.
ionic elk
I have other questions about that. Normally, reset_all_pins, which is the only thing that interacts with the never_reset array, doesn't run unless you soft-reboot. Is that the only time your USB problems show up as well? Or do they appear right away?
lucid solar
right away, but port_reset gets run twice it seems, something to do with clean_up_after_vm(?)
ionic elk
claimed_pins and never_reset_pins aren't attached to registers by themselves, they're just masks for pin searches and reset behavior. So them getting overwritten with new values shouldn't be a big issue in and of itself.
oh hmm yeah that'd do it
So USB gets set up after the first port_reset, and then gets reset in cleanup
ok
lucid solar
yeah
ionic elk
@tulip sleet my first impression of this is that it might be a dangling pointer allowing values to get overwritten. But would alignment actually resolve that?
tulip sleet
i think it's an accident. Note in that file that the ports[] array is just before the pins arrays. so maybe that is being overrun or misinterpreted somehow. I'd look at the .map file generated by the linker to see what is adjacent to the pin arrays, in case there was some reordering.
lucid solar
tulip sleet
another thing to test would be to insert a two element uint16_t array before claimed_pinsp[], to see if it makes the problem go away. You'd have to make sure it wasn't optimzied away.
lucid solar
green is with the alignment 'fixed'
ionic elk
also, @lucid solar, I'm wondering why reserved_uart would ever get optimized out, if the UART module is included in mpconfigport.mk. uart_reset is called by supervisor, and in turn uses reserved_uart, so I'm not sure how the compiler would think it's ok to get rid of it
lucid solar
@ionic elk no idea...but it does π
No wait...it works when it's optimized out
having it there causes the issue
ionic elk
Yeah but I think it could be related. Something about the contents of UART.c not being given the correct consideration by the compiler
tulip sleet
i don't care so much about the diffs; please show me the original map file without the alignment. I want to see the adjacency
there is always a reason. There is a tiny possibility this is a compiler bug, but it's much more likely to be something else smashing the location. You could set a watchpoint on the arrays to see if they are getting smashed, and if so, where
lucid solar
@tulip sleet https://gist.github.com/k0d/4b16df1bb18e1b8fc132cc647a0ce351#file-foo-patch-L2147 I just found that this is the first part where it crosses a word boundry...happens to be the usb descriptor....coincidence? π
tulip sleet
the usb descriptor might need to be word aligned, but isn't. I'm still having trouble reading the diffs, just show me the .map
the diffs are missing information I want to see
lucid solar
I'll get them shortly...I have to recompile with the issue etc...
onyx hinge
if you have a debugger you can watch the location in memory you think is being corrupted, and any CPU access to it will act like a breakpoint
tulip sleet
exactly
onyx hinge
e.g., watch -l &reserved_uart[8] if you think something's touching the first byte past reserved_uart[]
but that means you have to have a good guess about exactly what is being touched that shouldn't be
tulip sleet
you could also add some code that checks to make sure the values are what you expect (e.g. write your own watchpoint code)
@lucid solar which board are you compiling for? I can try it here too.
lucid solar
nucleo_f746zg
tulip sleet
just checking, are you using a gcc 9 compiler
lucid solar
yeah...the one from 'brew'
simple pulsar
@tulip sleet BTW, that BLE deafness occurs with just two devices chatting, My guess-a-workaround seems effective so I can make my application more robust using that: https://forums.adafruit.com/viewtopic.php?f=60&t=166440&p=816177#p816177
lucid solar
@tulip sleet
tulip sleet
so these are all adjacent, which makes me think something's being overwritten:
.bss._setup_packet
0x000000002001a3c8 0x18 build-nucleo_f746zg/lib/tinyusb/src/portable/st/synopsys/dcd_synopsys.o
.bss.never_reset_i2c
0x000000002001a3e0 0x4 build-nucleo_f746zg/common-hal/busio/I2C.o
.bss.reserved_i2c
0x000000002001a3e4 0x4 build-nucleo_f746zg/common-hal/busio/I2C.o
.bss.never_reset_spi
0x000000002001a3e8 0x6 build-nucleo_f746zg/common-hal/busio/SPI.o
.bss.reserved_spi
0x000000002001a3ee 0x6 build-nucleo_f746zg/common-hal/busio/SPI.o
.bss.never_reset_uart
0x000000002001a3f4 0xa build-nucleo_f746zg/common-hal/busio/UART.o
.bss.reserved_uart
0x000000002001a3fe 0xa build-nucleo_f746zg/common-hal/busio/UART.o
.bss.claimed_pins
0x000000002001a408 0xe build-nucleo_f746zg/common-hal/microcontroller/Pin.o
.bss.never_reset_pins
0x000000002001a416 0xe build-nucleo_f746zg/common-hal/microcontroller/Pin.o
.bss.nesting_count
0x000000002001a424 0x4 build-nucleo_f746zg/common-hal/microcontroller/__init__.o
0x000000002001a424 nesting_count
@ionic elk do you know what _setup_packet is?
simple pulsar
@tulip sleet @lucid solar Perhaps obvious, but you could also stick some blocks of known bytes in between / around to see if they get over-written.
tulip sleet
maybe _setup_packet is the wrong size or is being overwritten. I know there were some buffer size issues in TinyUSB recently, but I don't know if they were related to this
@simple pulsar v good idea; easy to check
lucid solar
I'm going to take a break from this...will check back to it tomorrow.
ionic elk
@trim elm setup_packet doesn't sound familiar to me
tulip sleet
i think it's just some internal buffer that we wouldn't know about without reading the code, but it may be set up by an API call.
@lucid solar Thank you for spending time on this. These kinds of bugs can be very diffcult to track. I apologize if I sounded too directive.
lapis hemlock
@onyx hinge Jeff, I have committed the sosfilt function to https://github.com/v923z/micropython-ulab/tree/sosfilter. If you tell me where I find the circuitpython stubs, and how you want to integrate them, I will take care of the documentation.
Oh, snap! You'll need this, too: https://github.com/v923z/micropython-ulab/issues/126
onyx hinge
@lapis hemlock in the circuitpython source code there is shared-bindings/ulab. It has index.rst as well as a number of files called __init__.pyi
lapis hemlock
OK.
onyx hinge
our doc building process and stub building process do .. stuff .. with it that I am not familiar enough with to really explain
lapis hemlock
I can't get this done tonight, but I will try my best.
onyx hinge
er I guess index.rst is a generated file, my mistake
thanks for taking this on! There are not enough hours in the day/month/years
lapis hemlock
You tell me! Preaching to the choir...
lucid solar
@tulip sleet @ionic elk I've narrowed it down to these variables... .bss.never_reset_spi 0x000000002001a3e8 0x6 build-nucleo_f746zg/common-hal/busio/SPI.o *fill* 0x000000002001a3ee 0x2 .bss.reserved_spi 0x000000002001a3f0 0x6 build-nucleo_f746zg/common-hal/busio/SPI.o .bss.never_reset_uart 0x000000002001a3f6 0xa build-nucleo_f746zg/common-hal/busio/UART.o .bss.reserved_uart 0x000000002001a400 0xa build-nucleo_f746zg/common-hal/busio/UART.o .bss.claimed_pins 0x000000002001a40a 0xe build-nucleo_f746zg/common-hal/microcontroller/Pin.o .bss.never_reset_pins 0x000000002001a418 0xe build-nucleo_f746zg/common-hal/microcontroller/Pin.o *fill* 0x000000002001a426 0x2
lapis hemlock
@onyx hinge Is shared-bindings/ulab/... meant to be for documentation only? In other words, if we put these files on /v923z/micropython-ulab, where should we place them, so that we can get away with a single PR, if we change something in the docs?
onyx hinge
in the case of ulab only, shared-bindings contains only documentation
in I believe all other cases, there are .c files instead which contain the "pyi" "code" as comments prefixed with //| , and no .pyi files are committed
tulip sleet
@lucid solar so it's not the i2c never_reset and reserved?
bss._setup_packet
0x000000002001a3c8 0x18 build-nucleo_f746zg/lib/tinyusb/src/portable/st/synopsys/dcd_synopsys.o
.bss.never_reset_i2c
0x000000002001a3e0 0x4 build-nucleo_f746zg/common-hal/busio/I2C.o
.bss.reserved_i2c
0x000000002001a3e4 0x4 build-nucleo_f746zg/common-hal/busio/I2C.o
.bss.never_reset_spi
0x000000002001a3e8 0x6 build-nucleo_f746zg/common-hal/busio/SPI.o
that come before?
lapis hemlock
@onyx hinge If you want, we can incorporate the docs in the source code. I just would like to minimize the expenses on your side.
tulip sleet
but maybe the i2c arrays are getting overrun past their bounds?
suppose you made never_reset_spi really large, but NOT a multiple of 4
onyx hinge
@lapis hemlock It depends how much work you want to do, and how you weigh the value of having the docs and the source integrated in a single file. I think Tannewt values it highly; seeing it next to the code you're editing is a good hint that you need to keep the docs up to date
tulip sleet
e.g. set MAXSPI to 130 or something
lucid solar
@tulip sleet it's never_reset_pins for certain