@balmy sail that may be useful as a reference, however the main thing you'll be doing is adding a peer to _write_register_byte that uses SPI instead of i2c:
https://github.com/adafruit/Adafruit_CircuitPython_ADXL34x/blob/master/adafruit_adxl34x.py#L410
#circuitpython-dev
1 messages · Page 309 of 1
(and _read_register)
you can probably use these:
https://github.com/adafruit/Adafruit_CircuitPython_MAX31856/blob/master/adafruit_max31856.py#L272
@balmy sail do you have more than one ADXL343 sensor ?
or 345
2x 343s
what micro are you using ?
any circuitpython compatible boards?
(stuff here:) https://circuitpython.org/downloads
not a bit deal if not
the pi's are compatible arent they? im using circuit python on the zero with i2c and he adxls
ah yeah, ive got a couple of m0 feathers
kinda? They technically run normal CPython and use Blinka to allow the circuitpython libraries to be used
I don't know that it matters either way.
@slender iron sorry -- I tried your esp32s2-busio branch and the I see the same behavior on Linux -- still fixed by Mac.
I'm just used to primarily working on new drivers on a Metro M4/ Feather M0, etc.
@balmy sail let's stay on the Pi for now
it would be useful to test the I2C and SPI side by side, so if it's not too much trouble, try to get the second 343 working on the other pi
ok
I think it may be useful to see what if any quirks there are to working on the Pi, but it it gets annoying we can switch
thats easy then, ive already got them working on i2c on the zero, can use the pi4 for spi
great!
lmk when you've made a fork of the existing library and checked out a copy of your fork on the Pi4
also let me know if you're not familiar with anything I'm suggesting
@slender iron I was using this build ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 2.0.0-7343-g3621fc08b on 2020-05-28; Saola 1 w/Wrover with ESP32S2
@indigo wedge where did you get the pin definitions used in the pins.c for the EVK?
I'm finding some issues
Not that it's easy, do you find NXP's documentation to be like, obnoxiously bad?
Ok cool that's what I'm looking at
But like dang they don't even give you a table for the Arduino connections, you have to piece them together over like three sheets
I've got the schematic open it's all good
ah ok
I was just wondering if you'd found a pin table somewhere else that was conflicting
@balmy sail I'm going to be in a different window so please @ me as much as needed to get my attention
will do, thanks for all the help
same to you!
got it -- building now
I am curious to see if it helps the FS problem
I should probably split that fix out if it does
oohh -- first test is OK -- let me erase and do a clean flash
🤞
ok great!
I'm opening this issue so that we can discuss how we speed up the builds. Here are a few ideas.
Docker image containing dependencies
Clean gcc-arm-toolchain folder so it contains only needed files (my initial tests show ~600mb can shrink to ~100mb).
Use GitHub Actions caching (https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action)
@slender iron @indigo wedge Have you ever had a DAPLink on an mimxrt EVK get stuck in this "MAINTENANCE" mode?
I can't tell if my board has just bricked itself or what but I can't program it over either the DAP or JLink anymore
hmm, i remember it happening to me once i don't quite remember how i got out of it
Sorry about that! Could you check make merge-translate? I may have it's functionality backwards.
@ionic elk it might be i downloaded the daplink fw for the evk and copied it over and that exited the mode
Normally when an MBED dap is in maintenance mode that's a reset pin related thing but I'm not pressing anything and the Jlink isn't even plugged in
so you had to re-flash the DAP firmware?
i can't quite remember if it was this evk or another one so dont take my word for it
how does a DAP screw up its own programming? what the heck man
Translations update from Weblate for CircuitPython/master.
Welp, we merged more translations and I can't merge for you. Mind adding me as a contributor to the Simmel repo?
Ok, I think I have a fix for this in my esp32s2_busio branch. The memcpy was copying too much into the cache (therefore overwriting with garbage.) I'll split it out today or tomorrow with a couple other fixes and get it PRed.
The STM32 port is currently using an erroneous value for the I2C Timing setting on these MCUs, resulting in a constant speed of 100k rather than the proper 400k default with adjustability to 100k. These should be replaced with a proper calculation based on the frequency parameter.
// Note that `reset_port` CANNOT GO HERE, unlike other ports, because `board_init` hasn't been run yet, which uses `never_reset` to protect critical pins from being reset by `reset_port`.
@tannewt @ArmstrongSubero missed this issue. Highly likely it's related to the low power domain which I managed to fix for the F4s but may have had some straggler issue for the F7 series. I'll check it out as soon as I can.
@tannewt was going to ask you about this - do you think this is the best solution? Or should I move the never_resets somewhere else?
@indigo wedge If you have a free moment, could you check and see if you can get an SSD1306 working with SPI on my cleanup branch? I'm not able to get mine to turn on but I don't have a second one to cross reference with. https://learn.adafruit.com/monochrome-oled-breakouts/circuitpython-usage
My other SPI devices work just fine
Hmm, not sure if I have one on hand
Another interesting case of timing in CircuitPython: Question about stepper motor control
A user is interested in achieving a certain rpm with a stepper motor and the discussion yields a suggestion which is likely to be interepreted as a while/for loop with 'kit1.stepper1.onestep(direction=stepper.FORWARD, style=stepper.INTERLEAVE); time.sleep(0.006)' in it.
Teensy noob fail. didn't realize they don't have JTAG broken out on the board. back to the retailers of fine devkit boards... 🤦 🤣
- Update ESP IDF and change USB init accordingly.
- Fix flash writes that don't end on a sector boundary. Fixes #2944
- Fix enum incompatibility with IDF.
- Fix printf output so it goes out debug UART.
- Increase stack size to 8k.
- Fix sleep of less than a tick so it doesn't crash.
☝️
@tulip sleet and @simple pulsar thanks for the help. Have the Clue working as a display for BLE beacons now. It is decoding Ruuvitag and TLM data so I can see temps around the house.
very nice!
@slender iron will try esp32s2 later or in morning. Is it necessary to reinstall esp-Idf after the changes or are they picked up automatically?
@solar whale you shouldn't need to reinstall, just update the submodule because we actually use that one
the other is just used to install the tools
Ok. Thanks
np, thanks for the help!
@slender iron I have a q re bleio_scanentry_data_matches() in shared-module/_bleio/ScanEntry.c. I am not sure it is doing what I think it should do. Looking at the else if (!any) { part, which would seem to me to return false prematurely if the first prefix doesn't match the first structure.
i thought it was trying match the first prefix against all the strcutures. If it can't and !any is true (i.e., all), then it should give up
ya, sounds right
i was writing the python equivalent and couldn't suss it out. OK, I'll see about fixing it.
We won't because most ports already had it on. This turns it off for ESP32S2.
thanks @tulip sleet. this is what happens without unit tests...
yah, i really want to write unit tests for the advertisement parsing I am writing in Python.
bleio_scanentry_data_matches() in shared-module/_bleio/ScanEntry.c returns false prematurely if the the first prefix doesn't match the first structure and !any is true. It should try all the structures.
@vale spire you ever debugged a "byte code not implemented" error? Maybe on esp?
@slender iron I wonder if you are just reading bad data
with the byte code thing?
yes, maybe see when it happens and see whether the adjacent bytecodes make sense. Maybe it's an edge condition on a page read or something
is it an imported mpy?
it's not a file reading issue because it's a regular .py
so it parses ok
a def in code.py works ok though
so it's something around import
is esp32s2 tossing things in and out of ram?
i thought it was doing some "paging" possibly?
it does have instruction and data caches but I don't think that's the issue
i meant manually, i thought maybe the esp8266 was doing that, or maybe that was flash sections
I don't think it is
if you make the program bigger or smaller does it change?
it's about as small as I can get it
(but my original theory of a bad .mpy read is shot)
Probably unrelated, but I did see "byte code not implemented" early on with esp32s2, but I attributed it to unerased flash (possibly some kind of memory/pointer issue a factor). Not really sure.
I haven't seen it since I started erasing always before flashing ...could be coincidence
the printing is maybe forcing somethign out of a register
No, only core modules
ya, it's something to do with a py module
my testlib.py is:
print("running import")
def hello(param):
print(param)
code.py is:
import testlib
testlib.hello("world")
print("hello top level")
def nested():
print("hello nested")
nested()
the testlib.hello call fails
If I run that, but delete the hello function and comment out the call in code.py, it never gets to the "hello top level" and subsequent attempt to save makes the drive disappear (time to re-erase and re-flash)
(Guru Meditation Error)
yup, that's what I'm seeing
kk, got it fixed
sooo, what was it?
the register window hiding stack values
Bluefruit Feather Sense photos were done on a coarse background, which I noticed every time I downloaded CircuitPython. Updated with shop product photo.
fix is incoming. just added another comment
From the change:
// xtensa has more registers than an instruction can address. The 16 that
// can be addressed are called the "window". When a function is called or
// returns the window rotates. This allows for more efficient function calls
// because ram doesn't need to be used. It's only used if the window wraps
// around onto itself. At that point values are "spilled" to empty spots in
// the stack that were set aside. When the window rotates back around (o...
Thanks for the great documentation!
Good catch!
I am pleased to tell you that I and Peter Kessler caused this problem for you about 40 years ago.

@slender iron just tried latest master on esp32s2 -- FS works OK on linux -- blinky works (time.sleep() still won't go below 1 second) Anything in particular you want me to try?
@solar whale the newer fix should make imports work
ah, I think it's calling something from a library that fails
I just made a library with a function that prints (posted above)
ok -- that works ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.4.0-beta.0-389-g6ace4ee7e on 2020-05-28; Saola 1 w/Wrover with ESP32S2
import test
running import
world
hello top level
hello nested
ah -- will pull
tomorrow will be busio debugging on the stream
naïve question... for a completely new processor family like xtensa, I assume the .py-to-bytecode is the same, but bytecode-to-C for the port has to be written or heavily tweaked? Was the ESP32-S2 able to use a good chunk from MicroPython ESP32? (otherwise, the port seems to have gotten where it is insanely fast, even considering how much work has gone in)
all good now ```uto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
running import
world
hello top level
hello nested
What time is your stream tomorrow?
@crimson ferry the python VM is pretty much the same, since it's C code executing the byte codes. The new work is implementing the peripheral modules (digitalio, etc. etc.), and also accomodating peculiarities of the architecture.
Thanks, tough time for me, but I'll watch it later.
the ESP32 has idiosyncrasies, and the underlying HAL library Scott is using has a complicated build structure.
idiosyncrasies -- you are being very kind...
Thanks, Dan. peculiarities and idiosyncrasies... wouldn't want it to be boring 😉
@slender iron I saw a note in the last PR about fixing time.sleep() not to crash. It still doos not go < 1sec -- is that correct?
@solar whale I haven’t looked into that yet so I don’t know.
np. Thanks.
Sure, I added you as a maintainer.
Is there a podcast of this weeks CircuitPython meeting? I’d like to catch up!
Is this due to Floating point not being enabled?
https://github.com/adafruit/circuitpython/blob/master/shared-bindings/time/__init__.c#L66
@bleak tiger its up on YT, but i'm not seeing this week's meeting on Spotify. not sure about other podcast services. https://www.youtube.com/watch?v=GCEQA3a0jcQ
@solar whale When you say '<1sec' for time.sleep() do you mean below millisecond resolution?
no - if you put in .25 sec -- it delays 1 second
Is that only on a specific CP version or specific boards? I may have missed some context here on the conversation.
@tulip sleet For https://github.com/adafruit/circuitpython/pull/2974 is there a performance argument for doing the "spill" conditionally if it's only needed for GC? At the moment there only appears to be one other execution of cpu_get_regs_and_sp in the code and I think it's a one-off but I'm just wondering if it's more future-proof if it's conditional?
@simple pulsar I have not looked in detail at this, @slender iron would be more up on the code. I think we might also look at what MicroPython did for ESP32 (and maybe that's where @slender iron got the idea).
Interesting. I'd never even heard of xtensa before this. My coffee table is made out of old SPARC IPXs though so I have a constant reminder of register windows 🙂
do you have a picture of that coffee table? 🙂
As requested by @ladyada. Does not fit on nrf52833 with other default choices. Appears to fit on all nRF52840 boards even with internal filesystems. Full build will confirm.
good morning!
Is it possible (and/or relatively easy) to create a build of Circuit Python for a specific device that does not include the USB Serial connection? So it won't connect to the host device via serial which means that REPL and serial console will be inaccessible?
Thanks @raven canopy I usually listen in on apples podcast service.
@lone axle I'm sure it's possible, but I don't know how. Is the goal simply to prevent UART access, or is it to reclaim flash space ?
@lone axle yes, it's not hard, you have to adjust USB_DEVICES .mk variable. I have such a build for an HID volume control I am using.
I want to have multiple devices connected to a host machine (Android if it matters) but only have 1 of them show up as /dev/ttyACM0 and not have any of the rest connect. That way I can always be sure to find my device at /dev/ttyACM0 instead of some other number.
Thank you!
only the first to connect will be /dev/ttyACM0
the rest will connect but as /dev/ttyACMx
@lone axle linux ?
@solar whale right. So by preventing all of the others connected to serial at all I can be sure that I'll only ever have /dev/ttyACM0
@onyx hinge yes mostly... Android.
On my debian linux system, there is a neat feature called serial by-id. A given device will always have the same name within this directory. However, your software has to be prepared to use such filenames
ah -- misunderstood
/dev/serial/by-id/usb-Adafruit_Industries_LLC_Feather_STM32F405_Express_24002500F005D42445632302-if00
change USB_DEVICES in the mpconfigport.mk for your board to be something like:
USB_DEVICES = "MSC,HID"
default is "CDC,MSC,AUDIO,HID"
e.g., this STM32F405 always appears at exactly this path
@xobs please check it out :)
there's also by-path, so /dev/serial/by-path/pci-0000:02:00.0-usb-0:2.4:1.0 should always indicate the device plugged into the specific port
but I dunno if android has these nice things
Ooooh, That is neat. I don't seem to have a by-id directory in /dev/ on this device though. This happens to be a fairly cheap no name Android tablet, I'm sure the specific implementation of Android on this device is a bit wonky.
I really like it. It's even better in combination with the program tio which is a simple terminal program which can automatically reconnect. So when I tio /dev/serial/by-id.... it will keep the terminal open even if I reset the device with the reset button
just to repeat, /dev/serial/by-id , by-id is not directly in /dev.
nifty!
@onyx hinge I had not seen tio before — that is .. impressive
@tulip sleet For https://github.com/adafruit/circuitpython/pull/2974 is there a performance argument for doing the "spill" conditionally if it's only needed for GC? At the moment there only appears to be one other execution of
cpu_get_regs_and_spin the code and I think it's a one-off but I'm just wondering if it's more future-proof if it's conditional?
@simple pulsar The only other call is when getting the stack bounds and it's done only a few times. We have much bigger performance things to worry about than this.
now I need to find how to install it on openSUSE
looks up tio for mac
it says it supports FreeBSD so I guess it should work
it's on brew 🙂
reminds me I need to figure out how to install brew on new job's mac
@slender iron I was not referring to current issues, more future ones.
I noticed that there are no search hits for VfsFat in the current doc build though it was in the 5.0.x docs. I encountered this locally because trying to link to storage.VfsFat in stubs documentation for the new _sdcardio module failed at doc build time. (#2863)
Testing the SPI module of the 1010 EVK shows normal results with a BMP280, but has no results with a 128x32 SSD1306 using DisplayIO (screen cross-tested on an STM32 to make sure it works). This could indicate a problem with either SPI or the DisplayIO module on the mimxrt port.
I don't currently have an I2C version of this screen, or another OLED screen to test with, so if anyone else has a DisplayIO device and a 1010 EVK they could verify this with it'd be helpful. I have this problem bo...
@ionic elk apologies if it's already been suggested, but is the SPI bus rate right? If it's wildly wrong (too fast) maybe some displays still work and others fail due to being out of spec
should be quick to verify which is why I suggest it
Q. High Memory Usage of Label: I'm working on a Markdown parser/renderer and am using a bunch of 'label' instances to draw the text on the screen. Label seems to use quite a bit of memory for each character in a tileGrid. For example, it uses at least 208 bytes for a 8x9 pixel 'a' character (maybe as much as 240 bytes when it's all done). I originally expected that the tileGrid would just use a pointer back to the original glyph.bitmap, but since it uses so much RAM, I'm suspicious that it's make a "copy" of the bitmap. Do you guys have any insights into what is causing the RAM usage and any options for reducing the memory usage? Important: I want to use a proportional font, so using an fixed (x,y) grid terminal approach is out.
@mental nexus each tilegrid instance has a lot of associated data, and the design of the on-disk font code also uses one Bitmap for each distinct glyph that is loaded. It leads to a lot of excess memory usage.
@mental nexus and a "label" is made of one tilegrid for each glyph
we have https://github.com/adafruit/circuitpython/issues/2566 with some suggested code that works but only if you can use the builtin terminal font
but I see you have already encountered that issue
Looks like an indentation issue.
-
VsFat's doc is indented beyond the start of the lines: https://github.com/adafruit/circuitpython/blob/master/shared-bindings/storage/__init__.c#L170 -
extraxt_pyiexplicitly looks for.startswith('//|'): https://github.com/adafruit/circuitpython/blob/master/tools/extract_pyi.py#L24
while that's the status quo we'd love to see someone improve things
Thanks @onyx hinge understood about one tileGrid per character. However, I'm confused about how tileGrid is using the bitmap. The label function passes in the glyph.bitmap, which I assumed was a pointer. But I'm suspicous that something more nefarious is going on. Otherwise, by looking at the C code, I didn't think there was so much overhead would take up that much space 200+ bytes per character.
The outcome is that if I want to write text to the whole screen it would take less memory just to keep a display buffer bitmap and manipulate that. In reality, I think I'm missing something here.
displayio_tilegrid_t has a lot of fields. I agree they didn't seem to add up to 200 bytes when I checked just now, though
I couldn't decipher everything in there but it didn't seem like it would take 200+ bytes of overhead for a "single-tile" label with one glyph. That's why I was wondering if it was somehow grabbing the bitmap and copying it, but I couldn't comprehend everything in there. [FYI I estimated the # of bytes used by a pre/post comparison of gc.mem_free() before and after the tileGrid instantiation inside the label function.]
200 bytes seems in the general area of what I recall
@tannewt @arturo182 Ok, I think this should be good to go. I've run quite a lot of tests on all the Busio modules along with DigitalIO and AnalogIO, and I've only had one breakout issue so far (#2977). Everything else seems to be pretty good - DigitalIO has all the right pullup and drive behavior, AnalogIO gets good resolution, and Busio works as expected on everything but the displays.
Since I was running so many comparisons, I also dug up some STM32 issues while working on this. Seems li...
You're 100% right that it's extremely limiting and it's hard to see a way for non-core code to improve on things. I don't think anybody is allocated time to work on it at the moment, so in a sense we're depending on the community to help us out.
@onyx hinge I tried some lower rates yeah, and the exact same sketch (copy pasted) works on STM32
It might still be something simple, I haven't looked into it too closely other than verifying that the SPI pins were working and at least trying to make it work. My primary goal for my i.MX testing PR was to turn the vague issues - "test this thing" - into specific ones.
Fortunately, haven't run into anything other than that one displayIO issue! Which is good because the STM32 bugs are piling up lol
Thanks @onyx hinge just wanted to make sure I wasn’t missing something with the current label code.
https://discordapp.com/channels/327254708534116352/327298996332658690/671805424973905974 In case you want to travel way back in time, here's the discussion from when I encountered the limitations
@onyx hinge Oh dang maybe that Label thing was why my unicode stuff was so unbelievably slow.
I'm working with Joey's Babel code this weekend. Maybe I'll turn up something useful.
Man, what possessed NXP to connect a bunch of the pins on their Arduino connector and then not document that anywhere but on the schematic itself?
Just wanted it to be a fun easter egg for people to find out that D2 is hardwired to D10 and D3 to D13??
big oof
Had the checkout backwards which lost any new translations.
Thanks @onyx hinge seems like I’m not alone here. But I’m unsure I have enough expertise yet to help out with improving the core code. But definitely there should be a better way. Thanks for the insights!
My guess is that it's related to the conversion from CP ticks to FreeRTOS ticks here: https://github.com/adafruit/circuitpython/blob/master/ports/esp32s2/supervisor/port.c#L146
I believe the FreeRTOS ticks are at the 1/10th of a second resolution so we'll also need to account for the remaining time.
Shouldn't you disable for the '833 here or does it fit for now?
This is the best option I can think of.
im pretty sure @xobs needs it
I thought so too but the "but" in the comment seems to imply it doesn't fit on '833.
ok this is by sean's request so we'll see what he says :)
The CIRCUITPY_AESIO ?= 1 is inside an ifeq that turns it on only for nrf52840. This is not obvious from the GitHub diff.
@xobs turned it on explicitly in the simmel/mpconfigboard.mk, but it's not on in the other '833 boards.
During the implementation of low power mode a couple of Discovery boards were mistakenly marked as having low power crystals, but actually only have DNP slots that require the user to install them. This resulted in these dev boards being unable to boot fully due to infinite loops on failure in some of the STM32 HAL functions.
This PR sets the Discovery boards crystal settings based on their manual data, which should help with the boot problems. Unfortunately, I don't have most of the Disc...
This makes sense in the normal (merge) case, for a developer who is not making translations.
Merged despite spurious failure on one build
@hierophect I've checked the 2 boards I have. The disco is fine, the nucleo is not correct. Could you give me details though about how to do a real low-power test so that I can be sure everything is fine.
The nucleo f746zg has a LSE crystal installed, but not a HSE.
I think it just grabs the 8MHz crystal from the STlink, like most ST dev boards, which seems to be identical as far as clock settings go.
the joys of systemd/udev/sysfs!
@raven canopy I am also working in that space. In my case, I believe it is not enabled in the UDOO Bolt kernel. 😦 I submitted an issue to change that.
That's true...but it does have a crystal installed. X2
source: https://www.st.com/en/evaluation-tools/nucleo-f746zg.html (and my eyes..as I look at the board)
@k0d right now we're just looking for correct boot behavior. See here: https://github.com/adafruit/circuitpython/issues/2952
On the Nucleo-F746G I have no issues with booting when I try the 5.4 beta or the most recent S3-build.
I am also working in that space. In my case, I believe it is not enabled in the UDOO Bolt kernel. 😦 I submitted an issue to change that.
@timber mango it seems a strange approach to pipe the GPIO solely through the ATMega on that board. but, i guess it does allow them to skip things like devtrees/etc.
Add support for the GigaDevices GD25S512MD 64 MiB flash chip. This chip is pin-compatible with the Macronix MX25L51245G added in https://github.com/adafruit/circuitpython/pull/2731 .
Additionally, the GigaDevices GD25S512MD uses multiple status bytes whereas the Macronix uses only a single status byte, so it gave me more opportunity to more thoroughly test the fix involving CMD_READ_STATUS2: https://github.com/adafruit/circuitpython/pull/2847 .
I believe all of the chip parameters are c...
boot_out.txt using this patch: Adafruit CircuitPython 5.4.0-beta.0-402-g5cd6bb4d5-dirty on 2020-05-29; BDMICRO Vina d51 with samd51n20
@onyx hinge @lone axle I rolled a new text label functions to avoid any tileGrids and write to a display-sized bitmap buffer. Speed is similar but memory is way reduced. I call that a win. I’ll create an issue post the three simple functions I am using. Maybe it will give others a starting point to improve from.
@mental nexus neat! you might also consider turning it into something that can go in Community Bundle.
@raven canopy Even more strange, on the UDOO Quad, all the external pins are connected to both the main CPU and the Arduino compatible chip. Personally, I think that is just asking for trouble.
@timber mango yeah. UDOOs are really interesting designs. more than i could do, so i don't mean to come off as critical. it just seems a headache to use outside of that constraint.
Thanks @onyx hinge for the encouragement. Clearly this is a pain point so maybe it can help make someone else’s life easier! I’ll read up on contributing to the family community libraries.
yeah. UDOOs are really interesting designs. more than i could do, so i don't mean to come off as critical. it just seems a headache to use outside of that constraint.
@raven canopy There are reasons I do not particularly like the UDOO Bolt, so I understand. It is so new that I do not think UDOO has done all they could for the initial release. I think they hurried it a bit to get it out. There are many holes that need to be plugged, especially for developers.
@mental nexus Cool! I look forward to playing around with it some.
Current status:
- cookiecutter PR needs review
- https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/99/commits (the original RFC pull request) is updated to match the changes for TestRepo, including the updated code of conduct file, and the correct licensing for the favicon.
This currently only checks for basic file hygiene, namely end-of-file and training whitespace.
This does not yet allow running REUSE, as there's a lot of files without
copyright information that need to be updated.
In order to reduce the memory usage of the label function (Adafruit_CircuitPython_Display_Text library), I created a library that uses a bitmap buffer for text writing. The textMap library and an example can be found here: https://github.com/kmatch98/CircuitPython_textMap @lone axle @onyx hinge
@mental nexus Nice! Looking into this now over some coffee
@lone axle coffee is a great idea! Here it is in action. It’s not going to be super fast but gets it the job done with less RAM.
Cool!
Had to tweak a few things to get it running on Edge Badge with the builtin screen but got it working now. It is fairly quick on there actually. Though right now some of the text is not on the screen since it's smaller.
On Edge Badge
same speed with the pink and teal boxes moved onto the screen
Looks good to me. For the NRF52840 I have about 65kB remaining. It looks like there is some memory leak per time through the while loop but seems to work comfortably for now.
In doing this I discovered that the builtinFont (terminalio.FONT) is structured differently than the BDF loaded fonts. The built in font is a fixed dimension font and seems to be designed for easy use with tileGrid. If you want to use terminalio.FONT we will have to adjust this library to accommodate it.
Could BDF fonts be easily converted on the fly to a terminalio.FONT format?
@timber mango I think it may be easier the other way around to convert the built in to the BDF style. The reason is that the BDF style handles proportional fonts (each glyph can be a different size) while the built in just has a fixed size.
I guess that is the price of proportional fonts. In that case, should not all fonts used be BDF style?
I’m unsure of the history of the built in font but the fixed fonts are good if you want to put it in a tileGrid.
I use fixed fonts almost exclusively (and terminalio.FONT extensively due to its low memory footprint) so that it's easy to align columns. (And have predictable text widths that don't depend on the letters used)
hey guys, sorry to interrupt. quick question of the topic, do you know if it is possible to execute two functions in the same time? Thanks 🙂
No, but you may be able to create the appearance of simultaneity by structuring the actions within timing loops.
Also, certain kinds of inputs can be buffered to be handled within a code loop as time permits (see: gamepad, pulseio, etc)
i just try to blink some led in same time (one on a strip and one on the Playground express...
is it possible to do that in Make Code ?
thanks @crimson ferry i will have a look!
Yep! Didn't mean to contest your correction about the 32k crystal, I mixed it up with another board. Working on testing locally.
@timber mango I've had good luck using generator coroutines
@kind river hi. Can you be a little more specific, i'm just a noob :/
I'll try to find the tutorial I used
😉 thanks. you tube reached the end of my abilities for the moment 😄
thanks i will have a look
@timber mango It's a bit complex if you are new to python. Feel free to ping me with any questions
sure will 😉
Does the rfm9x listen() function allow the radio to asynchronously receive and store packets, that I get later using receive() ? I am using an rmf9x M0 feather and the receive() method w/ a timeout. I really need the M0 to do other things, and wish my code wasn't blocked during the wait. I didn't understand the explanation for listen(), but I'm hoping it will help with my situation. I also wonder if the receive() parameter 'keep_listening' will help.
@rich merlin I don't think it will receive asynchronously exactly. But you can call in your main loop and it will return None after a timeout period if there is no message received. Then you can do some other work and eventually loop back around to check again.listen()
I do believe the library will "remember" the incoming message even if it comes while you are not actively in the middle of a call the message would get returned to you the next time you call listen() even if some time has passed since the message was actually sent/received. I'm not 100% certain though.listen()
Is there another place besides https://circuitpython.readthedocs.io/projects/rfm9x/en/2.0.0/api.html where I can find more details? Specifically where to learn the return types of these methods?
@lone axle your description of listen() matches what thought receive() did (or should do).
@rich merlin Ah, sorry yeah I think I confused those two sorry about that receive() is what it is called
that is the best place for docs. But there is also the Repo here: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x there are some examples in there that show how to use the library.
Without interrupts, there is no real way to not block. I hate to admit it, but the Arduino Radiohead library will work better for that. Also be aware that the feather M0 rfm9x will be very memory constrained under CIrcuitPython.
There has been some discussion of trying to add some interrupt support for such devices but it is a a ways off.
@solar whale I now see the keep_listening parameter to send() and receive(). And I see how those methods call listen() after they are done if keep_listening is true. So if I use keep_listening=true, then (I think) while my CP main loop is off doing other things, the radio will be putting the next incoming packet into the FIFO and will set rx_done. So when my CP loop comes around to receive() again, the method will return right away, returning the packet that came in while I was busy. Is this correct? If so, I'm happy.
@rich merlin I agree it should work that way in principle, but looking at the code, there may be a problem with that -- this line https://github.com/adafruit/Adafruit_CircuitPython_RFM9x/blob/master/adafruit_rfm9x.py#L863 will cause the Mode to be set to reset to RX and if I recall correctly, that causes the input FIFO to be flushed. I may be mistaken and need to review the datasheet. I recall experimenting with this in the past and I think this part should be revised to fix this. It seems to circumvent the whole purpose of "keep_listening". I will look into this tomorrow and see if I can verify the operation and possible workaround. Thank you for raising this. I will open an issue in the repistory to track this.
issue created https://github.com/adafruit/Adafruit_CircuitPython_RFM9x/issues/44 I am hopeful that hope this can be resolved quickly.
I may be confusing things -- In a quick look at the data sheet _ I don't see why there should be a problem, The issue may have been with switching between transmit and receive. It may well be OK as is. Please give it a try and let me know! I'll dig deeper into this tomorrow an report back.
@solar whale I see why you wrote the issue. I have a pair of Feather M0 with RFM95 cards and will try to write a test.
I have been wondering: What do expect would happen if more than one packet arrived before I called receive()? Which packet would receive() return? (first or last)?
Good question -- my thinking is that it will return the first since the FIFO pointer should be pointing to it. But that needs to be verified as well.
I have to go offline now, but it'll be fun to explore this ... thanks!
@solar whale I could not reproduce the issue. It is ok as is. I tested with each feather running CircuitPython 5.3.0 and library bundle 20200529, including version 2.0.0 of your library. I tried to make a test that would clearly show it working or failing by just looking at log file, but failed. So I made a transmitter send a packet every second, and the receiver do a receive every 5 seconds. The receive timeout was 0.2 secs. When keep_listening = True, the receiver got a packet every time, without waiting. Even when I killed the transmitter, the receiver would still get a packet one time after the tx was dead. With keep_listening=False, the receiver almost never got a packet (timeout still 0.2 secs).
@solar whale also from this test I found that when keep_listening is True, and multiple packets arrive between calls to receive(), then the most recent packet is returned.
@rich merlin Thanks for the test. I have run some as well and agree that "keep_listening=True" is working as intended. Sorry for the false alarm. I'm still trying to recall the issues I had in the past but it is good to know it is working OK now. As to receiving multiple packets .. so much for my instincts.... I have also confirmed your finding -- last packet received. It's always good to test 😉 I will close the issue I opened -- let me know if you run into any problems. Good luck.
FYI -- I was confused about how the received FIFO buffer was being used -- it is described in section 4.1,2,3 of this datasheet and only the last packet received is available. https://cdn-shop.adafruit.com/product-files/3179/sx1276_77_78_79.pdf thanks for getting me to reread this -- it's been awhile
The MakerDiary nRF52840 MDK won't run the HEX version of CircuitPython that's currently available for it, as it came shipped with a new UF2 bootloader. I tried using the HEX -> UF2 conversion script, but it didn't work. Is there something I'm missing?
in the Makefile -- the .uf2 is created here -- if requested https://github.com/adafruit/circuitpython/blob/master/ports/nrf/Makefile#L266 try uf2conv.py -f 0xADA52840 -c -o filename.uf2 filename.hex
hmm that does not work -- but python3 uf2conv.py -f 0xADA52840 -c -o filename.uf2 filename.hex does create a file
Converting to uf2, output size: 709120, start address: 0x26000
Wrote 709120 bytes to test.uf2
if they're shipping with the uf2 bootloader now, we'll need to update this to include .uf2s on release: https://github.com/adafruit/circuitpython/blob/master/tools/build_board_info.py#L55
@pseudo gale would you mind putting in an issue on github?
odd -- when I build the board locally it runs ```Create build-makerdiary_nrf52840_mdk_usb_dongle/firmware.uf2
python3 ../../tools/uf2/utils/uf2conv.py -f 0xADA52840 -c -o "build-makerdiary_nrf52840_mdk_usb_dongle/firmware.uf2" build-makerdiary_nrf52840_mdk_usb_dongle/firmware.hex
Converting to uf2, output size: 726528, start address: 0x26000
Wrote 726528 bytes to build-makerdiary_nrf52840_mdk_usb_dongle/firmware.uf2
but if I run uf2conv.py manually it won't accept -f ADA52840 -- but -f NRF52 seems to work...
Converting to uf2, output size: 702464, start address: 0x26000
Wrote 702464 bytes to test.uf2
Family ID needs to be a number or one of: SAMD21, SAML21, SAMD51, NRF52, STM32F1, STM32F4, ATMEGA32, MIMXRT10XX
[adafruit/circuitpython] Issue opened: #2982 New bootloader on nRF52840 MDK is incompatible with HEX
The MakerDiary nRF52840 MDK is now shipping with the UF2 bootloader. It no longer works with the CircuitPython HEX.
@xiongyihui Would you submit PR's to https://github.com/adafruit/circuitpython https://github.com/adafruit/circuitpython-org to update to .uf2?
@raven canopy done
@pseudo gale thanks!
Core repo update is here: https://github.com/adafruit/circuitpython/blob/master/tools/build_board_info.py#L55
I'd recommend changing to HEX_UF2 so that non-uf2 users will still get releases (for now at least).
Is there something I could do to try to fix this actions error or does it just need to wait a while for something else to happen?
What's the correct link for ulab documentation? https://learn.adafruit.com/ulab-crunch-numbers-fast-with-circuitpython/overview has https://circuitpython.readthedocs.io/en/latest/shared-bindings/ulab/__init__.html which 404s (I think it used to work) and that's also findable with DuckDuckGo. Google finds https://circuitpython.readthedocs.io/en/latest/autoapi/ulab/index.html which works. Is latter correct? Shall I put some feedback in for that guide?
Looks like that error went away on the next retry from a commit.
@simple pulsar that link got broken with the "stubs" work, I'll go fix it in the guide. In the future, you can report broken links in guides using the page itself.
(I'm sure you know that, saying it for the benefit of anyone else reading)
I don't need to do this but I've just noticed the // isn't supported on ulab. Was this considered? ```>>> ulab_sine2
array([0, 2057, 4106, ..., -6140, -4106, -2057], dtype=int16)
ulab_sine2 // 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported types for floordiv: 'ndarray', 'int'
On 5.3.0 on CLUE I'm seeing some strange behaviour with min/max in ulab on int16s. Either I'm doing something silly or this is a bug? ```>>> length=10
ulab_sine2 = ulab.zeros(length, dtype=ulab.int16)
ulab_sine2
array([0, 0, 0, ..., 0, 0, 0], dtype=int16)
for i in range(length):
... ulab_sine2[i] = int(math.sin(math.pi * 2 * i / length) * 32767)
...
...
...
ulab_sine2
array([0, 19259, 31163, ..., -31163, -31163, -19260], dtype=int16)
ulab.numerical.max(ulab_sine2)
-19259
ulab.numerical.min(ulab_sine2)
0
This is almost, but not entirely, a whitespace change.
"..." was missing or mis-placed in several places
The invalid syntax 'def f(self, ):' was used in several places.
Closes: #2976
There's something odd going on with ulab.numerical.min and ulab.numerical.max with the int16 data type. Example below from nRF52840-based CLUE:
Adafruit CircuitPython 5.3.0 on 2020-04-29; Adafruit CLUE nRF52840 Express with nRF52840
>>> import ulab
>>> import ulab.numerical
>>> length=6
>>> someint16s = ulab.array([0, 12345, 23456, -20_000, -30_000, 0], dtype=ulab.int16)
>>> ulab.numerical.min(someint16s)
0
>>> ulab.numerical.max(someint16s)
-20000
I'd expect `...
@v923z can you take a look?
Oh, I've not checked this on MicroPython. Perhaps this will end up in https://github.com/v923z/micropython-ulab - I hadn't thought about that.
@solar whale New problem with the rfm9x library is that it's too big for my poor little M0 feather. My project also need the gps library, which consumes ab 6800 bytes. The current rfm9x lib consumes 9500 bytes. With those 2 I am out of mem before I get all my own stuff loaded. When I use the previous rfm9x lib - which consumes 8300 bytes (1200 less) I can run (so far - I'm not done adding the code I need).
Sorry I'm just whining. I can't believe I'm counting bytes again like I had to 30 years ago. Too late for me to switch MCU.
you are using the .mpy versions, correct?
Yes, using mpy. Their size on disk is about the same as reported by gc.mem_free(). I called mem_free() before and after the import of the lib and printed the diff.
I wish I had something to offer - the M0 is really difficult and those are both big libraries. If you are not using the node addressing or "reliable" datagram you could get away with taking much of the new stuff out (there is one 256byte buffer) and a bunch of new code. There are probably some savings to be had with a careful scrubbing of the code. I have not done that.
but you will always be struggling with the M0 RFM9x
@rich merlin Why is it too late to switch MCUs? The M4 (SAMD51) should run everything the M0 (SAMD21) can, but much faster. You will also gain access to more libraries the M0 can not run.
@timber mango Because I'm a cheapo. Also because I'm using the m0 and LoRa combo feather. I didn't realize it's limits when I bought them.
@rich merlin If you can't switch MCUs, perhaps you can switch environments? All that stuff might fit nicely in the Arduino environment.
Heavy sigh. I guess I have to accept the results of my first experiment with CircuitPython: it's not right for this project.
@rich merlin This is why I am starting to prefer using breakout boards versus combination boards. I can connect a breakout to anything, but a combination board is not changeable.
The lack of concurrency in CP was also killing me. I was doing some wierd things just to make it look like it was doing concurrent things.
Heavy sigh. I guess I have to accept the results of my first experiment with CircuitPython: it's not right for this project.
@rich merlin I think it would be fine with the right MCU. 😉
OK so then I ask for advice: I have never used Arduino, and this was my first python anything. Should I try Micro Python or Arduino next?
@rich merlin Hopefully it's been a good introduction to the potential applications of CP and you will keep it in mind for the next project.
You will not get concurrency with Arduino either, but at least you do have interrupts.
For these boards, I would go to Arduino. -- that said, I have not tried using MicroPython on SAMD boards at all..
Geeze there's a lot I don't know about Arduino. I though it was 'c' and threads would just work.
Every computing environment and MCU combination has pluses and minuses to it. It is frequently quite difficult to pick two that can do what you need done.
Yep. So after this 10 minutes of discussion, I think I will clone the rfm9x library and try to squeeze it.
Not give up on CP or my hw just yet
Good luck! let me know if you run into problems -- be happy to help.
@rich merlin Do not forget to contribute any modifications back to the library. 🙂
do you need the node addressing or "reliable datagram' (ACK packets?)
While you are at it, i would also look at the GPS library -- may find some savings there as well.
you will need the mpy-cross tool to create .mpy versions -- no hope without that
@timber mango will do. @solar whale Is the a 'howto' for mpy-cross, and whatever, for making libraries?
looking
my dev i
my dev machine is a mac
should be fine.
the link above will get you the mpy-cross tool -- if you want to see the whole library contributing process go to the beginning of the guide.
thanks. Off I go. check in later
Have fun!
Hi there,
Does anyone knows how to create a list of array for different LED on strips on make code? It work on my playground express but not on the strip.
thanks
This adds the async def and await verbs to valid CircuitPython syntax using the Micropython implementation.
Consider:
>>> class Awaitable:
... def __iter__(self):
... for i in range(3):
... print('awaiting', i)
... yield
... return 42
...
>>> async def wait_for_it():
... a = Awaitable()
... result = await a
... return result
...
>>> task = wait_for_it()
>>> next(task)
awaiting 0
>>> next(task)
awaiting 1
>>>...
@timber mango you may want to post that question in the #help-with-makecode channel.
@solar whale i know but its been 2 days and no one answered me 😟
ah -- sorry to hear that -- I have never used makecode - so can not help. Good luck.
@timber mango I put a reference to some code in the other #help-with-makecode that may help
While we wait for the list of microcontrollers that are too micro to async, here's an example that shows how exception propagation is able to be handled in an async/await context.
>>> async def it_throws():
... yield
... raise Exception('ack')
...
>>> async def it_catches():
... try:
... await it_throws()
... except Exception as e:
... print('ah ha, I caught', e)
...
>>> task = it_catches()
>>> next(task)
>>> next(task)
ah ha, I caught ack
...
What is your fave edit/build environment? I'm trying VS Code because I'm used to Visual Studio. I'm wishing I could edit the adafruit_rfm9x.py file, then launch the python interpreter to show my mistakes. But of course VS code out of the box does not know about the other adafruit libraries. Do you know of a guide on IDE setup for building these?
I don't like the bar graphs, as the name of the top language is cut off, and there's nothing obvious that we can do about it.
I opened an issue with weblate about this: https://github.com/WeblateOrg/weblate/issues/3974
@solar whale well I guess it wasn't worth a try. I went to the previous version of the rfm9x library, that's 1200 bytes smaller. Still I ran out of RAM after adding a blinking LED. And I still need to add a PWM output.
So, I'm off to Arduinoville. Any recommendations for a starting point and/or a source of good reference material?
I'm having an issue getting CP to build. I followed all the instructions on the Adafruit site, but I'm running into this issue:
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
xargs: arm-none-eabi-gcc: No such file or directory
make: *** [build-makerdiary_nrf52840_mdk_usb_dongle/genhdr/qstr.i.last] Error 127
make: *** Deleting file `build-makerdiary_nrf52840_mdk_usb_dongle/genhdr/qstr.i.last'
I even tred installing gcc-arm-none-eabi manually without success.
Take control over your gcc binary path.
PATH=/github/gcc_arm/gcc-arm-none-eabi-9-2019-q4-major/bin/:$PATH make BOARD=feather_m0_adalogger TRANSLATION=fr -j 12 V=2
Thanks!
So on further examination, it appears that there are deeper issues with compatibility on my MakerDiary nRF52840 MDK. I tried converting it all sorts of ways into a UF2 for the new bootloader, but it did not take. I even tried older versions of CP. The device was able to flash an example blink code provided by the developer, so I know that it is functional. I'm stumped. Edit: Looking at the community pages for the device, I’m apparently not the only one having issues either.
@v923z can you take a look?
Yes. This is certainly odd, and should be fixed. Thanks for reporting!
And here's an async lib I threw together for this: https://github.com/WarriorOfWire/circuitpython-utilities/tree/master/budget_async
You can use it kind of like an asyncio event loop. This was really easy to put together; there is much opportunity for others to make better things.
It ties async/await to an event loop that you'd most likely call next() on in a tight while: True loop in your main application function. While in a coroutine you can await, you can await loop.sleep() a...
@APDevice I think you are using nRF52840 MDK USB Dongle.
@sommersoft Thanks for the hint. Will submit a PR later
@jepler This was a trivial error that was entirely my mistake: in certain cases, you can treat uint16/int16 on the same footing, but not here.
In any case, I have patched the code. https://github.com/v923z/micropython-ulab/pull/121 should fix the issue. If you agree, you can merge it into master. When pulling code into circuitpython, keep in mind that master contains the approx sub-module now, which you might not want to include on your end, so you have to unset the switch in ulab.h...
[adafruit/circuitpython] Pull request opened: #2986 include uf2 firmware for nrf52840 mdk usb dongle
The nRF52840 MDK USB Dongle has a new UF2 bootloader. Provide both Hex firmware and UF2 firmware for it.
#2982
@rich merlin I would definitely start here https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/setup?preview_token=IU2C_sI1Vkd78VJQTNxu1w with the Arduino setup for using the M0 RFM9x. This is not the simplest intro to Arduino! You should take a few minute to make sure you can load things like the "blink" sketch before going too deep into it. This will throw a lot at you if you are new to Arduino - setting up and installing libraries. The RadioHead Library has to be installed "manually" - that is not through the IDE's library manager. When you get to it, you can use either the v 1.62 link in the guide or just above that there is a link to get the latest version of the library from airspayce http://www.airspayce.com/mikem/arduino/RadioHead/ I have recently tried both and they both work. I'd recommend the latest version. Note: use the examples from the guide for your first tests rather than e examples from the libraries. The examples are tailored to the pinouts of the AdaFruit boards. Good luck -- if you have issues ask either in #help-with-arduino or in #help-with-radio depending on the nature of the problem.
After https://github.com/adafruit/circuitpython/pull/2685 PR, Spresense got stuck in function port_get_raw_ticks after startup. This PR fixes this issue and simplifies getting the number of ticks.
@solar whale can I ask you a favor 🙂
@gentle bronze sure!
I couldn't build circuitpython for esp32s2, it is my first time to build it. I am on ubuntu 18.04, you are the linux user I know did it ```cpython/ports/esp32s2$ make V=1 BOARD=espressif_saola_1_wrover all
IDF_PATH=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf cmake -S . -B build-espressif_saola_1_wrover/esp-idf -DSDKCONFIG=build-espressif_saola_1_wrover/esp-idf/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;boards/espressif_saola_1_wrover/sdkconfig" -DCMAKE_TOOLCHAIN_FILE=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/tools/cmake/toolchain-esp32s2.cmake -DIDF_TARGET=esp32s2 -GNinja
CMake Error: The source directory "/home/hathach/Documents/adafruit/cpython/ports/esp32s2/build-espressif_saola_1_wrover/esp-idf" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Makefile:215: recipe for target 'build-espressif_saola_1_wrover/esp-idf/config/sdkconfig.h' failed
make: *** [build-espressif_saola_1_wrover/esp-idf/config/sdkconfig.h] Error 1
It complains there is no CMakeLists.txt in the build-espressif_saola_1_wrover/esp-idf Do I need to run any other setup command first ?
did you run install.sh in esp-idf? then in esp-idf run . ./export.sh
I already did that with the other master of esp-idf that I clone directly from espressif https://github.com/espressif/esp-idf
I have to re-run the `. ./export.sh' every time I start from a new terminal session
hmm, maybe I need to do in the submodule as well, let's me run it again 🙂
it makes no difference 😦
I could run idf.py just fine in the terminal, but runing the make command still complain the the missing CMakeLists.txt
if you type 'env' do you see all thsi in your PATH ```PATH=/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/components/esptool_py/esptool:/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/components/espcoredump:/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/components/partition_table:/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/components/app_update:/home/jerryneedell/.espressif/tools/xtensa-esp32-elf/esp-2020r1-8.2.0/xtensa-esp32-elf/bin:/home/jerryneedell/.espressif/tools/xtensa-esp32s2-elf/esp-2020r1-8.2.0/xtensa-esp32s2-elf/bin:/home/jerryneedell/.espressif/tools/esp32ulp-elf/2.28.51-esp-20191205/esp32ulp-elf-binutils/bin:/home/jerryneedell/.espressif/tools/esp32s2ulp-elf/2.28.51-esp-20191205/esp32s2ulp-elf-binutils/bin:/home/jerryneedell/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/bin:/home/jerryneedell/.espressif/python_env/idf4.2_py3.8_env/bin:/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/tools:/home/jerryneedell/bin/gcc-arm-none-eabi-9-2019-q4-major/bin:/home/jerryneedell/.local/bin:/home/jerryneedell/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
IDF_TOOLS_EXPORT_CMD=/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/export.sh
IDF_TOOLS_INSTALL_CMD=/home/jerryneedell/projects/circuitpython_master/ports/esp32s2/esp-idf/install.sh
let me make sure it still works here
make BOARD=espressif_saola_1_wrover clean then make BOARD=espressif_saola_1_wrover
here is my env IDF_TOOLS_EXPORT_CMD=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/export.sh IDF_TOOLS_INSTALL_CMD=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/install.sh IDF_PATH=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf PATH=/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/components/esptool_py/esptool:/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/components/espcoredump:/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/components/partition_table:/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/components/app_update:/home/hathach/.espressif/tools/xtensa-esp32-elf/esp-2020r1-8.2.0/xtensa-esp32-elf/bin:/home/hathach/.espressif/tools/xtensa-esp32s2-elf/esp-2020r1-8.2.0/xtensa-esp32s2-elf/bin:/home/hathach/.espressif/tools/esp32ulp-elf/2.28.51-esp-20191205/esp32ulp-elf-binutils/bin:/home/hathach/.espressif/tools/esp32s2ulp-elf/2.28.51-esp-20191205/esp32s2ulp-elf-binutils/bin:/home/hathach/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200420/openocd-esp32/bin:/home/hathach/.espressif/python_env/idf4.2_py2.7_env/bin:/home/hathach/Documents/adafruit/cpython/ports/esp32s2/esp-idf/tools:/home/hathach/.local/bin:/home/hathach/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/SEGGER/JLink:/home/hathach/opt/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/9.2.1-1.1.1/.content/bin:/home/hathach/opt/xPacks/@xpack-dev-tools/riscv-none-embed-gcc/8.3.0-1.1.1/.content/bin:/home/hathach/ti/msp430-gcc/bin:/home/hathach/ti/MSPFlasher_1.3.20:/home/hathach/Applications/fomu-toolchain-linux_x86_64-v1.5.5/bin:/home/hathach/Applications/cov-analysis-linux64-2019.03/bin
works OK for me.
not much luck for me, I am on current tip of master
yes I am as well -- I am on Ubuntu 20.04 -- also I did not clone from espressif -- i did the install from the submodule in the master repository
I think there are some configurations set by scott in the repositiry.
I just run the install.sh and export.sh in the submodule, all the PATH is currently set to the submodule idf, I guess it would be fine. hmmm 🤔
ah, what is your cmake version mine is 3.10.2
I was just going to ask -- dis you update cmake https://docs.espressif.com/projects/esp-idf/en/stable/get-started/linux-setup.html
jerryneedell@jerryn#2399eedell-ubuntu-macmini:~/projects/circuitpython_master/ports/esp32s2$ cmake --version
cmake version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
ans all the other tools
thanks, let's me try to update it first, 18.04 latest is only 3.10
good luck!
yeah @solar whale it builds now, my cmake is too obsolete 🙂
yay!
sorry for the wait, my internet speed is a shame 🤣
no problem -- glad it is working.
btw, I think there is a typo here https://github.com/adafruit/circuitpython/blob/master/ports/esp32s2/Makefile#L215
-DCMAKE_TOOLCHAIN_FILE=$IDF_PATH/tools/cmake/toolchain-esp32s2.cmake should be
-DCMAKE_TOOLCHAIN_FILE=$(IDF_PATH)/tools/cmake/toolchain-esp32s2.cmake
hmm -- it works as is for me, but I agree with your change.
yeah it works cmake -S . -B build-espressif_saola_1_wrover/esp-idf -DSDKCONFIG=build-espressif_saola_1_wrover/esp-idf/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.defaults;boards/espressif_saola_1_wrover/sdkconfig" -DCMAKE_TOOLCHAIN_FILE=DF_PATH/tools/cmake/toolchain-esp32s2.cmake -DIDF_TARGET=esp32s2 -GNinja
but the macro is not correct, the $ swallow the I in IDF
maybe it is not matter anymore
apparently, but it should be fixed -- did you try it with the correction?
the build is still cloning .... idf submodules. I will leave it to complete first, then edit and retry.
Has anyone used the BLE code with more than one Advertisement type in start_scan ? I have two CPB's chatting between themselves with ads and one sometimes goes deaf. I'd normally suspect my code but it's the same code on both and from a few runs if i just listen for Advertisement then it works. Both 5.3.0. One happens to have a Gizmo attached. I'm about to check/refresh libraries...
@solar whale it is still cloning 🤣 , I will go out, and upate the result with edit make file later on
Either the call to board_init() should remain, or board_init() should be removed everywhere in this port.
board_init is called here: https://github.com/adafruit/circuitpython/blob/47efd595fce11240f92efecf768800e8d81fa702/main.c#L437
Why should we call this function twice?
We can now rely on weblate to regularly update the individual language files from the template, so "make translate" only needs to update the template file circuitpython.pot.
This is advantageous because updating the other files in locale/ was a frequent source of merge conflicts; resolving the conflict incorrectly was something that could easily occur (and did).
Testing performed: that "make check-translate" finds missing translations, that "make translate" only updates circuitpython.po...
This quiets two diagnostics I got when running make stubs:
.../setuptools/dist.py:454: UserWarning: Normalizing '5.4.0-beta.0.dev.407+g47efd595f' to '5.4.0b0.dev407+g47efd595f'
package init file 'circuitpython-stubs/__init__.py' not found (or not a regular file)
It's my mistake, thanks. This was moved in 100409961aa32e84810d6c86309e66277b4ea902 but the fix was not applied to cxd56 port.
Translations update from Weblate for CircuitPython/master.
At 100409961aa32e84810d6c86309e66277b4ea902 the responsibility to call board_init() was moved to main.c, so it appears litex port is calling this function twice.
This gets us
- the new "approx" submodule
- the new "equal / not_equal" predicates (since we can't do
array == arraydue to technical limitations) - vectorise() for vectori(s/z)ing arbitrary Python functions with reasonably good performance
The specific submodule ref is in a pending PR https://github.com/v923z/micropython-ulab/pull/122 so it should not be merged while that PR is not resolved.
This gets us
* the new "approx" submodule * the new "equal / not_equal" predicates (since we can't do `array == array` due to technical limitations) * vectorise() for vectori(s/z)ing arbitrary Python functions with reasonably good performance
This is definitely vectorize(). Since it was an original numpy function, I stuck with the American spelling:)
The specific submodule ref is in a pending PR [v923z/micropython-ulab#122](https://github.com...
Looks like this doesn't work on the CI builder.
The specific submodule ref is in a pending PR v923z/micropython-ulab#122 so it should not be merged while that PR is not resolved.
The sub-module itself has been in master for approx. (pun intended) two weeks now.
Overloaded terms. I mean to say, the git submodule ref for extmod/ulab is in the non-merged PR v923z/micropython-ulab#122.
Has anyone been able to attach an esp32 s2 to a Segger Jlink with OpenOCD? I tried this weekend and it just gave me an error trying to connect to the jlink device.
Does J-Link support espressif chips?
https://www.esp32.com/viewtopic.php?t=7097 seems like it?
Espressif ESP32 Official Forum
I haven’t had any luck though.
Hmm, not sure if this one just kind of fell through the cracks.
[adafruit/circuitpython] New comment on issue #2952: Hang on startup for the STM32F756 or SAMD21G18A
I'm also unable to replicate on 5.4. If you're using an old build, it might be related to #2866. In any case, I've modified the crystal settings in #2979 - if 5.4 still isn't working for you, you could give it a shot.
Closing for now since we aren't able to reproduce it, and it seems like the Atmel problem is possibly a custom board layout issue. Please do feel free to update though if you continue having any problems on the STM32 boards, we're trying to work out the kinks in the new low p...
@tulip sleet I have a live case of file corruption on one device out of three where the host says they are all the same and the devices. I tranferred the file off by printing out the bytes() and I can see it's corrupt on a 128byte boudary (not a 512 one). I put some details in latest post in https://forums.adafruit.com/viewtopic.php?f=60&t=165721 - anything more I should do to capture debug info before I try ejecting the drive on Windows host?
@Hierophect#2551 Not sure what you're doing with this PR, what's wrong with the LSE on H7/F7?
@k0d @tannewt Unfortunately, it looks like I can't mess with the settings on the F7 or H7s without messing up their boot behavior. I thought it was just the Nucleos after my first round of testing but now I'm having issues on the H746 discovery as well.
What these boards need is a full implementation of the low power domain for the H7 and F7. I can work on that this week but for now I've made a TODO comment for each of them so this can at least still be submitted as a hotfix for the Disco...
@k0d Right now, the new low power code in port.c has some caused problems with certain combinations of settings that cause boards to fail to boot if their oscillator settings don't match the actual board or the settings in clocks.c. Specifically, each board using an external LSE needs to have the backup domain configured properly or it won't exit the boot stage. I tried to make the system cleanly fall back to an internal oscillator if it fails, but my testing is showing it isn't working as ...
Changes look OK, CI passes. No actual testing done.
@simple pulsar are you doing an eject after each Windows Explorer copy? The host's view of the filesystem does not necessarily reflect reality; it reflects the host-side cached copy of the filesystem. If the data hasn't been completely written to the device yet, the host doesn't know that. So a disturbance (like a reset) on the device side could lose data.
I was wondering what the best way to submit a feature request for Circuit Python? I'm assuming GitHub, but still a noob with GitHub.
@tired cloak Just file an issue via https://github.com/adafruit/circuitpython/issues/new. You might want to search the existing issues to see if the request has already been raised.
Do any of your examples work in both the modified CircuitPython and in Python 3? I was not able to modify your examples to work in both interpreters.
@tulip sleet thanks!
@simple pulsar checking checksums on the host side doesn't really help because it's not reality, it's only the host's view. It can take up to 90 seconds for Windows to write to a FAT12 device if you don't Eject.
@tulip sleet I've had it broken for about an hour now
Are there any counters on the CP's usb side of things to check for errors/weirdness? (5.3.0 on CPBs)
@solar whale I still hit another link error 😓 ```LINK build-espressif_saola_1_wrover/firmware.elf
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libcoexist.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libcore.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libespnow.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libmesh.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libnet80211.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libpp.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/librtc.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libsmartconfig.a: No such file or directory
xtensa-esp32s2-elf-gcc: error: esp-idf/components/esp_wifi/lib/esp32s2/libphy.a: No such file or directory
Makefile:263: recipe for target 'build-espressif_saola_1_wrover/firmware.elf' failed
make: *** [build-espressif_saola_1_wrover/firmware.elf] Error 1
@simple pulsar no counters, there are sanity checks. I would say that the filesystem might have gotten corrupted at some point, and the best thing to do now is just storage.erase_filesystem() to get a cleanly formatted filesystem. If it repeats on this particular board I would wonder about whether there is some failing flash. We don't verify the writes to flash
No; Micropython implemented the async verb as producing a generator. Python 3 uses a coroutine instead. The apis are not the same.
This impacts developers of "nuts and bolts" features, like that budget async lib, but it should not impact regular use. I.e., if you have a suitable concurrency lib in your project, you just use it and can choose to write methods with async/await.
I'm aiming to help us get mileage on the syntax, not specifically to Solve The Problem universally....
What's the block size for flash writes? The corruption is a very specific small part and it's not 512 aligned
Weekly meeting is in about 30 minutes. You can find the document at https://docs.google.com/document/d/1LccVESiE1uFUrLv87Tp923LgrxHQgldFc26DX2QiAjo/edit -- if you plan to be "in" the voice chat but will not be speaking, please add your name in alphabetical order in two places, with "(lurking)" behind it. This is a big help.
As always, if you have notes that you would like us to read during the meeting, you can add those -- just put (text only) next to them.
@patent elbow I'd like to figure out the jlink and openocd stuff. I put a 2x5 on my feather saola board connected to jtag
It would be nice if anything that would normally go to serial could be set up to log automatically to the SD card.
For example, I've got a PyPortal, and really spotty internet. It seems to get hung up once a day, except when I leave a serial terminal watching it. If I know where and why it was hanging I'd be able to code around those issue to make it more reliable. (The Weather Station code from the PyPortal Adabox.)
If we could have anything that would normally go to serial also go to ...
@patent elbow I'd like to figure out the jlink and openocd stuff. I put a 2x5 on my feather saola board connected to jtag
@slender iron Me too...my boards are a little delayed, but hopefully they'll come in a day or 2.
Good afternoon -- happily lurking today, updated the doc.
@simple pulsar on samd21, the erase size is 256 bytes; the write size is 64 bytes
Rats -- dragged back to former day job for a meeting -- will have to miss today's CP weekly -- nothing to report -- have a great week all!
It's a CPB btw
Anybody want to do mic or video checks? Now's a great time!
can't join today but y'all are all cool, just thought you should know.
@simple pulsar were you using 5.3.0 or 5.4.0?
5.3.0
on nrf, flash page size is 4k
@ivory yew hate to be emotionally needy, but i demand you rearrange your life in order to accomodate the meeting time, because it's nice to get updates from you.
Lurking today
[1:55 PM]
Are you subscribed to the Python on Microcontrollers newsletter? Go to adafruitdaily.com and do so for a once a week spam free email
Shouldn't there be general chatter on the sound channel?
lurking
Nobody's talking at the moment
Howdy Kattni and everyone!
now they are
Lurking some of the time
cue technical difficulties
Lurking (as usual)
i heard ya\
Lurking
I can see Kattni
I see both of you
i see both of you
It is switching between you two
now Scott, now Kattni, now Maker.... seems that whoever is talking has the scene
[still seems discord needs to work out the bugs --- in the popout, it works fine. in the floating box, it's the highest alphabetically]
lurking
and @onyx hinge -- your fears are confirmed, your levels were a bit low just now 😦
Try unplugging your 5GBioShield usb stick
@onyx hinge it's not clear it's your headset mic that's picking up
ooo, good point @tulip sleet -- @onyx hinge are there any other possible audio devices? it did sound really far away, like a built-in mic in the webcam
[i learned that the hard way with logitech c920]
Lurking
Lurking today
Happily lurking, but occasionally here in chat 🙂
New lurker!
(I restarted discord so all audio bets are off, it seems)
(but in the 'test' page if I test my mic and touch the foam ball on the boom mic it is scratchy so it has to be that one)
@thick roost if you want to participate in the meeting, let us know. Otherwise I'll mark you as "lurking", feel free to hang out and listen.
ok i wonder and came for listening 🙂
@raven canopy lurking?
nope. just behind... 😄
lurking now that my work call ended
https://summer.hackclub.com/ https://blog.adafruit.com/2020/05/28/summer-of-making-hack-club-github-is-sponsoring-50k-worth-of-hardware-grants-for-adafruit-hardware-hackclub-githubeducation-sam_poder/
Hack Club
Join Hack Club’s Summer of Making: 6 weeks of professional mentorship, $50k in GitHub hardware grants, & an unparalleled online community. Starting June 18, ages 13–18.
johnkeefe.net
I'm incredibly lucky to be both healthy and able to work from home during this coronavirus crisis. That means I spend large chunks of my day on video calls.
As a courtesy to my family, all of...
Is @mental nexus present? He was trying to come to discuss BLE keyboard input or anything that can help the CyberDûck https://hackaday.io/project/171269-cyberdck-a-circuitpython-anatidae#menu-description
@half sedge I’m here to help to support you with BLE HID inputs if you want to cover in the weeds.
💯
That's an awesome LED wall
It's a ray of bright light during these dark times.
@icy forge let me know if you have hug reports or status updates and we'll come back to you
@mental nexus wait, you created cyberduck?
Yep, quack quack!
..thats my fav. SFTP client
That’s why I added the Û since I didn’t want any letters from them.
👍
Sorry if I confused you @prime flower , I’m not that cyberduck maker, just the person that made the plastic yellow CircuitPython computer duck.
thanks for taking notes kattni
@inland tusk hoping to get it done this week
@patent elbow I'd like to figure out the jlink and openocd stuff. I put a 2x5 on my feather saola board connected to jtag
@slender iron I went ahead and ordered the ESP-Prog from DigiKey. I was looking into the time.sleep() bug on eps32 taking at least a second, but without a debugger I didn’t get much farther than figuring out how Python is calling into the Hal for the sleep methods, but nothing seems esp32 specific so currently perplexed.
@onyx hinge I should say it's wrapped up for the moment. Maybe I'll be able to get back on it soon.
@gilded cradle nothing's ever truly finished
@slender iron I'm in the voice chat in case people want to go in the weeds on async. Not specifically planning to talk but I'm here 🙂
@gilded cradle I was curious and wanted to ask -- will the new RPi with 8gb ram be of benefit to Blinka?
👍 will look at it later today
I'm not sure @modern wing. It seems to work fine on the 4GB model so far.
@onyx hinge there's still a number of open issues for displayio: https://github.com/adafruit/Adafruit_Blinka_Displayio/issues
Stacking headers seem to be working as 'legs'...unexpected feature
yep. there are a couple of 2-in-1-out headblocks floating around, and it turns out the Marlin firmware has hooks for "single nozzle" dual filament print. it basically sets the firmware so that it is a dual nozzle printer with 0,0 distance between the two nozzles, and it makes it okay with only having one nozzle temp sensor
@tiny oriole Are you designing your own backend for weather alerts or using NWS?
- the memory isn't currently supported though
but why? What's the benefit? Does it have separate feeds for each filament? It actually funnels both into the same nozzle?
You can mix colours.
ill be caching the Alerts api from NWS on a relatively short regular interval, and then the clients in the field will hit MY server as fast as they need to. That way the bulk of the load hits ME, not them
ouch
@tiny oriole neat! Lmk if you like the NWS API or switch to something else (looking to migrate Adafruit IO's weather api by e.o.y), also keep me updated i love weather projects
@ionic elk You can mix even RGB: https://www.geeetech.com/geeetech-a20t-3in1out-mix-color-3d-printer-p-1108.html
geeetech.com
I like this. Do you think I should buy it?
Using @pimoroni Keybow mini with an @adafruit CLUE running @CircuitPython with the help of Bit:2:Pi from @4tronix_uk.
Here the 3 buttons are Mute, Vol- and Vol+.
I just simplified the code from John Park that did this for the Keybow and ItsyBitsy.
code: https://t.co/YaPaL7N...
Now BLE portable keyboard with:
CLUE (@adafruit)
- But:2:Pi (@4tronix_uk)
- Keybow mini (@pimoroni)
This is a continuation of @johnedgarpark experiment with ItsyBitsy M4 and full size Keybow: https://t.co/G1oa5nPGAh but without soldering.
Source code: https://t.co/0dteJtSw6...
@tiny oriole neat! Lmk if you like the NWS API or switch to something else (looking to migrate Adafruit IO's weather api by e.o.y), also keep me updated i love weather projects
@prime flower it's actually not that bad, i really like it, although sometimes it fails to reply, or doesnt reply with fully qualified json, which i havn't fully tracked down if its my fault or their fault yet.
new 64-bit Raspberry Pi OS: now they do this... 😄
@ionic elk I'm open to test stuff on stm32 this week if you need.
Maybe we are missing low power board? One without any LED on by default and such thing.
@lucid solar That'd be super! I'll be working on stuff that needs a lot of cross board testing but I'd appreciate your eyes on the F7 boards you've got!
Your product has a user accessible USB plug which appears as a CIRCUITPY drive when plugged in.
Metro and Grand Central form factors expose more pins
I notice the CircuitBrains does bring out D-/D+ as pins
so it supports USB, just doesn't have a connector
USB plug can be modified to a place where you can connect USB.
What if there was a Serpente without the USB port?
"CircuitPython-Ready"
If you had a breakout with USB in your store, that would be great too (assuming you want to sell it)
Is there another "thing" that exists to connect this to micro-USB?
@simple pulsar I didn't find one for CircuitBrains Deluxe, no
Deluxe M4 too https://circuitpython.org/board/circuitbrains_deluxe_m4/
I mean for any given board you could just use one of these:
I was thinking about these for the STM32 Nucleo boards, which only expose native USB over the pins
"CircuitPython Pro"?
as a general board branding...for boards without easily accesible USB?
essentially an NRF socket
That'd apply to boards like the Nucleos which I would hesitate to call "pro" material. That word carries a lot of implications
like teensy4.1 for the host usb I guess
I need 16 GPIO on an nRF52 to make a Commodor 64 keyboard.
@thorny jay https://www.adafruit.com/product/4481 has 21 GPIOs
(there's one in my keyboard right now .. er no, it's an itsy bitsy m4 but only using 20 I/Os)
@idle owl I'll hand it back to you for wrap-up
It would also be neat if we could use a form of https://docs.python.org/3/library/code.html (oops too bad we used the name 'code.py')
Do the BLE keyboards do both?
that's a good question. I'm not sure.
Be safe y'll
Thank you!
Thanks all
Thanks
yay see you all around!
I need to drop off. Later all.
bye
I'm going to drop off as well. Later
Thanks for considering new features in the weeds today. Definitely understood on priorities. Keep up the good work everyone!
@jepler There are still some unresolved comments above (alphabetization and "not bitbangio.SPI")
@fathom lava any idea when kattni's hello blink show will be posted?
[adafruit/circuitpython] New comment on issue #2993: Have important \(serial\) things log to SD card
@jepler Food for thought as you do SD card work. This is a good, long-term idea.
@WarriorOfWire Thanks for making a PR for this! It's nice to see a PR proposal.
I don't want to introduce an async API that is incompatible with CPython because then code will be built on top that we'd have to break later. CPython compatibility also means libraries can be developed and tested in CPython too.
I know MicroPython has been doing a lot of asyncio work recently. Do you know if they've switched away from generators and are now CPython compatible? It's been a while since we mer...
Fixed by https://github.com/adafruit/circuitpython/pull/2986 and will be on the website with the next 5.4.0 beta release.
Does the whitespace change leave one blank line at the end of the file? I think we tend to.
Looks like some test outputs were changed and broken. They'll need to be exempted.
@Flameeyes Thanks for this work! I've merged both of these PRs and replied on the CircuitPython pre-commit PR.
@slender iron what is the best way to crash for a clock fault, like timing out the LSE setup? It feels like safe mode isn't really a good fit, since most of the time an LSE fault will prevent USB from even enumerating.
Why can't we do == and !=? We shouldn't introduce a new API just because we can't match MicroPython or CPython.
@ionic elk switching to the LSI makes sense to me. is that possible?
I'll try and make that work yeah
It's been failing with the setup so far but I'm checking out how Cube does it
if that doesn't get usb we can think about safe mode + led flashes
The annoying thing is that it tends to work if you have a working version that you change without power cycling, but then fails when you reset power.
equal and not_equal are in numpy. https://numpy.org/doc/stable/reference/generated/numpy.not_equal.html
However, on some more full implementations of Python, == and != can be used for this functionality as well (I think there may be a minor difference in how non-finite values are handled)
ya, the crystal stuff usually only starts on "power on reset" since it can be slow
Thanks for the update!
@onyx hinge need me to update the translations for the ulab update?
@slender iron it's actually not just power on reset, but literally full power cycling, because of the backup domain
resetting from a debugger won't break things but actually unplugging and replugging will
hrm, I thought power on reset meant "reset when the power turns on"
right, the debugger does a different type of reset
2979 doesn't do a lot other than fix a startup bug for the F4 discovery
I had to switch a bunch of changes to "todos" because they were breaking boot
it's the basis of a new LSE fix PR I'm working on rn
I'll probably do beta.1 in the next hour or two so I can merge it and you can follow up later
ya sounds good
kk, I have a couple PRs to poke that I want to get in too
Thanks for the update!
@onyx hinge fyi I updated 2992 through the github UI so pull before editing locally
This is a good interim fix for these boards while we sort out the crystal init. Merging for the next beta. Thanks!
@tulip sleet I drew a picture to make it more obvious what got corrupted: https://forums.adafruit.com/viewtopic.php?f=60&t=165721&p=814231#p814231 - it's rather strange, it looks like 44 (I corrected this from 40) bytes moved around and one other solitary 8 byte lump
I know MicroPython has been doing a lot of asyncio work recently. Do you know if they've switched away from generators and are now CPython compatible? It's been a while since we merged so upstream may have already evolved. If that's the case, we should consider merging in upstream (a large task but this would be another reason to.)
It's still backed by yield_from which [uses iter and yield](https://github.com/mi...
It would also be neat if we could use a form of https://docs.python.org/3/library/code.html (oops too bad we used the name 'code.py')
@onyx hinge Hey, there is your name on this code: # Inspired by similar code by Jeff Epler and Fredrik Lundh.
@simple pulsar I just took a look. That's strange, and I can't think of something that would account for that, unless it were that the file you were editing changed length by that much in the middle, and the write to update the data was incomplete in some way.
I looked into this again today and it simply can't be done easily. My changes are here: https://github.com/tannewt/circuitpython/tree/arduino_nano_atecc
I've also opened a PR to add a note on circuitpython.org about it. https://github.com/adafruit/circuitpython-org/pull/487
Images automagically compressed by Calibre's image-actions ✨
Compression reduced images by 63.1%, saving 19.81 MB
| Filename | Before | After | Improvement |
|---|---|---|---|
assets/images/boards/large/8086_commander.jpg |
118.10 KB | 108.46 KB | -8.2% |
assets/images/boards/large/aloriumtech_evo_m51.jpg |
141.23 KB | 54.76 KB | -61.2% |
assets/images/boards/large/avnet_iiot_gateway.jpg |
... |
Merging for inclusion in the next beta. Will revisit with background rework.
The brownout level is set quite high (2.77V) too soon after POR release on fast chips with slow ramping supplies.
An issue was encountered when testing the PoE-FeatherWing with the Adafruit Feather M4 Express. It would continuously go into safe mode right after boot when connected to PoE. My theory is that as the PoE power is still ramping up, the chip comes out of POR and starts to execute code. It reaches port_init before the inp...
I know MicroPython has been doing a lot of asyncio work recently. Do you know if they've switched away from generators and are now CPython compatible? It's been a while since we merged so upstream may have already evolved. If that's the case, we should consider merging in upstream (a large task but this would be another reason to.)
It's still backed by yield_from which [uses iter and yield](https://github....
There were two main problems
- word_buffer was being filled as though with unsigned samples, but during mixing all samples are kept in signed mode
- If the first buffer was stopped, the voices_active flag got set anyway, even though the output buffer wasn't initialized yet, so the samples were mixed with indeterminate data
We also cover the case where no buffer was playing, and ensure the output buffer is filled.
This now works much better. Tested on neotrellis m4 playing back 4 mp...
@slender iron thanks for doing the ulab translations update. I was at my local hackspace's virtual weekly meeting
thanks for the merges
@thorny jay scary to recall, but I was very active in comp.lang.python and the python-dev mailing list in the 90s, though my daily interest had waned by 2000.
I wonder why weblate is a "first time contributor" every time
Asyncio is a pretty complex topic and there's been a lot of work done on it in MicroPython over the years. Support for coroutines via generators was done for efficiency and for the most part users will not notice any difference here. Our uasyncio module is largely CPython compatible and I'd suggest you rebase/merge v1.13 of MicroPython (once it's released, should be soon) as just use that as-is.
@dpgeorge Thanks for the reply! What sort of efficiency? Execution speed or implementation. I'd much prefer a CPython compatible solution.
@tannewt why are you afraid by a fixed problem ?
Just add the right frozen modules to the iso and all works just great !
@fgallaire I'm not sure what you mean by it being fixed or "iso".
Should be fixed since #2992, please reopen and comment if not.
These calls were all moved into main.c, however this call was not
removed from litex. As a result, litex was calling board_init() twice.
This is currently not a problem, as fomu is able to be initialized
twice without issue, however future boards may have issue with this.
This fixes #2991.
Thanks for spotting this. I've created a PR that fixes this issue.
Mainly efficiency of implementation.
There are lots of layers involved with an asyncio implementation and we've prioritised making the user-facing layers CPython compatible. I don't think it's realistic (or necessary) to make everything CPython compatible, for example it probably requires reference counting to get task clean-up to work the same.
So I guess the question is: what does "CPython compatible" mean to you?
In making my weak scheduler PoC I saw that the lack of __await__ and send() on the awaitable object produced by an async function invocation were obstacles to compatibility at least insofar as writing unit tests. I think if I did not have to advance my tasks via next() we would be not too far off. I don't think a full CPython coroutine implementation is necessary here to get the overlap good enough that CircuitPython (limited) code works in a CPython (full) runtime.
To be clear though, it is really just that you can't implement an asyncio-api-compatible pure-python scheduler with this bare generator async/await. If I had written a CircuitPython-specific C module that did task scheduling (reeeeimplement asyncio or uasyncio) there would not be Python unit tests and the user-visible code would be compatible with CPython (modulo the library that would need to be built in blinka).
I consider this gap to be a temporary thing with a low-pain forward mig...
In making my weak scheduler PoC I saw that the lack of
__await__andsend()on the awaitable object produced by anasyncfunction invocation were obstacles to compatibility at least insofar as writing unit tests.
@WarriorOfWire are you able to provide/link to some code which uses __await__ and send() in a way that works under CPython but not MicroPython? send() should work.
@dpgeorge I have committed an error; I apologize for the needless sink on your time. Indeed send() works like CPython. Thank you for pointing out my error.
here is the diff that allows the (incredibly) budget scheduler to work under CPython.
Seriously Damian, thank you ❤️.
@dpgeorge while you're in the neighborhood - how would I implement a suspending function in Python using async/await that works both in CPython and Micropython?
Consider:
async def go_next_time():
yield
async def print_next_time(message):
await go_next_time()
print(message)
co = print_next_time('hello')
co.send(None)
co.send(None)
This works in CircuitPython but not in CPython. It is an abuse of the encapsulation, but I'm not sure what alternative means to t...
Why can't we do
==and!=? We shouldn't introduce a new API just because we can't match MicroPython or CPython.
Here is what you need for the ==, and != operators to work: https://github.com/micropython/micropython/pull/5593
I am not emotionally attached to the equal, and not_equal functions, so if you want, we can remove them. It was more like a temporary measure for circuitpython. As far as I remember, it was specifically a user request.
Right, figured out a way that works in both to provide a "sleep":
class TimedWait:
def __init__(self, duration):
self.duration = duration
self.start = time.monotonic()
def __await__(self):
yield from self._wait()
def __iter__(self):
yield from self._wait()
def _wait(self):
while time.monotonic() < self.start + self.duration:
yield
It's a little circuitous but it will do until we have a C module i...
@WarriorOfWire you can do __await__ = __iter__ in your class definition, instead of providing 2x identical functions.
So this bad Python scheduler serves as a proof that there is a subset of functionality that overlaps sufficiently with CPython to write a meaningful pure Python coroutine scheduler (which should not be the ultimate goal here imho).
The async/await syntax of my demo application has been unchanged through this tumult BudgetScheduler has remained API compatible even through misunderstan...
@WarriorOfWire you can do
__await__ = __iter__in your class definition, instead of providing 2x identical functions.
Yes you're right, this suffices for compatibility:
class _CallMeNextTime:
def __iter__(self):
yield
__await__ = __iter__
Hi, Is there or going to be any special bootloader for ESP32 S2 to make it ready for CircuitPython?
e.g. if I want to play or test CP with my SEOLA board how to start? (I know that it is still on development stage)
I had a lot of problems with brownout safe mode recently too, I started wondering if something in the recent changes with timers made it much easier to get into safe mode.
Is there a known issue with the current master build for the teensy 4.0 and 4.1 -- neither will boot for me?
@solar whale in a quick glance I don't see an open github issue like that
neither did I -- I'll do a few more checks then open one if not resolved.
The most recent builds for the teensy 4.1 and teensy 4.0 do nto boot for me
this fails to boot
jerryneedell@jerryneedell-ubuntu-macmini:~/projects/adafruit_github/teensy_loader_cli$ ./teensy_loader_cli -mmcu=imxrt1062 -w ~/Downloads/adafruit-circuitpython-teensy41-en_US-20200602-e889287.hex
this boost OK
jerryneedell@jerryneedell-ubuntu-macmini:~/projects/adafruit_github/teensy_loader_cli$ ./teensy_loader_cli -mmcu=imxrt1062 -w ~/Downloads/adafruit-circuitpython-teensy41-e...
the last build that works was:
adafruit-circuitpython-teensy41-en_US-20200519-916ca9f.hex
it starts failing with
adafruit-circuitpython-teensy41-en_US-20200520-0af5dd5.hex
@onyx hinge thanks -- found build when it first broke -- been awhile -- posted to issue
@tulip sleet The whole file thing is very puzzling. Given the sizes and damage it does look like some sort of editor meets broken file system. I save files to a network file system (samba) and then copy them to the devices. I think I'd bet money on it being Windows but it's strange given the sha256 were all the same, there must be a rare consistency issue with its cached view of the CIRCUITPY drive vs the writes to the CIRCUITPY drive. On the plus side, I've worked out a few tricks for checking and extracting files over the serial console.
What version of the bootloader are you using? I added code starting a v3.9.0 that waits until the voltage reaches the BOD33 setting, and then waits 100 msecs: https://github.com/adafruit/uf2-samdx1/blob/master/src/main.c#L216
@simple pulsar which editor are you using? And I wonder if your workflow could change to use a script that forces an eject or to use an editor directly to do the writing? I would like to have some editor plugins to write files to both CIRCUITPY directly and to a backup location, for safety
@tulip sleet That was trusty notepad++ saving directly to a samba mounted drive but there's clearly no non-bug explanation for the situation I had. Are you just pondering some workaroud to make things more robust?
@tulip sleet Not quite the same but have configured emacs to save its backup files (~ suffix) to a location on my home directory instead of the CIRCUITPY filesystem
@simple pulsar there is nothing we can do about the Windows delayed write problem. We've had communications that this FAT12-specific issue is being fixed, but I haven't seen it mentioned in the Windows Insider Previews release notes. The best we can do is force the writes to the drive. There is no way I know of to make Explorer or the DOS copy command to do that. It has to be something that specifically invokes a flush. Some editors do this automatically (Notepad++ does not), and I wrote a plugin for Atom to do it. I will say again that looking at things from the Windows side doesn't tell you what's on the board, just what it thinks is on the board. Yes, it could be a bug in the filesystem code, but it could also be something that caused them to get desync'd. Unless the drive disappears from Windows and then gets remounted, Windows will not know what's on the drive because the caching happens at too low a level.
@celest zenith I think emacs and other editors have enough hooks that we could have a "shadow" CIRCUITPY it writes to as well as the drive, or in general, write to two places rather than one. However, I looked for existing editor code and plugins to do this and didn't really find much.
certainly with emacs -- I've looked how hard it might be to do it in mu, but it didn't get much farther than reading code
i use emacs all the time, and if i were developing on windows, I might have written that code already 🙂
If memory serves it wouldn't be too hard to add a code to write files to a different location with mu but how to configure that backup location was not clear to me
I know this has been done with some Bluetooth devices that can now work with Circuitpython. My glucometer (for measuring sugar level) has Bluetooth. It would be really nice to be able get the raw data from the device so it could be used to calculate other stuff like A1C. What would be the best way to figure out what the device is sending and how to get the data? No rush on the answer but I just wanted to get this out there before I forget. I have only had about two hours sleep, so I hope I am making sense. 😉
@timber mango what device is that? many are using standard Bluetooth profile for glucose sensing — never tried to implement it myself though
(I've linked to the Bluetooth GATT for those in https://protocols.glucometers.tech/#standards-and-common-protocols for reference)
@timber mango we have looked into drivers for CGM's, but I don't have one to test with. Sometimes they are rather locked down, sometimes not, sometimes they are classic Bluetooth, not BLE. I think you will actually find a lot of (not CircuitPython) code for various CGM's on GitHub and elsewhere
@topaz quest there are lots of nice simple service defns by the Bluetooth standards folks; it's sad not more devices use them. I've only found heart rate monitors and bicycle sensors that actually use the standard defns
@tulip sleet I think I have at least one device that uses the standard GLP one, but it's a blood-sample meter, I don't know of any CGM actually using the standard profiles
(for any commentary on what I think of a certain encrypted reader device I'll just refer to the last post on my blog, obliquely, just in case.)
@topaz quest I have a Contour Next One glucometer. https://www.contournext.com/products/contour-next-one/
The Contour Next One smart meter and app combine remarkable accuracy with ease-of-use to benefit a broad range of patients living with diabetes.
@timber mango yeah that should be using GLP then 🙂
Ascensia is the only one actually publishing their programming docs nowadays: http://protocols.ascensia.com/Programming-Guide.aspx
Oh! Then maybe this will not be as difficult as I thought it would be. 🙂
the protocol is a bit of a mess, to be honest, but it's not impossible to implement
I've received a contributed driver for the USB part of the Contour devices
I chose a good meter, in spite of that then. 🙂
Neat! Thank you! Maybe doing what I want to do will not be such a difficult thing. I recently got a CLUE board.
I will look at all of this later. I have only had two hours of sleep, so I am going back to bed now. 🙂
enjoy rest! 😄 if you have glucometer questions feel free to tag me in, it's my hobby 😉
@gentle bronze when I see this kind of comment in TinyUSB, what is generating it?
/**
* @brief System Clock Configuration
* The system Clock is configured as follow :
* System Clock source = PLL (HSE)
* SYSCLK(Hz) = 84000000
* HCLK(Hz) = 84000000
* AHB Prescaler = 1
* APB1 Prescaler = 2
* APB2 Prescaler = 1
* HSE Frequency(Hz) = 8000000
* PLL_M = HSE_VALUE/1000000
* PLL_N = 336
* PLL_P = 4
* PLL_Q = 7
* VDD(V) = 3.3
* Main regulator output voltage = Scale2 mode
* Flash Latency(WS) = 2
* @param None
* @retval None
*/
or do you write them out yourself?
@timber mango 1) Which board do you refer to, 2) can berry syrups program?
@timber mango I'm 99% sure it's a no as the processor is "too small", the list of boards for CircuitPython can be seen on https://circuitpython.org/downloads and for MicroPython I'll add the list when I find it ...
Uno is definitely a no.
@timber mango you can use snek, which is a python-like language, on an Arduino
huge
an Rpi has at least 512MB of RAM, and now up to 8GB. The processor is 100-1000 times faster, very roughly. It runs an operating system, Linux-based
Hi, Is there or going to be any special bootloader for ESP32 S2 to make it ready for CircuitPython?
@maiden chasm Not yet no. Right now you should just load it with esptool.py. We are looking into a UF2 bootloader for it.
I can't find anything an easily understood list of boards for MicroPython. BBC micro:bit based on the nRF51822 processor is probably the "smallest".
Are there any debug options available on BLE start_scan() ? I've just coded up my own Advertisement matching and it appears to work as opposed to library implementation which seems non-deterministic. The python parts of the library code seem rather simple so I am puzzling over this.
you could do some unit testing on the matching. Are you doing "all" matching or just "any"?
Just one
There is a bug in the existing C implementation
Is there a ticket that describes that one?
I have one device sending and two devices receiving but one of the rx'ers can see (as in match correctly the Advertisement sub-classes) packets and one can't. Could that bug explain that? I.e. same over the "wire" data is received by both
I also have scan responses rattling around. I'm about to try active=False which I believe will stop those as I don't need them and would like to reduce chatter.
it's possible only one device is seeing a scan reponse.
otherwise, no, both should be able to see, unless there's a lot of competing traffic
I'll do some more testing on my own matching code.
I've seen >15 seconds where nothing has been received on one device sat 10cm from another. Has been a puzzling and frustrating few days!
if you just look at all advertisements and not filter, do you see something? Do you see random advertisements from other devices like your phone?
As soon as I look at all Advertisement I see everything, the two other CP devices and my neighbour's bose headphones, etc. (it's just like the Matrix).
ok, so it sounds like a filtering issue and not a reception issue. fixing that bug is a fairly high priority, but is not my most immediate thing at the moment
but if you are trying to use advertisements as the sole data transport, yes, you might try to avoid scan responses to get more effective broadcast. I am not sure if scanners ignore scan responses they don't initiate or not
i'm trying to find out but haven't found an answer
BTW, this code appears to match on the last rather than the first result: https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/master/adafruit_ble/__init__.py#L245-L248 as there's no break when it matches. It would be more efficient to match on the first. I don't think behaviour is documented at the moment. Is this intentional?
Oh, actually there is more going on in that loop than I thought.
Is it finding the deepest sub-class match?
i think something like that; I did not write that
Someone here knows about USB device descriptors?
@tulip sleet https://gist.github.com/k0d/acc77da4cfc29ccd4dac2c04f3a2b3de I don't know why this isn't working. There should be 2 CDC and 1 MSC. The # of endpoints says 9, when I believe it should be 8...also " Current configuration: 0 (unconfigured)" appears...which confuses me.
ah no...CDC has 3 endpoints it seems.
MSC has 2
plus EP0
there are endpoints and there are endpoint pairs (in/out)
sometimes the terminology is used sloppily
Does part of the software release process for CircuitPython include updating the Wikipedia page? I've just noticed it still mentions 5.1.0 https://en.wikipedia.org/wiki/CircuitPython
@tulip sleet I don't get why it says it's not configured
and line 9
this is circuitpython? or something else?
tinyusb...it didn't work in circuitpython...so I thought I'd test in tinyusb first.
i would look at the usb-probe report for some vanilla circuitpython device and compare it
also feed the descriptor(s) into http://eleccelerator.com/usbdescreqparser/
@simple pulsar we don't update it
I've got a usb probe report for one cdc and one msc...that works fine.
i'd have to re-remember all this, so I could help, but I'm not sure I'm any further along than you at the moment
cdc has control and data endpoints
are you trying to do two cdc channels
yeah...there is an example on tinyusb....but that didn't work either...but it did on a different board.
ah, ok, so that sounds like a bug if your code is otherwise the same
This has been updated with SDIO for STM32F405 Feather.
When fixing this it would be useful to keep an eye on any code which might fail on matching sub-classes of one or two Advertisements. As mentioned in discord, I've had the same code running on three boards which transit to each other and receive each other's broadcasts. Sometimes one goes "deaf" and doesn't pick up a particular sub-classed Advertisement for >15s which is really odd compared to its neighbour which receives them fine. The "deaf" CPB then suddenly picks up the next sub-cla...
@gentle bronze want to chat here? maybe @sour lynx is around
@tulip sleet it worked fine on a different board...I was using a 'blackpill' must be some bug with that board. Thanks for your help anyway!
@lucid solar Some STM chips have very limited numbers of endpoints
ah...thanks...I didn't know there was a limit.
and hierophect had a lot of trouble with the blackpill in various ways
I don't know usb very well yet...that's what I'm trying to change...it's useful to know more I think.
yes, pyboard can't have MSC, HID, and CDC at the same time: not enough endpoints. The SAMD's and nRF are much better in that regard
Thanks for the info! Now I need to find out the limits...
Seems I can't have more than 2 CDC on the F7, so I'll just give up on this project...2 can be enough I guess.
it's not even F7, it's which F7. F407 has fewer endpoints that F412, for instance
F746
"1 bidirectional control endpoint + 5 IN endpoints + 5 OUT endpoints"...now at least I know where to look.
blackpill "4 bidirectional endpoints"
Tested SDIOCard example on feather_stm32f405_express -- worked fine!
Also tested adding /sd to path and executed simple script from the sdcard.
@slender iron ping.
hi hi @idle owl
@onyx hinge Nice work on the SDIOCard!
@solar whale thanks for testing, you rock
@slender iron Have you already requested an adafru.it/ URL for your deep dive playlist on YouTube?
@slender iron Ok I will. adafru.it/deepdive work for you?
It is far from finished, we need an SDIO bus object, and of course we have multiple microcontrollers to support.
Happy to test
@idle owl that's fine! thanks!
👍
The URL http://adafru.it/translatecp is now live and points to our Weblate engage page. Please feel free to use it to get people involved with translating CircuitPython! @onyx hinge
@tulip sleet I got 3 CDC working on a MXRT1010-evk. Thanks for your guidance, it helped me to understand a bit more.
@slender iron http://adafru.it/deepdive is now live.
@slender iron CPY meeting notes for next week need created.
Excellent! I had updated my 2 boards to the latest CircuitPython, but had not updated the bootloader. One board had bootloader version 2.0.0 and the other 3.7.0. I updated both and they now work correctly.
I will just have to tell my PoE-FeatherWing customers they need to update their bootloader to the latest version if theirs is below 3.9.0.
I closed the issue.
Glad it worked for you! That's a good test.
LGTM! Was this left-over from the previous math functions, possibly? Only reason to pass in the bitmask, that I can think of.
Thanks @jepler.
All, not sure if this is the right place to follow up on an issue, but the following has been there for a while. I'd love to help with it, but I think it's a bit over my head. Is there any way to bring it under the responsible people's radar. It's related to the locationbeacon capability that was already implemented but it was dropped on the final version of CP. : https://github.com/adafruit/circuitpython/issues/2709
I used an alpha version as suggested by @tulip sleet at the time, but just wanted to make sure that it will be available in the official release for everybody to use.
@hierophect Do you have teensy's you can test this with?
Thanks @v923z. I opened #2999 for reasons to merge upstream changes.
So I guess the question is: what does "CPython compatible" mean to you?
@dpgeorge Thanks for jumping in on this! I really appreciate your input.
My philosophy is that "CPython compatible" means that any code written in CircuitPython that only imports modules available in CPython works without modification in CPython. The corollary of this is that any CircuitPython-only code must import a module not available in CPython. This means that CircuitPython-only code will error consistent...
You can use generators like coroutines even back in Python 2, ever since yield was introduced — in fact the early async proofs of concepts were done that way.
I think that at some point they actually added a check to async/await that raises an error if you call it with a generator, but that was relatively late in the development.
Here is the notes document for Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1Qw85z5TvSbwiNRFfyjH9SiU30pWJ_edUk3T-cEEIApg/edit
@slender iron do you use Sublime Merge?
@ionic elk off and on
do you think it'd be an ok thing to ask Adafruit for?
are you using it regularly?
I basically wish I could have the kind of overview Github gives but locally, does it do that?
No I don't have it
definitely try before you buy
it works just fine without purchasing
I don't know how to diff against master
I mainly use it for staging some of the changes I have
I just use github for the overall diff
Ok. I'll try and see if it speeds anything up but I won't spend a lot of time on it
👍
@ionic elk did you see the issue about teensy no longer starting?
it may be that we need to never reset it's flash pins
hmmm I thought I covered those
do you have the boards?
maybe I got the wrong ones
I have a teensy 4 somewhere around here
But I didn't test that one
I don't know how to program it
ya, if you could take a peek that'd be good
k
thanks!
Well, the 4.1 doesn't have pin protection at all, so that's pretty obviously the problem for it. I think it came in after my reset PR
and it looks like the 4.0 is missing a bank for the second flash device.
(why does it have two from different brands?)
two what?
This PR expands the never reset pin set in board.c to appropriately cover all flash chips on the Teensy 4.0 and 4.1.
Resolves #2998, hopefully? I'm still figuring out how to flash a teensy 4.0 with a Jtag.
Actually, I'm starting to think it's my code that's getting out of sync with itself. Now I've got my own matching code I can also see more detail when it doesn't match and I have a very small sequence of different Advertisement types. I accept the current one and one after but not the one before...
@ionic elk you don't need a jtag to flash
in fact, you can't
teensy doesn't break out the pins
so, is there an non-overridable bootloader loaded on one of the flash chips or something? I'm still kinda wrapping my head around the i.MX flash stuff
on teensy there is a separate micro that does the loading
(iMX also has a rom bootloader itself)
Oh that's what thee MKL02Z32VFG4 is, I mistook it for an extra flash chip when I glanced at its digikey page, my bad 😆
yup yup
Well, that's nice. Guess I need to download the whole teensy loader thing
the extra teensy loader is unique to the teensy ecosystem
not to say there aren't similar solutions
@slender iron Hmmm, no dice on my end. Can you think of anything else on here that needs to be never_reset? https://www.pjrc.com/teensy/schematic.html
@slender iron I have a weird build failure on one of my PRs, in the esp32s2 build, nowhere near anything I touched. https://github.com/jepler/circuitpython/runs/731887876 supervisor/usb.c: In function 'init_usb_hardware': supervisor/usb.c:80:31: error: 'USBPHY_DM_NUM' undeclared (first use in this function); did you mean 'USBPHY_VM_NUM'? gpio_set_drive_capability(USBPHY_DM_NUM, GPIO_DRIVE_CAP_3); ^~~~~~~~~~~~~ USBPHY_VM_NUM
@ionic elk flash and usb are two obvious things to protect
could it be the same issue of resetting the port before setting the never reset?
I notice now this is the Action from my fork, brow furrows due to being a draft, maybe it's not built in adafruit/circuitpython
@onyx hinge I haven't seen that before
@slender iron not unless someone snuck in a different reset_port somewhere that isn't port.c, I'm looking at it and it's still fine
¯_(ツ)_/¯
I've got protections on the flash... maybe it's USB? Even though ID and VBUS aren't actually connected?
does it work if you comment out the reset logic?
Well, I've tried this on the 4.0 and something critical is getting reset outside the flash pins, I think. Commenting out reset_all_pins from port_reset results in normal operation so it's definitely a pin overwrite issue... but which pin?
hi
@ionic elk I use meld as a mergetool. I used kdiff3 before that, but it stopped working well with the latest Ubuntu
@tulip sleet thanks I'll check those out too
@surreal scarab hi, if you have a q, go ahead and pose it
im just starting i youtube channel can i post links to my new vids here when they come out?
or streams
what is the subject of them? They should be relevant
ah I commited some bad submodule updates 🤦
unboxings and gaming i only have 3 vids at the moment im edeting the rest
just made the channel 4 days ago
that's not really so relevant to the topics in this server, sorry
what would count as relivent thou just wondering