#circuitpython-dev
1 messages · Page 305 of 1
yay for stuff doing things behind your back
Anyway, it's been a productive day! My NRF52833 is now sleeping at 340 uA. That's still about 50x more than it should be, but it's coming along nicely.
And USB plug/unplug is reliable now.
Thanks @crimson ferry. I only have a single board plugged in when I'm seeing this. Behavior seems to point to the PID/VID recognition issue.
Tried a fresh local build last night and ran across this error:
../../lib/protomatter/core.c:442:13: error: dereferencing 'void *' pointer [-Werror]
*core->addrPortToggle = newBits ^ priorBits;
^~~~~~~~~~~~~~~~~~~~~
../../lib/protomatter/core.c:442:35: error: invalid use of void expression
*core->addrPortToggle = newBits ^ priorBits;
^
cc1: all warnings being treated as errors
make: *** [build-evo_m51/lib/protomatter/core.o] Error 1```
@old smelt yeah, it looks like upstream is broken. All of my PRs have been failing with that error.
Ok.
I thought I saw a bug report about that, but I guess not.
Am I able to check out the latest stable release? Say, 5.3.0, and build that?
Guess I'm grabbing the very latest of everything right now
That should work, yeah:
git checkout 5.3.0
git submodule update
Thanks.
I'll do that for now. I searched the Issues on github for this error - didn't see anything. Maybe searching for the wrong string? I assume it is already a known issue if things are breaking.
I'm guessing it's https://github.com/adafruit/circuitpython/pull/2867
@old smelt hooray!
Also, final update for the night: I realized the LRCK and SCK lines were flopping around on I2S which was probably causing the I2S microphone on this board to do odd things. I set those to output, driven low, and now the board is down to about 11 uA. Hooray!
Update: With this patchset, usage is down to 10 uA when running on battery. It quickly and reliably wakes from sleep, and it appears to be capable of logging to internal flash.
@half geyser wow that is huge! (or tiny)
@old smelt sorry about the trouble with our master branch, I trusted too much in some automated checks and some bad commits got merged to master branch that shouldn't have 😦
@onyx hinge I'm pleasantly surprised!
@onyx hinge I was going to approve your build fix PR last night, but it was failing on multiple boards. But now it's succeeding. Did you fix something?
@tulip sleet yes I force-pushed a second change
I noticed that the "RTC" on the NRF is actually just a counter. Nothing is retained in case it crashes. I guess the answer there is to not crash...
(And maybe save the time occasionally in flash.)
@half geyser if the power is still on, then RAM should be the same? So you could just save it in RAM on each tick? Or is that not the use case you are talking about?
@tulip sleet That's a good idea, actually. And a candidate for a patch. Place rtc_offset in uninitialized memory.
if (block_num > 1) {
return 1; // error
}
``` am I overlooking something about this code, or is it nonsense?
I mean, that comment's not wrong...
@onyx hinge I'd look at the blame history
I think the second check is supposed to be num_blocks, like it is in write
I know I asked this before, but I'm almost at a point where I can actually work on it. But: What would be the best way to add an I2S Microphone?
I see I2SOut and PDMIn. The logical solution is to add an I2SIn object.
Yeah we'd like to see I2SIn added, it just hasn't happened yet. the nrf52 has the hardware for it I think
But I2SOut has a lot of generic I2S blocks, it's just specialised for I2SOut.
refactor as appropriate
not sure if you can get both to work at the same time. I wrote the i2sout but let's just say I'm not sure I'm proud of the code
I think you can, but it requires they both be at the same rate. Probably.
That's fine, because we'll need PWMOut, which I've tested works.
Does the build system allow me to have an I2S.c inside common-hal/audiobusio/? Would I need to add an I2SIn.c to every other platform?
Or, at least, each port which has audiobusio; looks to be just nrf and samd
(huh I thought samd did have i2sin...?)
(but no, I'm just wrong)
And does it support adding a common I2S.c file? Or does that have to go elsewhere?
@half geyser you'll need the appropriate files in shared-bindings/audiobusio as well. to gate it to certain ports, you'll likely have to use #ifs.
@tulip sleet re: bootloader & ubuntu 19+: the udev stuff turned out to be a bit of a red herring. but it did kind of point to timing issues. i'm currently testing a bump in the SINGLE_RESET delay to 75: https://github.com/adafruit/uf2-samdx1/blob/master/src/main.c#L113. will keep pushing, and see if i can get some empirical results...
@raven canopy but does this affect double-reset? BTW, that timeout was lengthened in https://github.com/microsoft/uf2-samdx1/commit/4c2e73e7a0324de02e7aee6bc31430a7028c0934, which we incorporated
@raven canopy that's what I thought, but since it's not an actual python class but is just a common library, I thought that was a bit odd. Are there any modules that have support modules that don't expose python types?
@half geyser, yes, like time, which only has functions. They're all in __init__.c
@tulip sleet double-reset seems to work for me, but we all have different timing. :D
i can move the bump down to the lower !main_b_cdc_enable wait loop (which we do differently it seems): https://github.com/adafruit/uf2-samdx1/blob/master/src/main.c#L317.
does that seem a more appropriate direction?
we are supposed to be sync'd up with the microsoft repo completely. I am just behind on merges in both directions
I've looked at that loop a few times, and thought it seemed really short
Thanks, @tulip sleet !
@raven canopy the main reason there are even two repos is that MS has some policyt rules that they are not allowed to release binaries, so we have to do that
well, maybe not the main reason (because we still want to submit PR's), but that's a consideration
do you have to go through and cherry pick?.....
ahh. ok. well, i've got interest in getting it working, so feel free to abuse that to get some grunt work assistance. 😄
I just need to do a merge from upstream and a PR back up; haven't had time yet
did you try building their current master to see if it's any better?
nope. but i can. watching nina's stream...attention stolen
@tulip sleet What is an example build without monotonic_ns() or how can I figure that out on my own?
any build without longints, so if you look in circuitpython/ports/atmel-samd/boards/*/mpconfigboard.mk for LONGINT_IMPL = NONE, those are the ones. E.g. Trinket M0
basically I have some code with bits in it designed to work on both in the event of using one that doesn't have monotonic_ns() and I want to make sure that the code works.
Ah. Oi. Ok. 🙂 Thanks.
This problem does not occur in current micropython even when MICROPY_OPT_COMPUTED_GOTO = 1.
I compared our py/vm.c with micropython's, because MICROPY_OPT_COMPUTED_GOTO is only significant in that file. There are differences in exception handling based on the flag.
Really interestingly, this micropython commit, which is a minor speedup, https://github.com/micropython/micropython/commit/869024dd6e62905b7e1069b547856a769b3b24ba, changes
#define DISPATCH() break
to
`...
Who can help me with a grep command?
My brain isn't wrapping around the man file for it.
what'ya got?
I want to grep for a string in a large directory structure, specifically, I want to search for a string in circuitpython
Very specifically, I'm trying to figure out where _pixelbuf is getting colorwheel or wheel. Because I think it's in the wrong order.
But I can't find it searching files on GitHub. So I need to grep I think.
shared-bindings/_pixelbuf/__init__.c: { MP_ROM_QSTR(MP_QSTR_wheel), MP_ROM_PTR(&pixelbuf_wheel_obj) },```
I use grep -r or, better, the ag (silversearch) command over the whole tree. @raven canopy, ooh, didn't know about git grep
that was @onyx hinge , as much as i would like to take credit. 😄
git grep only greps files that are tracked by git .. but irritatingly it doesn't go into submodules
Duly noted.
return (uint8_t)(pos * 3) << 16 | (uint8_t)(255 - (pos * 3)) << 8;
vs
return (255 - pos * 3, pos * 3, 0)```
I know it's in the wrong order.
I tested it.
It's based on our original wheel code
which was also broken
until I found it and fixed it.
fixing it now.
oic
In theory.
is the python code in https://learn.adafruit.com/circuitpython-essentials/circuitpython-neopixel the right one?
Let me check
It's basically correct, yes. Except we usually wrap them in int() but the math is accurate.
This is for sure correct:
def wheel(pos):
"""Input a value 0 to 255 to get a color value.
The colours are a transition r - g - b - back to r."""
if pos < 0 or pos > 255:
return 0, 0, 0
if pos < 85:
return int(255 - pos * 3), int(pos * 3), 0
if pos < 170:
pos -= 85
return 0, int(255 - pos * 3), int(pos * 3)
pos -= 170
return int(pos * 3), 0, int(255 - (pos * 3))```
I'm seeing my pygamer not enumerate with current master 😦
pixelbuf is GRB, not RGB.
I'd like to fix it. But this is going to take a little learning I think.
the C _pixelbuf you mean?
Yes.
oh! is there a reason for that?
I believe it was written based on the wheel code before I fixed it
so it's in the wrong order.
wheel(1) and wheel(255) should return red. They currently return green using _pixelbuf wheel.
wheel(85) should be green, it's currently red.
Blue is correct at 170
It means any rainbow code using _pixebuf wheel will have a rainbow starting with green, fading to red, fading to blue, back to green.
Which in theory still covers all the colors, but it's supposed to start with red.
I have the code in front of me, but it's C. so I'm going to have to put some effort into understanding it
@tulip sleet i'm seeing errors on building MS uf2-samdx1:
In file included from lib/samd51/include/samd51j19a.h:546,
from lib/samd51/include/sam.h:38,
from ./inc/uf2.h:7,
from src/main.c:77:
lib/cmsis/CMSIS/Include/core_cmFunc.h: In function 'main':
lib/cmsis/CMSIS/Include/core_cm4.h:85:28: error: listing the stack pointer register 'sp' in a clobber list is deprecated [-Werror=deprecated]
85 | #define __ASM __asm /*!< asm keyword for GNU Compiler */
| ^~~~~
lib/cmsis/CMSIS/Include/core_cmFunc.h:456:3: note: in expansion of macro '__ASM'
456 | __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
| ^~~~~
lib/cmsis/CMSIS/Include/core_cm4.h:85:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
85 | #define __ASM __asm /*!< asm keyword for GNU Compiler */
| ^~~~~
lib/cmsis/CMSIS/Include/core_cmFunc.h:456:3: note: in expansion of macro '__ASM'
456 | __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
| ^~~~~
looking at their CI run, i'm guess its GCC9 related...
their travis still uses GCC6
yeah, I fixed that in ours, you can just remove the : "sp"
@idle owl OK, how's your understanding of bit shifts in C (or Python for that matter)?
@onyx hinge terrible. I understood it for about 5 minutes after having it explained, did not use it enough, and it drained from my brain.
so the first thing to know is that colors are 0xRRGGBB, hex numbers with 6 digits
each digit is equal to 4 bits, each pair of digits is equal to 8 bits, so it's also 0xRR * 655356 + 0xGG * 256 + 0xBB
That got complicated quickly
haha sorry, let me slow down
If it was decimal it would be 10000 * RR + 100 * GG + BB, because that's how you "move digits over" in decimal
ah ok
to move over in hex, you multiply by powers of 16 instead, OR you use shifts like << which are in powers of 2
(2^16) is 65536, so 0xRR << 16 is 0xRR * 65536
ok
I know I'm not really explaining it in full, but I'm trying to help you recognize what the patterns in the code mean
^^^^^^^^^^^^^^^^^^^^^^^^^ shifting something by 16
so RR is (pos * 3)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
shifting something by 8, so GG is (255 - (pos * 3)
yup, now you got ahead of me
and unlike in Python, the 0 isn't bothered with, if something is 0, then it's simply ignored
right
I think I get what's going on
R << 16 | G << 8 | B
but whichever ones are zero are just left out, and there are parens and casts
the one that confuses me now is the first bit: if (pos > 255) { pos = pos - ((uint32_t)(pos / 256) * 256); } because it looks nothing like that in the Python colorwheel.
(uint8_t)(x) is a lot like int(x) except it also restricts x to the range 0 through 255 inclusive
ah ok
I think that makes it so that colorwheel(x + 256) == colorwheel(x), but still not for negative numbers
I'm not sure why it's written that way, however
it's saying pos = pos - int(pos/256) * 256 basically
think that's enough background to let you fix the bug?
Might be. I'll give it a try, and see what happens! Can always git stash && git stash drop and start over.
hm I never thought of doing those commands as a way of discarding my work. interesting.
I'm going to go have lunch, I'll check back later in case you had more questions
Alright, thank you so much for your help!
OK, I think my earlier problem was due to incorrectly updating the tinyusb submodule. phew.
🎉
Updated it, built it, fixed it!
@tulip sleet Do I need to do anything else but update the code to create a PR for CircuitPython? e.g. equivalent of running Pylint, Black and Sphinx on the libs. It's a simple fix, swapped two lines of code. No changes in number of characters or anything.
I'm not sure I've ever submitted a code fix to CP.
Docs yes, code, not so sure.
@idle owl usually there's not much to do. If you changed any message strings, you'd want to run make translate, but not true here. So just go ahead; you already tested it, and it seems like a simple fix
No message strings changed. Right on, thanks. Will do.
@tulip sleet "message strings" are not "comments", correct? so if I add a comment, still no issue?
anything in a translate() is what I mean
Ok
@slender iron is there any one-line command for Jlink that'll upload a bin to a specific file, without opening a GDB server? I'm poring over the manual and can't find one
JFlashExe will do that
no sorry, wrong way, I mean JMem
are you reading or writing flash?
there are commands in the JLinkExe CLI that will do it
J-Link Commander (JLink.exe / JLinkExe) is a free, command line based utility that can be used for verifying proper functionality of J-Link as well as for simple analysis of the target system with J-Link. It supports some simple commands, such as memory dump, halt, step, go et...
I'd like a command that's equivalent to what I have with my other STM32 programmer, texane/stlink: st-flash write firmware.bin 0x8000000. Run and done.
Yeah commander sounded like I had to write and link a configuration file to program it? Which sounds kind of ridiculous, I dunno.
I'm not looking to reinvent the wheel was just wondering if you had something you already use.
It's not that big a deal, most of the time I need GDB open anyway
looking...
@raven canopy that's what I thought, but since it's not an actual python class but is just a common library, I thought that was a bit odd. Are there any modules that have support modules that don't expose python types?
@half geyser We tend to put Python-agnostic supporting code in theperipheralsdirectory within a port.
@ionic elk it's not too hard to write a JLink script, but there isn't a pre-existing way to do it, as far as I can see. There's the JFlash tool, but that requires a separate license, and it's really meant for production
@tulip sleet yeah I have it, it looks like the STM32 official tools. But it's GUI based too.
well whatever nbd
@ionic elk JFlash has a command line interface: see this manual, chapter 5: https://www.segger.com/downloads/jlink/um08003
I don't think that works on mac... I don't see a symlink for it
There's one for flashing SDI chips though which is kind of neat, actually
@kevinjwalters Not that I know of. Please open one. It'll be very low priority but good to track non-the-less.
@hierophect I don't have cycles to look into this now. I think you fixed it in another PR already anyway. :-)
Hey guys. I'm doing some cycle testing on a part, and driving a stepper motor continously using a metro m0 express board. The board constantly sends a pulse train to the motor controller and each pulse cycle is set to 2mS. I am also using an adafruit i2c backpack connected to a display, and writing the cycle count each time one cycle is completed. I am noticing a delay (motor stops) between the end and beginning of each cycle, that seems to be due to writing the value of the cycle counter to the display. Does anyone have a recommendation for how to decrease the time it takes to do this, so that the motor can continue to cycle uninterrupted, while still updating the display? Is there a better way to send a value to the display, without having to encode the counter value as a string first?
Why is COUNTIO in here twice? This second time will never apply. (Sorry I didn't ask sooner.)
Looks great! Thank you!
I've tried to rerun the checks. It looks like some of the larger translations were failing for the simmel build.
@LintangWisesa This issue is for CircuitPython which runs on microcontrollers rather than single board computers. Please keep the discussion specific to CircuitPython.
Is the cause for this a race between the last background task run and the wfi call? WFI should work fine with interrupts enabled but for TinyUSB that means work may have been queued but not done.
@crimson ferry did that ESP-IDF transport bug patch get released?
It looks like it's from 2019?
break here to make it clear the loop is done.
Any idea why the LSE isn't starting? Thanks for looking into this!
Update: With this patchset, usage is down to 10 uA when running on battery. It quickly and reliably wakes from sleep, and it appears to be capable of logging to internal flash.
Why do you think this improves power usage so dramatically? Were we never actually sleeping?
@prime flower That's weird, the issue thread that references it https://github.com/espressif/esp-idf/issues/5004#issuecomment-625731391 reads like it was fixed after the issue was posted. Still apparently a known DNS blocking. So I guess we just continue to keep an eye on releases for one that's worthwhile for NINA.
FYi -- i tried this PR on a feather stm32f405 and it still does not boot.
@slender iron is it more natural for sdcardio.SDCard to take a DigitalInOut or a microcontroller.Pin? adafruit_sdcard takes a DigitalInOut but many core things (like, say, busio.SPI) take Pin objects. I coded for Pin.
Fixes issue where _pixelbuf colorwheel was in GRB order, not RGB. Also updates wheel to colorwheel for clarity while maintaining backwards compatibility.
Tested on Feather M4 with NeoPixel FeatherWing.
busio.SPI is assigning a peripheral to pins, so it would take pins. But busdevice SPI takes an SPI object and a DIgitalInOut,
does it make sense to pass a busio.SPI to sdcardio.SDCard? I would think so. Do you need to control a CS line too?
for that also a DigitalInOut would make sense
here's a before-and-after: ```- spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)
- sd_cs = digitalio.DigitalInOut(board.SD_CS)
- sdcard = adafruit_sdcard.SDCard(spi, sd_cs, baudrate=6000000)
- sdcard = sdcardio.SDCard(board.SPI(), board.SD_CS, baudrate=12000000)
the baudrate change is .. not relevant, ignore it
weirdly the docs for adafruit_sdcard, seem to be at variance with how it's actually used ... ``` spi = busio.SPI(SCK, MOSI, MISO)
sd = adafruit_sdcard.SDCard(spi, board.SD_CS)
the advantage of passing an object is that you can do duck-typing, and some things might not have pins, but just buses (e.g. blinka stuff)
yeah the adafruit_sdcard code will work with a bitbangio.SPI or a busio.SPI, but the new thing will only work with busio.SPI
similarly, it won't work with things that duck-type like DigitalInOut
(you don't want to, you'd lose speed)
i mean it as a general policy; may not make sense in this case. displayio.FourWire takes a busio.SPI, etc.
@crimson ferry yep - thanks for keeping me updated!
@tulip sleet digging at it a bit, I think that the reasons for FourWire to take microcontroller.Pin chip_select are what makes it natural here too
it also is a line of code the user doesn't need to write
so, for speed, that sounds fine, to avoid the common_hal routines?
and @slender iron mentioned the possibility of making sdcardio.SDCard survive reset like displays. In that case, you need to construct the digitalinout object "within" the containing non-gc'd object: common_hal_digitalio_digitalinout_construct(&self->chip_select, chip_select);
that is a good reason
@tulip sleet I didn't think I changed anything that would affect translations 😕 https://github.com/adafruit/circuitpython/pull/2870
Maybe the comment I added does?
korean hallowing build is 4 bytes too big. I'll work on squeezing it
don't merge it yet
Noted, I wouldn't have without it passing.
@onyx hinge Use pins if you only want to support the microcontrollers pins. Use digitalinout if you want to use other pins indirectly
@tulip sleet ok, here's where i'm at with MSFT uf2/master: went through about 10 physical resets (double-tap->single->repeat) without issue. but, i only get one successful reset via microcontroller.reset() into bootloader and back; the second .reset() locks up the host once it hits bootloader.
the DBL_TAP_MAGIC values match, so maybe its related to the BOD?
Issue #2812. Raise a NotImplementedError instead of an AttributeError for a missing function for time functions such as time.time() and time.mktime() on platforms that do not support long integers.
@slender iron what's the info for the weekly Monday CircuitPython meetings?
@rose root What info are you looking for?
Scott's answering it on his broadcast. I was wondering when the meetings were and how I would join. Scott linked me to the Weekly Meeting notes GitHub repo and I found the calendar link there. @idle owl thank you though.
got caught on a phone call: thanks for streaming @slender iron!
and...wrong channel lol
Is the CLUE still an alpha?
@hollow gazelle @lucid solar @sour lynx just pushed the code from today's stream
😋
Update: With this patchset, usage is down to 10 uA when running on battery. It quickly and reliably wakes from sleep, and it appears to be capable of logging to internal flash.
Why do you think this improves power usage so dramatically? Were we never actually sleeping?
That was poor wording on my part. Without these patches, I couldn't reliably test, since whenever it went on battery it would effectively crash. With this patchset in place, I was able to concentrate on ...
WFI does work fine if interrupts are enabled, but without disabling interrupts you can never be sure that there isn't pending data before issuing WFI For example:
sleep_until_time:
; ... do some prep involving the RTC
bl usb_background
wfi
usb_background:
; ... service USB buffers
bx lr
Even though usb_background() drains the buffer, you still could have an interrupt arrive between the bx lr and the wfi instruction...
@slender iron I just saw the shout out in the weekly minutes - thanks ❤️
I'm still working on it. I do indeed have boring rectangles as well as full polygon support planned. Currently I'm polishing and going over use cases to see what works and what needs more effort. I don't have a debugger so it's all printf for now 🧃
At the moment I'm just banging my head against feature parity with "transpose xy" functionality. After that I'll be working through mirror. I don't really want to do hidden or absolute transform support right yet. Around that point I think it'll be ready for alpha testing by others. I've got a few more features on my immediate plate for the project but they're fun & I'm trying to take care of the boring housekeeping stuff first. (I need transpose and mirror too, I figure a lot of people do) Feel free to PM me if you're curious for more details.
Just an observer here, but is this bootloader command what might be needed here?
pyb.usb_mode
It seems that it'd make sense to control this behavior in boot.py, which is accessible by double-clicking the reset button to mount the bootloader's partition. Presumably, if boot.py changes this mode, it could intercept the CircuitPy partition / MSC device from being presented?
I've thought about this a bit, we're not actually exposing this debug_uart object to python, so they won't be able to deinit it. As this would be enabled by board, and the vcp_rx/tx pins are already connected, then it's very unlikely someone would want to use those pins. Plus this would mostly be used for debugging...in which case the user would already be compiling CPY themselves. We should probably not expose the pins to CPY either?
@RichardFoo Yes, that's the part of the kind of capability we have in mind, but we'd also like for user-supplied descriptors both for the different USB devices, and for different HID devices in the HID desccriptor. The actual API would be different. It would be invoked from boot.py, which runs before the USB enumeration happens.
I put in a tiny change to a some code in a learn guide and Travis reports it failing. It's crapping out around some esp8266 bits in build_main_platforms. Is this a known issue? https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/1104#issuecomment-626191315
@onyx hinge cleaned-up the Travis issue I just mentioned, thanks.
happy it worked @simple pulsar
@simple pulsar I assume this code is tested by you on the non-magnetometer boards now?
A call to time.time() fails with various errors unless a prior call has been made to rtc.set_time_source().
In 5.3 release:
>>> import time
>>> time.time()
947386557
Using current master:
>>> import time
>>> time.time()
Traceback (most recent call last):
File "", line 1, in
AttributeError: '' object has no attribute 'datetime'
This was on a Metro Express M0. On a CircuitPlayground Express it simply crashes into safe mode.
If rtc.set_time_source() is call...
@low sentinel sounds good! Thank you!
@onyx hinge Yep, I've got the code running on a CLUE, on a CPB + Gizmo and on CPB only. I hadn't tested the code path on a button press on the CPB as most of my testing has been done on the CLUE - that's the reason for that fix. The code is funny on the CPB only, I think it's firing all the screen writes pointlessly down those unconnected pins!
could be
@simple pulsar I wonder, I see that the Gizmo has a pull down on A3. If you set A3 to GPIO input with pull-up enabled, you shold read .value as True if no gizmo is connected and as False if a Gizmo is connected. The voltages work out at least as long as the pull up is close to the nominal value. But if it's the minimum value of 20k, then the voltage is 0.33 * Vcc and technically you need to get down to 0.3 * Vcc, so this detection method might not work on a small portion of all devices.
Yeah, this came up in https://forums.adafruit.com/viewtopic.php?f=19&t=165042
The CPB only platform wasn't the main platform and it would change timing a bit so I haven't yet looked at that. Plus I needed to allocate some time to guide writing rather than just coding!
I've just used my standard ploy. I've added that to the Going Further page's Ideas for Areas to Explore 🙂
hehe
Complete oversight on my part. Fixed.
Makes perfect sense. Fixed four instances of this.
@dhalbert you're exactly right. #2847 address the real issue, so I re-scoped the if (!(flash_device->no_reset_cmd)) to only pertain to the reset command.
I am currently looking at using CircuitPython with WiFi as a mobile robot controller. I already have code that will update from a web server on my laptop on boot, so the ability to debug over WiFi as well would make it perfect.
vectorio builds on m4 express feather
Concrete shapes are composed into a VectorShape which is put into a displayio Group for display.
VectorShape provides transpose and x/y positioning for shape implementations.
Included Shapes:
-
Circle
- A radius; Circle is positioned at its axis in the VectorShape.
- You can freely modify the radius to grow and shrink the circle in-place.
-
Polygon
- An ordered list of points.
- Beteween each successive point an edge is inferred...
potato vision for the PR ☝️
I was truing an I2C device with the STM32F405 undere CP 5.3.0 and it crashes to the HardFault Handler
You are in safe mode: something unanticipated happened.
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Press any key to enter the REPL. Use CTRL-D to reload.
``` when I try to run the ht16k33_segments_simpletest
the code runs f...
Are there any issues with BLE code getting stuck in start_scan()? I developed https://learn.adafruit.com/circuit-playground-bluefruit-quick-draw-duo/quick-draw-duo on a few versions including 5.0.0-beta.2 and it was fine. I just ran it up on 5.3.0 and something is amiss. I have newer libraries too... [added later] turns out 5.2.0 is ok, I put in a ticket for this https://github.com/adafruit/circuitpython/issues/2875
Is this a dupe of #2691 ?
#2689 features more control-c / interrupt woes.
I was puzzling over some trivial BLE code not working on REPL on 5.3.0 on an nrF52840 based CPB, e.g.:
>>> import adafruit_ble
>>> from adafruit_ble.advertising.standard import Advertisement
>>> ble = adafruit_ble.BLERadio()
>>> scan = ble.start_scan(Advertisement, timeout=5)
>>> print(scan)
>>> for adv in scan:
... print(adv.complete_name)
...
...
...
Traceback (most recent call last):
File "", line 1, in
File "adafruit_ble/__init__.py", line 235, in start_sc...
There's nothing in the release notes for 5.3.0 that sounds like it could break this...
A decision would be needed on how to handle/precisely define the existing partially implemented property of BLERadio.tx_power in https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/b08096f5eadc3bcf27461340e97d66d791073c05/adafruit_ble/__init__.py#L305-L312
Yes, BLERadio.tx_power is too broad as it stands. Maybe it could be the default power. We could add .default_tx_power as an alias for now, deprecate tx_power in the doc, and then remove it in 6.0.0. Or, since it's not really implemented, probably nobody uses it, and we could just drop it or cause it to throw an error now on "get", since it already throws an error on "set".
Has a cloud CircuitPython Mu editor been considered, like MicroBit has? When my Makerspace hosts classes so much up-front time is consumed in setting things up, and the Mu editor is problematic on some devices; it would be nice to have an OS-agnostic solution.
Hi,
I'm a little desperate and I'm hoping someone can give me an answer.
I'm trying to display bitmap images on the LCD screen of the '2.4" TFT Featherwing'. I use the displayio module, the ILI9341 driver and the latest version of Circuitpython (5.3.0).
I can display text and draw shapes, but I can't display images with 'OnDiskBitmap()'.
Everything works fine with Pyportal or with a Feather M4 Express + TFT Featherwing, but as soon as I run the same code on the Feather nRF52840 + TFT Fe...
@rain parcel I think the new web file API is still in preview, but once that's available that + webserial would make that possible.
This API in particular https://web.dev/native-file-system/
another piece of information
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.3.0 on 2020-04-29; Feather STM32F405 Express with STM32F405RG
>>> import adafruit_msa301
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_msa301.py", line 53, in <module>
File "adafruit_register/i2c_struct.py", line 41, in <module>
RuntimeError: maximum recursion depth exceeded
>>>
Making steady progress on the USB host feathering. https://twitter.com/theavalkyrie/status/1259570565708316673
Is address_bytes on an Adresss supposed to be in reverse order here? It's a bit wierd!! ```>>> e.address.address_bytes
b'\xZZ\xZZ\xZZ\xc7R\x04'
e.address
<Address 04:52:c7:ZZ:ZZ:ZZ>
type(e.address)
<class 'Address'>
``` - theZZis a bit of data-masking.
the docs explain that it is so
@onyx hinge Which ones? I've found there's a brief mention at the end of here but it's not specifically about the Address class: https://circuitpython.readthedocs.io/projects/ble/en/latest/api.html?highlight=Address#adafruit_ble.BLERadio.address_bytes
@jepler ok finally got around to testing on the stm32f405 and works great :) please add the feather fritzing documentation in the next week or two to the guide
@onyx hinge Oh, I found it., https://circuitpython.readthedocs.io/en/5.0.x/shared-bindings/_bleio/Address.html
Huh, builds are failing on check formatting... This black thing wants the code to be unreadable 😦
When did black get added to the libraries? I hate it.
I can't even find any settings file for black to make it not make function/method args spread over a million lines.
Fix several documentation errors or inaccuracies in _pixelbuf
black doesn't have many settings (by design)
What's the code that's bothering you, @ruby atlas ?
@ruby atlas you can use # fmt: off and # fmt: on to prevent black from formatting something if it does something totally egregious.
@ivory yew i really really hate how it formats function args and method args. It makes it really hard to read. I also understand it messes with list formatting too.
i'm sure there are many other things I hate about how it formats code. It also makes it much harder to read what actually changed without increasing my git diff -U a fair bit (like -U10)
Hrm, there's a way to make it ignore unchanged files
not sure if we set that up or not
I saw I can turn it off with # fmt: off, but i'm pretty sure that me doing that for whole files wouldn't be received well.
yeah probably not. 🙂
I guess I missed the discussion when black was selected as a way to format the libraries. Been way too busy with work.
The whole point of black is to make pickiness about formatting irrelevant.
though you can't ever make everyone happy.
Black is awful though - it removes the ability to carefully format things for readability. The opinions in PEP8 and similar are pretty darn good, but still leave room for layout.
Anyway, I'm likely not going to contribute to the libraries much with black there. I hate it.
that's really unfortunate to hear, considering most projects adopt black to lower the barrier for new contributors so they don't have to worry about adhering to unwritten styling rules.
Ugh. I guess python took a really bad direction this year 😦
Is there anything we could do to make it easier for you?
Have black not want to split everything onto one line.
It might be worth chatting with Łukasz if you feel strongly about this. He's a super reasonable person and a friend of mine.
LGTM, but I don't (yet) have the powers to merge this. :)
Probably. The reason I hate the one-line -per-arg convention is I literally scroll past method and function signatures without seeing them. My brain registers them as ... not sure - I just don't see the code structure anymore with black.
Yeah. I mean, ultimately it comes down to taste.
I think as projects get bigger and bigger with more contributors, it's valuable to have a tool enforce style rather than have the codebase look like it was created by 100 people with 100 different ideas on stuff.
I've definitely seen projects where people just change formatting and then get into arguments about it. 😦
Right... Pylint and PEP8 have been pretty good at helping. But in my opinion, black takes it just a bit too far. From where I'm looking at this, black is changing a half century worth of code formatting conventions.... And in my case, over 35 years of how I'm used to function and method definitions looking when I scan and navigate code. My brain is used to a pattern we've been using for a very long time, and I don't see myself ever liking black. The code doesn't flow visually.
But my opinion is probably antiquated and irrelevant.
If I have time (hah), maybe I should write an unblack that I can run while I code to layout arguments and large lists in a sane manner, and then rerun black after.
haha
you can write black plugins, I think!
That might be viable. 🙂
Obviously our community will be better for your contributions, but if you don't feel happy when doing it that's understandable.
Probably not the right place for this, but has anyone done a survey on developer satisfaction with how black formats code?
probably a better question for Lukasz.
though I think in the Go community they consider gofmt to be a significant contributor to their developer satisfaction.
Also, just FYI, I have a terrible patch to Circuit Python that adds a .record() function to I2SOut. It seemed easier to do it that way. For now it's mostly testing, and is useful for me understanding all the little undocumented features of this chip, but might be worth adding something similar at some point: https://github.com/simmel-project/circuitpython/commit/07c27d0cf9a02cad6b7c7213e6521252860840b7
@ruby atlas The one-line-per-parameter thing is what bugged me most too but it does make diffs easier to read, especially when you include type hints and a default value for each parameter. I've gotten used to it and totally buy the argument of "lets standardize on one thing even if it isn't perfect. Consistency is the most important attribute of formatting.
I've been doing it that way for years
Ujson should only worry about whitespace before JSON. This becomes apparent when you are using MP stream protocol to read directly from input buffers.
When you attempt to read(1) on a UART (and possibly other protocols) you have to wait for either the byte or the timeout.
Fixes:
- Waiting for a timeout after you have completed reading a correct and complete JSON off the input.
- Raising an OSError after reading a correct and complete JSON off the input.
- Eating more data than seman...
I disagree: readability is the most important attribute of formatting.
I also don't buy the diffs argument. Maybe I would have before tools that do excellent diff highlighting. See my comment about having to increase the number of lines of context now to see what changed.
I'll engage Łukasz at some point, and hopefully find time for an unblack formatter (or black plugin) that I can use when working on black formatted code. Mostly I'm sad I missed the discussion about whether to adopt black as-is on the CircuitPython libraries and wasn't able to voice my concerns.
I realise just sending this for whichever library I was looking at was probably not the best choice — so if anyone has interest in "enforcing" license-tagging of files, I've sent an RFC pull request in https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/99 that uses the REUSE tool 🙂
One think that comes to mind that you could try is to set the speed of SPI explicitly after creating the SPI object:
spi = board.SPI()
spi.configure(baudrate=20_000_000, phase=0, polarity=0)
good morning discord
@ruby atlas I think you may know this, but the one-line-per-element thing can be controlled. The line length is a command-line parameter. So perhaps your "unblack" for your own purposes can just be black -l <something more than 88>.
also have you read https://black.readthedocs.io/en/stable/index.html (I would assume so also)
In time, we should transition all background tasks to work this way, but by preserving the existing "supervisor_run_background_tasks_if_tick" code we can do this piecemeal.
Before this, the mp3 file would be read into the in-memory buffer only when new samples were actually needed. This meant that the time to read mp3 content always counted against the ~22ms audio buffer length.
Now, when there's at least 1 full disk block of free space in the input buffer, we can request that the buff...
I found something that appears to be a weird 5.3.0-ism yesterday: https://github.com/adafruit/circuitpython/issues/2875
@simple pulsar I am debugging some BLE code on master (past 5.3.0) and am not seeing this problem, but I will try to reproduce
I think start_advertising was fine, it was start_scan that was problematic, i.e. some stuff certainly works
This code works for me on a Feather nRF52840 with 5.3.0, and the latest adafruit_ble straight from the repo:
import adafruit_ble
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement, Advertisement
ble = adafruit_ble.BLERadio() # pylint: disable=no-member
while True:
for adv in ble.start_scan(Advertisement, timeout=5):
print(adv, adv.complete_name)
I see various advertisements printed.
Note that in the example above, with timeout=5...
You say you've updated libraries, but could you somehow be running into this?
https://github.com/adafruit/Adafruit_CircuitPython_BLE/issues/75
I've gone back to 5.3.0 on a CPB and it works today, very puzzling. I would normally expect "user error" here but there's not much to go wrong.
I would have upgraded the files in lib after i did the upgrade to 5.3.0 yesterday. I would then have tapped control-d / control-c to reset things. Is there anyway the previous libraries could have had a persisting, negatve effect there?
If you did a control-d, it should be fine. A power cycle will definitely reset everything, but I very rarely do that. ctrl-d is fine.
But make sure there aren't two versions of the library, one in lib/ and one in /.
If you did ctrl-d, and then had to ctrl-c a code.py, then it's possible there was some leftover BLE state. In general I test with a code.py, or remove code.py and do manual imports of test programs (so I can have multiple test programs). And as I mentioned, testing...
That's an interesting point, I did copy some libraries around last night and "missed" lib and got / but I spotted that immediately and moved them.
I did a renamed of lib to lib.from.5.0.0 before that and then made a new lib directory from the Windows host. Does that hold any possibilities for confusing things?
I think I was using 5.0.0-beta.3 pre upgrade.
I believe this problem may have been introduced by the lower-power branch.
I don't have a simple how-to-reproduce, because the simple program I created to look for the problem seems to work just fine. It may have to do with high CPU utilization from MP3 decoding, interrupts from sound DMA, etc., it's hard to be sure.
How to reproduce:
- set up jeplayer and some mp3sa on a pygamer
- with 5.3.0 loaded, start playing tracks, check that play/pause with the "any" button works
- with m...
@tannewt I'm still hanging at boot for the Feather. Just did some additional testing and it seems to also brick the Pyboard, but interestingly, NOT the F411 boards (pyb nano, blackpill). I'll work on tracking this down today if you're busy.
I've repeated the upgrade from 5.0.0-beta.3 to 5.3.0 and it's ok on one CPB.
I'll close this for now and add re-open if I can reproduce it.
To be really sure, you can also do storage.erase_filesystem() before copying libraries back over. That way you'll know you are starting from a clean slate. Just remember that will also wipe out any programs, so back everything up before testing.
In rtc_init(); added a call to rtc_reset() to initialize rtc_time_source. This allows calls to time.time() to succeed without needing to call rtc.set_time_source()
@ladyada do you think I could get the mfn part numbers for the LSE and caps used on the Feather?
I tried the sample code above on an nRF52840 Feather running CircuitPython 5.3.0-184-g90bd93180 on 2020-05-09. The native runs slightly slower:
Python elapsed: 4.591
Native elapsed: 4.59601
Python elapsed: 4.59094
Native elapsed: 4.59497
Python elapsed: 4.59009
Native elapsed: 4.59399
The CircuitPython Weekly is in a little over an hour. Everyone is encouraged to attend! Please add your status updates and hug reports to the notes doc even if you'll be attending - it's super helpful! Looking forward to chatting soon. Thanks! <@&356864093652516868> https://docs.google.com/document/d/1bzaYoTmWls07acn7JB4z0CX9BiTymQH-22rwZzXIObE/edit#
where has my morning gone? 😭
@idle owl I'm skipping it today...I feel sick. Have a good meeting!
@lucid solar Feel better soon!
@narrow dirge it ran away with mine
@lucid solar take care of yourself and take care of others by distance
hi @ivory yew 👋
hope you feel better soon @lucid solar 🍜
Thanks @idle owl @onyx hinge @raven canopy. It's not the virus type of sick thankfully 🙂
@solar whale you around? wanted to ask you if you've seen any issues on Ubuntu 20.04 with switching over to the bootloader drive...
If you were copying via Windows Explorer or a CMD command or similar, it can take Windows up to 90 seconds to actually finish writing the files and their metadata. I think you know this already, but make sure you "Eject" after doing a write like that.
@raven canopy not sure what "bootloader drive" you are referring to
FEATHERBOOT and the like
not that I have noticed.
k. thanks. just trying to vector an issue i'm having... 😣
I have managed to get my AHRS library I demoed on show and tell last week into a (somewhat) proper library. I know a couple people here had gave me a start to it and were asking to see it... so here it is!
https://github.com/gamblor21/CircuitPython_AHRS
just verified taht FEATHERBOOT comes up OK with a feather m4 express
I have only been able to test it was a LSM9DS1 as that is what I have, but seems to work for the most part
@raven canopy what board?
so, far a Metro M4, with bootloader 3.6 and higher. i still need to walk back bootloader versions further. (this is all on an RPi with Ubuntu 19.10+)
OK -- my bootloaders may be older -- I'll try updating a metroM4
@solar whale note: i'm seeing total system lockups with this, so make sure you're in a situation where you can suffer through a hard-reset. 😄
lockup of the ubuntu Pi?
yep
hmm -- I do have an ubuntu pi -- I have to verify the version etc -- been gathering dust. I can experiment with it - no worries.
ooh -- my metro m4 is at bootloader 2.0.0 -- time to update....
Interesting, I haven't had that issue when testing with SPI devices. This issue is currently super-ceded by the #2861 issue on master, but I'll have it next up on my list.
Good afternoon all you wonderful folks -- lurking today [as happily as one can be when putting out fires].
Hello to All, I'm also lurking
@raven canopy as of now my ubuntu pi does not see the metro m4 at all -- CIRCUITPY or METROM4BOOT ... investigating
Hello everyone! I'm text only today.
Hi text only....
Lurking - noted in doc
Lurking sometimes
lurking
or maybe Kattni is low...
lurking
lurkinkg this week
Lurking
....when I said I was putting out fires, that's not what I had in mind 😉
Lurking
If you all have cool stuff for the CircuitPython newsletter out tomorrow, please email them to me at anneb@adafruit.com now. I'm closing the edit phase soon
lurking today
They're testing it now. They claimed they'd only do it once.
And to subscribe to the Python on Hardware newsletter, visit www.adafruitdaily.com
Apologies for the delay.
10--4
wee woo wee woo
I don't have a fire alarm to deal with, but there is an obnoxiously loud bird right outside my window. He is singing the song of his people.
@blissful pollen are you lurking or will you be speaking in the meeting today?
lurking
got it, thanks
@ivory yew maybe its waiting for a Big Honking Button response?
@raven canopy hehe. I think that would only attract more birds.
https://www.youtube.com/watch?v=1TniUBJejfY&feature=youtu.be https://www.youtube.com/watch?v=LfUBOF1AWzs
Visit the Adafruit shop online - http://www.adafruit.com
LIVE CHAT IS HERE! http://adafru.it/discord
Adafruit on Instagram: https://www.instagram.com/adafruit
Subscribe to Adafruit on YouTube: http://adafru.it/subscribe
New tutoria...
Join Scott today (Friday May 8th) as he streams at 2pm Pacific. The plan is to recap ESP32-S2 work Scott did this week (lots of exciting progress!) and then start implementing digitalio and (if he’s lucky) busio for the ESP32-S2.
(Scott typically streams at 2PM Pacific time)
Testing out RGB Matrix support in CircuitPython for STM32F405 @ST_World #STMicroelectronics added native RGB matrix support to CircuitPython for the SAMD51 and nRF52 processor series - now we have added STM support! makes it super easy to use these inexpensive colorful displa...
@raven canopy when you get a chance, can you give me teh contents of your /etc/apt for Ubuntu 19.10 on RPi -- mine is very unhappy.... lots of broken links.
can do
no rush
oh no I just realized I fell out of the list of PR reviewers this week. Bad jeff, no biscuit.
quality > quantity! 😄
FYI ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.3.0 on 2020-04-29; Feather STM32F405 Express with STM32F405RG
import adafruit_rfm9x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_rfm9x.py", line 49, in <module>
File "adafruit_bus_device/spi_device.py", line 33, in <module>
RuntimeError: maximum recursion depth exceeded
Hello well I not sure what im doing or did wrong... plugged Feather M0 in double clicked reset got FEATHERBOOT dragged CircuitPython 5.3 on it drive went away and i never see the the drive again what did i do wrong/
Actually, I realize that the maximum recursion depth implies this is likely related to #2830. You could try manually expanding the stack size in the stm32f405_default file to 24k. I've encountered some of my own hardfaults when testing this, though, so let me know if you try it and it works.
~eventually~, @slender iron.
🤞
primary goal right now is to just make it easy to use from circuitpython.
same api would be good 🙂
(does the hostess featherwing have a logo? Is it a cupcake?)
Hello well I not sure what im doing or did wrong... plugged Feather M0 in double clicked reset got FEATHERBOOT dragged CircuitPython 5.3 on it drive went away and i never see the the drive again what did i do wrong/
@old vapor If you double tap the reset button, do you get the FEATHERBOOT?
@tiny oriole Yes I did
@onyx hinge I didn't give a separate logo, but this is what i looks like:
@tiny oriole Err do
I am
Though I really want to do a pink soldermask for the production one. 🙂
@ivory yew where do u get your 3d parts?
try flashing it again? haha. Secondary, i would say doublecheck to make sure you have the latest drivers (Link incoming, one second)
@old vapor exactly which board is it and which .uf2 did you load? Also what is the host operating system?
and what is that rendered in?
I don't know who I am
looks great
@ionic elk 3dcontentcentral, mostly.
KiCAD, though the product images you see on <winterbloom.com> are rendered in fusion 360.
@ivory yew looks good .. should still find room for a cupcake
@old vapor also, i'd recommend making sure you have the correct firmware file. the names can kind of melt together sometimes.
I should swap to kicad if I can get exports that pretty
@onyx hinge hehe I'll make a note.
Hi text only....
@solar whale This is why I thought you were text only
my eagle images are always hideous
Also yes. double check you have the correct firmware: https://downloads.circuitpython.org/bin/feather_m0_express/en_US/adafruit-circuitpython-feather_m0_express-en_US-5.3.0.uf2
Ahh -- that was in response to Cgrovers post ...trying to be funny...
@tulip sleet @tiny oriole Downloaded latest Drivers using Win 10 feather M0 all correct files
Windows 10 does not need drivers, but the installer should not install them anyway
it checks it is windows 10
however Kasperksy and Norton antivirus can prevent CIRCUITPY from appearing
Using Neither of those
are you using another third-party antivirus?
Just Windows
that should be fine.
@solar whale have you experienced any power issues with the camera? Maybe indicated by grainy B&W images.
I haven't been following, did you check what the onboard status led is saying?
See above and below this: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#circuitpy-drive-issues
not that I have seen -- using with RPI zero w and a USB "power bank" 2.1 Amp
Ah yes, the telephone game of carrying a bug between implementations
can you connect to the REPL with Mu or Tera Term?
@old vapor what was the exact full name of the UF2 file you dragged over?
adafruit-circuitpython-feather_m0_express-en_US-5.3.0
welcome to C-land!
"copying files and adding a string" basically sums up my 18 years of programming experience.
@old vapor ok. seems fine. then what @tulip sleet asked about connecting to REPL.
@onyx hinge
That feeder is for the birds 🐦
I get an error cannot find CP device sorry typing bad just had carpal tunnel surgery
@wise spoke Are you lurking?
y e s
Join Scott today (Friday May 8th) as he streams at 2pm Pacific. The plan is to recap ESP32-S2 work Scott did this week (lots of exciting progress!) and then start implementing digitalio and (if he’s lucky) busio for the ESP32-S2.
Join Scott today (Friday May 8th) as he streams at 2pm Pacific. The plan is to recap ESP32-S2 work Scott did this week (lots of exciting progress!) and then start implementing digitalio and (if he’s lucky) busio for the ESP32-S2.
hah he beat me
Early bird gets the worm 😉
fights urge to paste... 😉
more press for scott's great livestreams
His streams are very nice deep dives, showing that programming isn't magical, instantaneous coding -- but step by step problem solving, needing patience, persistence, and even more patience 😉
that's a chonky led in the preview
I think I had it from a college breadboarding kit 🙂
not even sure of the resistor value
swoon I'll be sharing that with my woodoworking friends
@tulip sleet so when i connect it back to computer i don't see drive start MU i get Could not find an attached Adafruit CircuitPython device. tried it again when i can see bootloader drive same issue
context:
https://forums.adafruit.com/viewtopic.php?f=60&t=165259
http://adafru.it/mpy-update forwards to
https://circuitpython.readthedocs.io/en/2.x/docs/troubleshooting.html#valueerror-incompatible-mpy-file
It looks like the short URL needs to be updated to point to 5.X. I can do it but I don't know how/where
@old vapor I just want to doublecheck that the bottom of the board says "Feather M0 Express". Did you try copying the .uf2 file again? Does anything unusual happen when you do the copy? Do you see a progress bar that stalls for a while?
as Jeff E. asked, what are you seeing on the RGB led (neopixel)?
thats what is wrong thought is was express but is a basic 😦
@tulip sleet Thanks and it is back reading is for the mental so i koalafi
@tulip sleet is there a github link for the new BLE Services stuff? I am curious to try it out to see if the Android version of the app suffers from any sort of similar issues.
LSE = low speed oscillator?
aha
got another call. See ya all! happy coding!
Adafruit CircuitPython 5.2.0-167-gdcb0e50f0-dirty on 2020-04-22; Feather STM32F405 Express with STM32F405RG
@lone axle you'll need the latest adafruit_ble library
Adafruit CircuitPython 5.3.0-184-g90bd93180 on 2020-05-11; Feather STM32F405 Express with STM32F405RG
🎉
👍
@solar whale so, booted my 20.04 first absent-mindedly. booting 19.10 now... 😄
you want full folder? or just sources.list?
@idle owl I'll let you wrap up
@raven canopy a zip of the folder would be best, I think
big weedy energy
@ionic elk did jeff or limor ask you to do more rgb matrix stuff?
jeff did
kk
when I plug in the board, dmesg looks normal, but it does not mount. i may be missing something.
Thanks!
@solar whale I've been using a cell phone or other auto adjust camera for so long, I forgot how wonderful adjusting fstop can be.
was hoping to see more work on imx too
And no fire alarms either!
@slender iron Limor told me that @ionic elk would be doing other STM parts. I brought the news to him but assumed Limor would have more deets
They are currently simultanious
kk, np
i.MX is more weedy and sometimes frustrating so I figured RGB would be a good relaxing thing by comparison
I like physical stuff
👋
@raven canopy oops -- just realized -- I am using 19.04, not 19.10...:-(
oh. hehe
i don't think i have 19.04 readily bootable. i moved my primary (SSD) to 19.10, have one SD on 20.04, and my other SD on raspbian.
@siddacious I will ping you privately. As far as I know Internal Dev or PT needs to update it.
sorry for the false alarm -- I have not used it in several months and really have no need for it since I now have latest arm tools on raspbian.
fair enough. i avoided raspbian; building from source is too long a wait... 😄
but I can say I have not problem mounting metrOM4BOOT on my Ubuntu 20.04 -mac mini
withr 3.9.0 bootloader
that's good enough info really. like i mentioned in status, i'm still working my way through finding where the actual issue is.
although, could you check one thing for me on the mac-mini? is it using xhci, ehci, or something else for the usb driver?
If you ever want a "tarball" of the arm tools for raspbian let me know.
where to I check for the usb driver?
dmesg should show, during enumeration
[Mon May 11 15:15:24 2020] usb 3-1.4: New USB device found, idVendor=239a, idProduct=0021, bcdDevice=42.01
[Mon May 11 15:15:24 2020] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Mon May 11 15:15:24 2020] usb 3-1.4: Product: Metro M4 Express
[Mon May 11 15:15:24 2020] usb 3-1.4: Manufacturer: Adafruit Industries
[Mon May 11 15:15:24 2020] usb 3-1.4: SerialNumber: 4632E64B53574E514D202020FF081736
[Mon May 11 15:15:24 2020] cdc_acm 3-1.4:1.0: ttyACM1: USB ACM device
[Mon May 11 15:15:24 2020] usb-storage 3-1.4:1.2: USB Mass Storage device detected
[Mon May 11 15:15:24 2020] scsi host8: usb-storage 3-1.4:1.2
[Mon May 11 15:15:24 2020] hid-generic 0003:239A:0021.0022: hiddev1,hidraw3: USB HID v1.00 Device [Adafruit Industries Metro M4 Express] on usb-0000:00:14.0-1.4/input3
[Mon May 11 15:15:25 2020] scsi 8:0:0:0: Direct-Access Metro M4 Express 1.00 PQ: 0 ANSI: 2
[Mon May 11 15:15:25 2020] sd 8:0:0:0: Attached scsi generic sg3 type 0
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] 16000 512-byte logical blocks: (8.19 MB/7.81 MiB)
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] Write Protect is off
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] Mode Sense: 0f 00 00 00
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] No Caching mode page found
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[Mon May 11 15:15:25 2020] sdd:
[Mon May 11 15:15:25 2020] sd 8:0:0:0: [sdd] Attached SCSI removable disk
xhci_hcd
xhci it is. thanks!
👍
unless you want me to keep it for some reason, I thin I will "recycle" the ubuntu pi back to raspbian....
no reason that i see.
I forgot I even had it -- but now that it's in front of me , I can think of better uses for it.
haha. that's usually how it goes.
I have way too many toys...
that's not a real thing. at least, not in my opinion. 😄
On BLE front, this is what I was up to at the weekend: https://forums.adafruit.com/viewtopic.php?f=53&t=164851#p811436
Here is the notes document for Monday’s CircuitPython Weekly meeting. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/15gBlvCmwW-f26oYTY5LI897XAfc5GpYlNC7httMFFqU/edit
thank you very much for your proposal.
Unfortunately, when I test it, it doesn't work.
I've locked the SPI bus before add the configure method, but it doesn't work.
The code freezes and the REPL in Mu editor stays blank. I can't make any CTRL+C or CTRL+D.
I need to unplug and plug the board to get the hand back.
Do you have another idea ?
Here is a test build (zipped up):
circuitpython-teensy41-61450cb.hex.zip
language-circuitpython v0.7.0 has been released to APM which brings support for input into the serial monitor (thanks to @timid nimbus!). if anyone wants to give it a shot and let me know of any feedback or issues I'd be grateful. stay safe all!
I know there are some existing issues with the bindings file not been located and I've been working for ages on trying to get that to work but I can't figure out why some people can reproduce it and some cannot
Verified that it comes up on the board here: https://forum.pjrc.com/threads/60532-Teensy-4-1-Beta-Test?p=238840&viewfull=1#post238840
oh yeah! whoops! should have clarified, it's the atom plugin I wrote a while back
the serial port library for node is a nightmare for shipping because it uses compiled bindings
@trim elm is working on moving our native module docs to Python stubs so editors have a better time: https://github.com/dherrada/circuitpython/commits/master
ya, I bet!
oh interesting
do you have a blog about it somewhere? we could add it to our weekly newsletter
I don't (though I really should start a blog), I wrote it about exactly a year ago and spoke with people here about it. other than that it probably spreads by word of mouth and the search. I'd love for people to be able to use it although the odd serialport errors do worry me a bit, it's not ideal for end users to have to rebuild the bindings
https://github.com/jos-b/language-circuitpython is what I have
kk cool! release notes can be a good place to put info about a new release too
Just to add - I can recreate this issue. Release 5.3.0 works fine. With version shown below from S3 bucket, behaves as described above, i.e. buttons essentially stop working.
Adafruit CircuitPython 5.3.0-184-g90bd93180 on 2020-05-09; Adafruit PyGamer with samd51j19
>>>
I can't verify it on HW but this all looks plausible :)
@ionic elk how is the LSE stuff coming?
It's done I'm just double checking the stack stuff rn
Ok, fixes are in @tannewt. @jerryneedell, the stack sizes have been adjusted - if you could run your stack code on this that would be very helpful.
Important note! Once programmed you may need to reset the power before these fixes will take effect. It appears settings in the Backup Domain like to persist past writes and such, and I've observed that sometimes the chip will not boot when switching between the LSI and LSE, as we saw briefly on the call today. A simple reset does not do the t...
Also, since the H7 and F7 have different settings for the Backup Domain, and I don't think we've effectively tested them, I've disabled LSE on them entirely until I have a chance to revisit this and hopefully move all this RCC setup code into Peripherals management where it probably belongs along with the rest of the oscillator stuff.
thanks @ionic elk, looking now
Looks great! Thank you! Will merge after CI passes.
My guess is that this requires "supervisor_tick" to be called at a regular interval. I added internal enable/disable tick calls for this but didn't connect them up to gamepad or gamepadshift. So, these two classes should "enable_tick" until they are reset or deinit and then "disable_tick".
FourWire now takes baudrate in it's constructor so try it instead of changing the SPI setting.
Thanks for the fix @DavePutz !
Thanks for this! My brain will start thinking through this approach. It's not what I was thinking which means it is probably better. :-)
"You Ain't Gonna Need It". I'm not sure this should be here at all.
This routine might be needed if you queue some work but then decide it shouldn't be done, but I'm not sure why that would be. At object deinit(), perhaps?
This is awesome! Thank you!
Would you mind following up with a PR to restructure the json module into shared-bindings and shared-module? That way we can document it like all other native modules.
Now you do @theacodes. Thanks for the review!
Fixed by #2881. Thanks @DavePutz
@tulip sleet thanks for the tips re black, will check it out.
Looks like de_DE, pl, fr, it_IT, es, ko, fil, and zh_Latn_pinyin: https://github.com/adafruit/circuitpython/pull/2869/checks?check_run_id=657239982
Ok, this looks good! All it needs is another merge.
That was poor wording on my part. Without these patches, I couldn't reliably test, since whenever it went on battery it would effectively crash. With this patchset in place, I was able to concentrate on other parts of the chip in order to bring current consumption down there.
kk, awesome! I'm excited to see the subsequent PRs. Are you blocked on TinyUSB changes now?
Thanks for this! You'll need to merge again for translations and then please make sure your protomatter submodule doesn't change. This PR shouldn't change it.
@hierophect still need the part info? I can look it up too.
Thank you for the updates to this! It's getting close. Just a few more comments about the UART functionality that needs to work outside of the debug use too.
We shouldn't always do this. The uart should have a setting for it.
Someone may want full control of a UART and not want it do detect ctrl-c.
I'm ok not exposing the VCP pins. You should set never_reset to false though because future uses of UART never reset will expect it to work like others. Other implementations allow you to undo "never_reset" with an explicit deinit.
Please add a note here that it is only implemented for STM. The other ports will crash because they won't be able to allocate the uart buffer.
A few questions. Lots for my brain to process. Thanks for this! It'll be a huge benefit for folks. Line might be nice to have too.
Could you try setting this to FULL_BUILD? Ideally it'd be in as many boards as it fits. :-)
//| The radius of the circle in pixels
Document it like it's a variable.
This feels a lot like TileGrid. Would it be too weird to have the shapes just act like two color bitmaps for use with TileGrid?
How are dict variables laid out in memory? I have one that's gradually growing over time and adding a value to it is eventually giving a MemoryError. I'm wondering if parts of it need contiguous memory?
it's a hash table that probably doubles in size every time it grows
I've had two of them die i different places on additions but the allocation is only 1016. I think I'll puzzle over this tomorrow.
@slender iron thanks
Sure I can try. I was going conservative as I only have the m4 express feather to test myself but it'd be nice to have on more!
Looks good! I also tested this on a Metro M4 with regular QSPI configuration, and also EXTERNAL_FLASH_QSPI_SINGLE and _DUAL, and it worked fine.
@tannewt Any further comments?
TileGrid is well-suited to maximizing bitmap grids. I tried to use it for vectorio but was unable to do so without branching an unreasonable amount.
It does feel similar, yes; but:
- Positioning is a bit different with vector shapes.
x+widthhas nothing to do with the location of the pixels to be drawn in these shapes. - There is no width and height external to the shapes themselves. These are not sprite sheets!
- I'm hoping to make an
mp_shape_protocolin the future and just ...
Yeah, O(1) memory cost increases I'm pretty receptive to. I'll measure and see if it matters.
do comments in .py files count against the ram used by circuitpython on the m0? I'm wondering if I just wrote too much code, or too verbose
A few questions. Lots for my brain to process. Thanks for this! It'll be a huge benefit for folks. Line might be nice to have too.
This CR is too large, sorry! I've never made a vector display library and didn't know what would work, so I just kind of went for it.
Agreed, Line would be very good. I don't think I want to creep features on this cr any more than it already has though 😓
@topaz quest No, comments are removed and are not kept in RAM. If you are getting a memory error on import, you can try compiling the file to .mpy with mpy-cross and using that instead. Remove or rename the .py file, because it will take precedence over the .mpy file.
@tulip sleet ah good — I'll give that a try tomorrow (getting "early in the morning" here) — for the moment I solved it by "hatchetting" the code until it kind of worked, but it's in no way close to a possible pull request 🙂
what that will do is not use up RAM (temporarily) when compiling, because it will have been done in advance. It won't change the size of the ultimate compiled code. Good luck!
Automated website update for release 5.4.0-beta.0 by Blinka.
New boards:
- simmel
- pitaya_go
- pca10100
- openmv_h7
- nucleo_f746zg
- stm32f746g_discovery
- teensy41
New languages:
- sv
resolved with 5.4.0 release -- boots normally and tested both I2C and SPI devices
sorry I'm late, but it works great on my feather_stm32405 -- also resolves the I2C and SPI issues.
The CIRCUITPY_INTERNAL_FLASH_FILESYSTEM_SIZE variable adjusts how much of the flash is dedicated to an internal filesystem, and changing the size causes the filesystem to move. Since it's located in a platform header file, it also causes a rebuild of most of the port.
However it does not cause a rebuild of the linker script, meaning in practice the filesystem is physically positioned at the old location. Additionally, pointers inside circuit python will not match the intended layout.
...
Looks great! Thank you!
Thanks, I didn't notice that among the other build failures. I've reduced the flash filesystem by one block.
Incidentally, I opened up https://github.com/adafruit/circuitpython/issues/2884 which I've run into several times while figuring the optimal internal filesystem size. We'll probably enable SPI flash at some point soon, but for now I'll be doing the flash filesystem dance.
This does depend on the tinyusb patch, because tud_task() can hang the system if interrupts are disabled. In fact, the hang only occurs if it would have encountered the disconnect/connect issue that this patch aims to fix.
My concern is that other background tasks require interrupts to be enabled, and I am unable to exercise those. However, I do think that others will begin to report issues with missed events with the lower power WFI patch, and some approach like this will be required ...
Thanks for 5.4.0 beta !tannewt!
np! all out now
Just a follow up on the Terminal in CircuitPython. I’ve got a simple terminal working that is a wrapper around the tileGrid. It handles a few of the basic functions including showing cursor location, text entry, scrolling. It’s adequate for a minimalist text editor built from this editor https://github.com/robert-hh/Micropython-Editor
This library is currently in flux and doesn’t yet meet CP group’s guidelines but perhaps it can point in the right direction.
[https://github.com/k...
Ok, this looks good! All it needs is another merge.
Thanks again for your help @tannewt - I've merged in master, looks like it breaks on the stm32f405 - with a protomatter issue. Did I merge in the wrong submodule?
Also the catwan_usbhub fails on the locale DE .. (it builds on my machine using English) - any suggestions on what I can do here?
Try moving into lib/protomatter and checking out 9f71088d2c32206c6f0495704ae0c040426d5764 which is the commit currently in master. That should hopefully fix it.
For the catwan you can just disable COUNTIO for it. It must be tight on space. You can add TRANSLATION=de_DE to the make command if you want to try building it locally.
Thanks!
@tulip sleet yeah mpy-cross worked, thanks!
I think I've had a run-in with GC here: https://forums.adafruit.com/viewtopic.php?f=60&t=165359 would this work ok if there was some compaction going on? Is that ever going to happen in CP (or CP on non-M0 boards)?
@simple pulsar thanks, maybe this is fragmentation. I think your last example, in the second post, could be telling and I'll open an issue for that (or you can if you want).
@tannewt I would find it interesting to know for future reference, but clearly it wasn't the cause of the problem, so I don't need it for anything specific. If nothing else had worked I would have run it through STM32's appnote of oscillator compatibility formulas for possible problems.
from @kevinjwalters:
https://forums.adafruit.com/viewtopic.php?f=60&t=165359 (this example from second post in that thread)
Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit CLUE nRF52840 Express with nRF52840
>>> from adafruit_clue import clue
>>> import time, gc, random
>>> gc.collect() ; gc.mem_free()
89872
>>> a=[(1.0, 2.0, 3.0) for x in range(500)
... ]
>>>
>>> def read(n):
... for idx in range(n):
... a[idx] = clue.magnetic
...
...
...
>>> gc...
@kevinjwalters were you using the .py or the .mpy version of the CLUE library?
.mpy and a slightly old one - it's from adafruit-circuitpython-bundle-5.x-mpy-20200327
@tulip sleet Thanks for having a look. I have a bit of a dusty clue library but i'm not sure that could explain why it suddently blows up when i go near monotonic_ns().
This is telling, it's something to do with the evaluation of the result in the argument to a function or specifically to print.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit CLUE nRF52840 Express with nRF52840
>>> from adafruit_clue import clue
>>> import time, gc, random
>>> gc.collect() ; gc.mem_free()
89872
>>> a=[(1.0, 2.0, 3.0) for x in range(500)
... ]
>>> gc.collect() ; gc.mem_free()
71648
>>> read(500)
...
It's got weirder, following on from commands in previous comment:
>>> t1-t2
-1782595000
>>> print(-1782595000/1e9)
-1.78259
>>> print(t1/1e9)
18424.0
>>> print((t1-t2)/1e9)
MemoryError: memory allocation failed, allocating 512 bytes
>>> print((t1+t2)/1e9)
MemoryError: memory allocation failed, allocating 512 bytes
>>> print(t1/1e9 - t2/1e9)
-1.78125
>>> print((t1-t2)/1e9)
MemoryError: memory allocation failed, allocating 512 bytes
@rare geode With the Atom plugin, what assumption is made about which USB is used for serial/REPL (assuming I have multiple CP devices plugged in, and they each have unique volume names)?
Right, it doesn't handle that brilliantly, it just iterates through all ports and checks the vendor IDs against the adafruit one (with a JavaScript find, which may or may not be predictable I can't remember) https://github.com/jos-b/language-circuitpython/blob/master/lib/atom-serialport.js#L25-L33
@tulip sleet it's been a while since I touched it, but I just noticed that the SAMD implementation doesn't actually do pin claiming. Do you know why that is?
@ionic elk samd implementation of what?
pin claiming. There's no array in the samd port that stores what pins are being used by modules
It only protects things like the neopixel. But you could otherwise grab a pin that's being used by an existing module and it wouldn't be able to tell.
Contrasting to the NRF port, which has a table that stores every pin in use, and the STM32 which was based off NRF.
@ionic elk it does it in a different way, by looking at the pin mux settings: https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/common-hal/microcontroller/Pin.c#L191. claim_pin() only special cases things it can't catch by checking that. Otherwise it can figure it out by looking at the registers.
Ah, gotcha, so it uses pin number for everything then
it uses an integer pin number, but the point is that there's a common register for most pins that says what function that pin has been assigned to (e.g. a particular peripheral function). There's no such common thing in nrf, for instance: each peripheral has a pin mask, and the pin gets assigned to the last peripheral that had the pin chosen in its pin mask.
e.g. see pages 30 ff. in http://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D21_DA1_Family_DataSheet_DS40001882F.pdf
Hmm, interesting. I guess the equivalent for STM would be that each pin has an altfn, but that isn't enough to tell exactly what peripheral you've assigned since a single pin-altfn combination can support multiple peripherals.
anyway I'm just asking because I'm implementing it for i.MX now. I think I'll probably just stick with the claim-pin array
in STM does the altfn setting getting cleared if the pin is not in use?
spending 8 bytes on a claimed pin array in exchange for not having to do register reads seems like a good tradeoff
I have actually never read altfn stuff out of a pin, the ST hal is pretty one-way
in samd the pinmux settings are the ground truth, so it's kind of the same thing as having a pin claiming array
I'd have to look up how the actual registers store it and do my own implementation
Yeah ST doesn't have that kind of globally stored information they count on you having a bunch of structures for everything that you either pass around or toss and re-do
in the atmel world people are a lot more inclined to use the CMSIS direct-register layer when needed, i guess
I could have used it more in STM32, but honestly I just think the HAL is more readable
the hal layers are often relatively thin. they mostly do higher-level driver stuff which you'd rather not write yourself, like buffer mgmt
Well, actually, no, the big reason to use the HAL in STM32 is because the registers are different between every chip family
lol
so you save yourself a bajillion preprocessor statements.
also the hal can be pretty incomplete, especially in asf4. There are multiple layers
that makes sense. the samd21/51, and the other related sam<x>11, etc. all have pretty similar peripherals.
the samd51 was a bigger departure than most
So, if you set a pin for a certain peripheral in SAMD, is it actually impossible for it to conflict with another one and get undefined behavior?
Because in STM32, you can totally assign two different clocked peripherals to the same pin and spit out garbage
yes, impossible, because it's set by the pinmux register. nrf sets the crossbar to the last periph you chose: you can't set it to two periphs simultaneously
neat
(I did ask that question of Nordic: https://devzone.nordicsemi.com/f/nordic-q-a/37337/same-pin-selected-in-psel-registers-in-multiple-peripherals
I just wanted to chime in with some words of encouragement.
Thanks @WarriorOfWire! I'm excited to see this merged :)
@ionic elk using register state is better because it can coexist with other code that isn't in circuitpython
an in-memory array can be ignored
in iMX you'll want to look at the IOMUXC peripheral
@slender iron yeah I'm trying to see if it's possible to do in i.MX
I can see the advantages
but so far, I really can't say I'm a fan of the i.mx docs or commenting... this IOMUXC peripheral is inscrutable
what are you reading?
I've got the MCUExpresso SDK manual, the 1010 Reference Manual, and the actual IOMUXC macro definitions page open
kk, I'm looking at the reference manual
reference manual seems like the best bet, the API manual is basically useless they don't list any of the actual settings or explain very much
ya, I tend to stay in the data sheet / reference manual
the samd data sheet has the reset state but I don't see it here
I'm just trying to figure out what the reset state is yeah, so I can implement reset_all_pins
but they don't have a macro for it, and they don't list a define option either
usually it's connecting to GPIO without the input and output buffers on
macro for the reset state?
(low-pri) mp_hal_ticks_us is not implemented on the samd port.
Not sure I actually want that though - would love a utility function (or macro, whatever) that returns just an unsigned reference counter that counts micros or nanos or clocks... anything finer than milliseconds from the supervisor ticks. I'm probably missing something and this already exists?
I'm looking for a "set_pin_disable" thing is what I mean
both to use and to know what pins are at startup
@low sentinel you now need to start your own timer for high res time-keeping because the monotonic counter is only 32768 ticks a second
see pulsein as an example
in ST hou HAL_GPIO_DeInit
thanks
@ionic elk it might be quickest to just read the registers on start up
in ST you've got the HAL_GPIO_DeInit function
@slender iron yeah that's probably a decent idea
the "functional description" subsections are usually the most useful
the gpio peripheral has reset bits
ah, IOMUXC has reset value in the memory map
@ionic elk
Hmm, so it's different for different pins I guess
k
This isn't urgent... so just whenever has some time...
I saw in the CP 5.4.0 Beta release notes that the OpenMV H7 board was added, which was a big surprise (I own one). It looks like this was some sort of early support step to enable further development... but I didn't find any tracking issues. What's next for the OpenMV running CP?
It should run but it won't have any camera support
I saw Kwabena's comments about making a more universal library for the camera, so I'll watch for that work to happen and come to CP. Thanks Scott!
cool cool. we mainly just wanted to be able to test on it
we do want to do camera support at some point but I doubt we'll ever match openmv's support
Love that idea of camera support for CP and ya know a Camera Feather Wing...
And then CP DashCams, CP VanLife\AdvVan Cams, CP Astrophotography... 🙂
😄
Looks great! Thank you!
I'm assuming we'll have bugs to track down with the lower_power merge. So, merging this is fine once TinyUSB has the needed update. We can test the other background stuff in the beta releases.
Thanks for the merge! Looks great.
as-is:
Circle -> shape:{1012px, 2.9ms, 345429.0pps fill} shape_pixels:{1098.6us total, 1.1us/px}
Circle -> shape:{ 880px, 2.4ms, 360448.0pps fill} shape_pixels:{ 732.4us total, 0.8us/px}
Circle -> shape:{1012px, 2.9ms, 345429.0pps fill} shape_pixels:{ 732.4us total, 0.7us/px}
Circle -> shape:{ 880px, 2.4ms, 360448.0pps fill} shape_pixels:{ 732.4us total, 0.8us/px}
Circle -> shape:{1012px, 2.8ms, 360446.0pps fill} shape_pixels:{ 976.6us total, 1.0us/px}
Circle -> shap...
@gilded cradle How about a 12 character display? 😀 I also have 3 of the 7-segment displays to solder. I will do those tomorrow. Now, I have to wire these up. 😀😉
Why? The callbacks shouldn't be allocated on the heap because background tasks run when the heap doesn't exist.
/shrug can always add it in case. small builds will drop it because of LTO.
They are at addresses 0x70, 0x71, and 0x72
Dang, I am out of jumpers. I should have thought to order more when I got the displays. Oh, well, that will have to wait until next month or after. 😦 😦
Kk, it's not super easy for me to get so I'll just close this. I believe #2874 fixes this.
@tannewt I think you mean #2866? If so yes that was the intended fix, I forgot to put in the Resolves keyword.
@idle owl I'm getting the dreaded "toctree contains reference to document 'api' that doesn't have a title". You put something here a couple of months ago that said it was due to autodoc_mock_imports being incomplete. I've added everything under the sun to that, and I'm still getting it. As with you, I cannot figure out what is different in this library vs others.
@tulip sleet Running locally or it's pushed and running in actions already?
Following up on the issue in #2866, the "backup domain" causes issues with low speed oscillators if it does not have write access enabled. This low power domain write access has now been enabled for the F4 family, but the F7 and H7 were skipped as they have different register settings.
This should ideally be solved by moving ALL of the low power oscillator setup code from port.c to the peripherals directory. The HAL RCC setup functions already in use there will handle these low level regi...
I was going to ask to see it, that's why I asked whether it was pushed.
oh, maybe i haven't pip'd something it needs locally
@tulip sleet I received that same error working on my library. I noticed api.rst was missing a title line compared to the other RST files. I had to look at it in raw to see it
but most of our api.rst files don't have titles, and they don't fail :/
None of ours have titles. They are auto-generated
Let me see the code @tulip sleet, you may need to automock something oddly to make it work. I've had to I think.
hold on one sec, I am trying one trick
Everything looks good! I merged in translations from master and will merge this once it passes CI.
Others can help test once we merge. :-)
@tulip sleet adafruit_ble isn't automocked.
Thanks for this! I'll merge after I resolve the translation updates for you.
This is fine. :-) Just my initial reaction and clearly you've thought about it way more than me.
I'm a little sad it takes so long to draw a large rectangle and would like to profile to find the slowest parts. The shape API could be extended to allow shapes to provide batch pixels if their implementations have a fast way to determine batches (rather than 1px at a time).
I thought about doing run length masking and pixel values instead of individual ones. However, I needed to pull myse...
@idle owl added it locally (and also made sure it was pip'd); still failing
@slender iron @indigo wedge Could I get a quick sanity check on the chip pin reset? From what I can tell, the mimxrt does not have any functions capable of automatically returning pins to a reset state. Additionally, the individual reset states of each pin register at startup are not consistent - the SW_PAD_CTL_PAD_GPIO registers differ in their pullups.
So I think, given this, I'm going to need to store the reset state information per pin, and then add an array of pointers to every pin I can iterate through in order to correctly set pin to the reset state. Am I missing anything that would make this unnecessary?
@tulip sleet I'll take a look. Cloning now
I don't know how critical it is to preserve the pullup information at reset for each pin, but I figure it's important to have the startup state match soft reboot state
@ionic elk Hmm, I haven't looked into the reset states so I'm not that familiar with them, having a table seems a bit overkill but I guess it makes sense for consistency. We could also agree on a reset state and apply that on reset but then the state might differ before the the sw takes over.
It seems overkill to me too but I've never seen a HAL layer before that literally doesn't have a function for pin reset
So I'm not sure, maybe @slender iron knows more or can share his thoughts from the viewpoint of CPY
So I'm kind of scrambling here lol
@tulip sleet You're going to hate this.
i made a spelling error
Wait, maybe not.
is that it?
I'd default the pinmux to 0x00000005 and then special case the others that don't match like JTAG
when I run sphinx-build locally I always do -a otherwise it caches bad builds
@tulip sleet No I thought it was a whitespace issue, but it had ignored that change and didn't actually rebuild. So it looked like it passed. nm.
Oops, looks like I don't have permission to change your branch. Here is a PR into your branch: https://github.com/WarriorOfWire/circuitpython/pull/1
@idle owl @tulip sleet intrigued. hopping in too.. 😄
@slender iron Build CI has not yet run on the new build configuration. You sure you want to merge now?
you can merge my PR into yours and then yours will run
I won't merge into master until it's green
https://github.com/adafruit/circuitpython/pull/2827 may cause us to need another merge too
translation files are finnicky
countio and vectorio will be good to get in before https://github.com/adafruit/circuitpython/pull/2810
Translations are extremely nice polish. It's only a pain when you have a high rate of change (a healthy project) 😄
I see that. I'll ff my vectorio branch
Thanks for this! I'll merge after I resolve the translation updates for you.
I was curious anyway; pull --ff-only was clean
👍
@slender iron you have any opinion on this reset pin business?
I'd default the pinmux to 0x00000005 and then special case the others that don't match like JTAG
looks
Basically, a bunch of different pads have different pullup settings
Currently I'm defaulting this to build where displayio builds. displayio claims these platforms in its docs. If you have displayio you should have vectorio unless the pending build shows we need to disable some platforms (e.g., due to flash space)
@ionic elk just ignore pad
it doesn't really tell you whether someone is using the pin
but it affects the pullup on startup, doesn't it?
Since the default for the MUX is GPIO
yes but I'm ok ignoring the pull strength when determining whether something is "in use"
the one thing I don't see is knowing that a pin is being used to read a digital value
there is an input buffer but I don't see what turns it off and on
Sorry, to back up, what I'm trying to do right now is reset all pins
but for reading the MUX to detect pin use, I'm not sure how I could do that either since the GPIO setting for it will be the same when it's used by DigitalIO, so I'll still need a claimed pins table to keep DigitalIO from trying to claim existing pins
most pads reset to 0x10a0
yeah I wasn't sure if you wanted the remaining ones accounted for
philosophically, to retain the same known state as startup
if it's nbd than it's nbd
you probably should because the pulls could be things like JTAG that need it
my guess is that the pad exceptions match the mux exceptions
you can detect output digitalio by reading GDIR
@tulip sleet @idle owl i've got it past the title error, but now hitting struct errors...
GDIR?
@tulip sleet @raven canopy Looking at other ones with packages, the api.rst file needs to have every file listed. What did you do to get past the title error?
I don't see that, only SION and MUX_MODE
look in GPIO
oh so I'd have a sub-check within GPIO
@idle owl list each file in api.rst, drop _service from the title in color_sensor.py, and change the autodoc_mock's entry for adafruit_ble_adafruit -> adafruit_ble.
i tried to mock struct but still throwing the error. not surprising since its in the stdlib.
Hah I just tried that too.
Should have known you'd try it.
@raven canopy Added adafruit_ble_adafruit back to automock in addition to the rest and it's back to the title failure, but the struct failure is gone.
mocking the library for its own docs seems...weird. 😄
@ionic elk so ya, I think you need a bitmask to track in use. since pins default to in
@raven canopy Agreed.
@idle owl I did see a guide that had some pylint stuff in to workaround a mock failure, is that what you're discussing?
@simple pulsar I don't believe you saw that - pylint doesn't help with this. Sphinx is failing to build here in a way that is usually resolved by using autodoc_mock_imports properly.
https://learn.adafruit.com/pulse-oximeter-wireless-data-logger/code-the-pulse-oximeter-logger John Park has a comment in there about BLERadio on lines 54-55
ahh. autodoc is coughing on the const(0xFF) not being an integer...
@simple pulsar Yes that is a Pylint issue, not a Sphinx issue.
Without that Pylint would fail, but Sphinx might build successfully.
@raven canopy I leave this in your capable hands, I need to tap out. Newsletter video needs to be done and I probably shouldn't have taken as much time as I already have to try to figure this out.
@idle owl thanks for trying. the things I have to say about sphinx...
hey folks, after lurking a little bit it feels like I definitely built this one up in the wrong place to actually propose it (https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/99)
where should I rather suggest this for discussion? 🙂
@topaz quest You can open a new issue on the library or core part you are working with.
this is a bit of a meta-issue pretty much -- I'm suggesting license-tagging the source to match https://reuse.software/ specs (because right now from the docs pages there's no obvious license/copyright info attached to examples)
You can suggest anything in an issue. It does not have to be code related.
no that part I guess -- the problem is that this is less library-specific and more "throughout project" kind of suggestion
(or if it's not meant to be a throughout project, then I guess that pull request is fine)
It does not have to be library specific or even core specific. It could even be infrastructure related.
Or pretty much anything else.
As long as it relates to Circuitpython in some way.
@topaz quest we don't put licenses in the example files because it just bulks up those files, and the applicable license is the license file for the repo anyway
@tulip sleet yeah I agree it would bulk up to put license headers everywhere, that's what REUSE is trying to fix by relying on single-line SPDX indentifiers instead
Is it now therefore possible to use a built uf2 on feather_stm32f405_express - you'd still pull boot0 up I assume but how would you flash this ?
@topaz quest for project stuff we usually just have it on adafruit/circuitpython. The weekly meeting is the best place to discuss it
I'll move the issue
ah, it's a PR. I won't move it. 🙂
There are two kinds of bootloader for the feather - the built in one, which is stored in a special region of memory, and the UF2 one, which is stored in the beginning of the flash memory and uploads to the flash after itself. To use the UF2 bootloader, you'll need to actually program it into flash using either the built-in bootloader, or by using a dedicated programmer over SWD or JTAG.
The UF2 bootloader is a separate binary that you need to compile from here: https://github.com/adafruit...
ah, it's a PR. I won't move it. 🙂
@slender iron yeah sorry, I got overexcited when I was looking at that and didn't think to look up the right way first ^^; I'll open an issue after dinner and reference the pull request as example for implementation 🙂
yep, reuse-tool has a lint mode which integrates with pre-commit and other continuous integrations explicitly for that 🙂
(and that's what I love about it)
Does CPy have an mDNS library?
not that I know of
darn. I was trying to implement something using one. oh well
couldn't find one, so i should have figured that
@prime flower would know for sure
i cant wait for a iMXRT1062 feather
All these m0's making it hard to add stuff https://github.com/adafruit/circuitpython/pull/2873/checks?check_run_id=668477450
ya, I feel ya
Are there any naming guidelines for custom circuitpython libraries? I'm writing one for the Dyanmixel servos, and I'm not sure what to name it.
Hierophect_Circuitpython_Dynamixel?
ya, that's what I'd suggest
Seems like basically everything in the bundle is Adafruit, but I could have sworn there were some user contributed libraries, is that not the case?
there is a community bundle
@ionic elk https://github.com/adafruit/CircuitPython_Community_Bundle I was just looking at it myself
forgot it was running actually
you're not posting on adafruit as you idle on Torbjorn? disappointment
that's my pro strat
The REUSE specifications are a suggestion coming from FSFE to make code licensing information explicit and easier to apply. They build upon SPDX Tags to make it obvious (and at the same time less verbose) which license apply to a certain work: code, documentation, examples, etc.
I have been suggesting its use and using it for my own projects, and I feel it would be a positi...
alright - I'm hooked. Python virtual environments are really nice.... old dogs -- new tricks 🐶
they really are
I'm done kicking and screaming...
i finally started using venv some months ago. they do help.
I found it hard to leave Wordstar, too 😉
Just ran into a simple case -- the Adafruit_nRF52_Bootloader build Makefile uses "python" -- it works fine with python3 but my newly updated Ubuntu system only has python3 -- at first I edited the Makefile to change "python" to "python3" but that was not very satisfying -- generated a "dirty" build. Creating a python3 venv worked much better.
@solar whale I was disappointed when edlin disappeared.
sigh...
I may or may not have used joe for my first few years as a Linux user because it worked with my muscle memory...
we better switch to politics ... 😉
sorry -- did not mean to stifle the conversation....
@solar whale wait till we get you using pyenv to run multiple python interpreters... 😄
Everything looks good! I merged in translations from master and will merge this once it passes CI.
boot.py executes first if it exists, then it seems the run priority is: code.txt, code.py, main.py, main.txt ...or is that order not deterministic? (thinking about ways to do OTA code.py update w/o a custom bootloader)
Anyone know a better way than
del sys.module['MODULE-NAME']
to remove all instances of a module in the heap? I want to be able to dynamically re-import a file already located on the filesystem.
@tulip sleet - any tips 😇?
basically, no, it's not easy. @marble hornet has been doing this a lot to try to unload and load things to save RAM. But it's painful. are you doing this just for testing purposes or you're writing a big program?
consider restarting the whole thing and deciding what to import based on the next task
And it is quite doable, you just need to be careful about references
it's not something that people typically do with python
Interesting!
My use case is dynamically updating PORTIONS of a circuitpython script over-the-air by making the code modular and then pushing new .mpy files over RF
i will leave you two to it, good night, but consider just restarting to avoid leaks and fragmentation
thank you @tulip sleet 🙂 I will take a strong look at that again
@marble hornet can you elaborate a lil more about your references comment?
I'm imagining the other potential references made to the module floating around?
I'd suggest reading about python's import system, more precisely here: https://docs.python.org/3/library/sys.html#sys.modules . May i ask why you need to dynamically re-load portions of code at runtime?
(is it watch based? )
@marble hornet thank you that tabs is open, but I found myself using python3 features in the python3 REPL (like reload()) that wasn't available once I went back to CP.
The goal is basically "hot code swapping" where the VM will do things like:
if X: import everything in /abc/
else: import everything in /def/
if that makes sense
@lime trellis yes? since python is garbage collected you can "reload" a module be delete every reference to it (this includes the ones in sys.modules) then calling gc.collect . then you need to re-import. I find that using the import <name> statement to be a bit clumsy for this and tend to use the __import__('<pathw/dots>') function . if you want to go into more detail we could schedule a time to chat and code together during a non nocturnal hour.
and see if there are better, less-fiddely solutions to your use case
@marble hornet those are excellent points, thank you. I also really appreciate the offer! Let me wrestle with things for a while before I take any more of your time. I'll ping ya when I have a better feel for the limitations of my current approach and see if there's time in your schedule
sounds good, as a hint I'd suggest two things: removing all bust one reference to modules at the time of import and comparing the previous sys.module.keys() vs the one after importing.
@lime trellis also, if you have a trusted source, you could just read the text into a variable and exec() it...
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 3.0.0-alpha.1-5657-g99a833bd6-dirty on 2020-05-12; Adafruit Metro M4 Express with samd51j19
>>> import os
>>> os.listdir()
['.fseventsd', '.metadata_never_index', '.Trashes', 'code.py', 'lib', 'boot_out.txt', 'System Volume Information', 'exec_source.txt']
>>> source_text = ""
>>> with open("exec_source.txt") as f:
... source_text = f.read()
...
...
>>> source_text
'print(\'exec_test.txt source read...\')\r\nclass foo():\r\n def __init__(self):\r\n self.msg = "Hello, I\'m foo."\r\n\r\nprint("class \'foo\' created. creating \'bar\' as an instance of \'foo\'...")\r\nbar = foo()\r\nprint("bar has a message for you:", bar.msg)'
>>> exec(source_text)
exec_test.txt source read...
class 'foo' created. creating 'bar' as an instance of 'foo'...
bar has a message for you: Hello, I'm foo.
>>>
@raven canopy holy cow! I never knew about exec ! Thank you 🙂 I have more reading to do now
its handy. but i'll stress it again: use with trusted sources only. exec and eval have no real safety net...
hehe
also, just so you're aware. if you use classes/etc like i did above, you can still run into long-living objects:
>>> globals()
{'bar': <foo object at 200037f0>, 'os': <module 'os'>, 'source_text': 'print(\'exec_test.txt source read...\')\r\nclass foo():\r\n def __init__(self):\r\n self.msg = "Hello, I\'m foo."\r\n\r\nprint("class \'foo\' created. creating \'bar\' as an instance of \'foo\'...")\r\nbar = foo()\r\nprint("bar has a message for you:", bar.msg)', 'f': <io.TextIOWrapper 200032f0>, '__name__': '__main__', 'foo': <class 'foo'>}
I believe it! just compiling byte code all willy-nilly haha
i love it. Thanks for the tips!
happy adventures! 😄
Takes polygon from 126k pixels per second fill to 240k pps fill
on a reference 5 point star 50x66px polygon, updating both location and shape
at 10hz. Tested on an m4 express feather.
As a curiosity, the flat-out fill rate of a shape whose get_pixel is return 0;
fills just shy of 375k pixels per second.
Baseline:
Polygon -> shape:{1020px, 8.1ms, 126603.0pps fill} shape_pixels:{5859.4us total, 5.7us/px}
Polygon -> shape:{ 510px, 4.0ms, 126603.0pps fill} shape_pixe...
All working and Beta 5.40 on the board as UF2 using make BOARD=feather_f405.
Only small thing is when in bootloader mode board shows as
But fully functioning - many thanks hierophect 👍
@lime trellis I highly recommend Dan's suggestion of replacing the mpy and then rerunning the VM. Trying to delete imported modules isn't recommended and I would have no qualms breaking how it works.
Yes, we haven't gotten around to changing it to exactly match the Adafruit UF2 bootloaders. I'm glad it went smoothly for you!
@tannewt your advice was right on, thanks.
Closes: #2880
Looks great! Thank you for this!
I also attached a fix for samd audio dma in this PR. Other platform (i.e., nrf) audio probably also needs a check. I can split it to a fresh PR if you prefer.
@twilit geyser I have a pure-python implementation of the arduino dns client (for wiznet5k chips) here: https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k/blob/master/adafruit_wiznet5k/adafruit_wiznet5k_dns.py. But it doesn't support mDNS afaik.
I assume that the "same" fix as samd is needed in order to make audio play properly after reduced power.
Testing performed: only building the software
I'm using _bleio directly and not using BLERadio. Perhaps I should learn how to use the latter. However, at this time I am not using BLERadio.tx_power.
Looks good! Thank you for the fixes!
Are there interrupts generated when the DMA buffer swaps? Using that would be better than the tick enable because it'll happen at the needed frequency.
@Dar-Scott BLERadio.tx_power doesn't do anything right now anyway :). It returns 0dBm and you can't set it.
@slender iron I have finished with Adafruit Services but it needs a CPy build with the PacketBuffer fixes. 5.4.0-beta.0 has that USB disconnect issue (I see it on nRF) and also runs the services demo programs a lot more slowly possibly due to shutdown/wakeup, even though there are no explicit sleeps in the main loop. Are there some fixes for 5.4.0 that are imminent, or should we think about a 5.3.1? We can discuss at meeting tonight... I still have some guide pages to write before it's ready.
@tannewt I can look into it if you have a pointer to where else we're doing this. In samd audio it looks like audio interrupts "are involved" (e.g., we look at event_interrupt_active to decide whether more data needs to be fed) but it still didn't work, which is why #2889 had a similar "fix" for audio weirdness. I guess both could use further looking into rather than speculative fixes.
e.g., in nRF I2SOut we can allow EVENTS_TXPTRUPD to generate an interrupt. But there is no explicit handler defined for it. Does this mean it would get a dummy interrupt handler and all would be well?