#circuitpython-dev
1 messages ยท Page 344 of 1
@slender iron got a sec today to talk sockets?
later yes. not now
๐
I followed the steps above with a 'fresh-out-of-the-box' Wio Terminal. I loaded CP 6.1.0-beta.2 and did not see any hangups using time.sleep(). I re-tested using CP 6.0.0 and still do not see the reported behavior. Do you possibly have any libraries installed that might be interfering here?
Since we've eliminated the obvious on our end and at weblate, I've submitted a github ticket--I don't think it is viewable by the public but it is "Pull request displaying incorrectly #946332" and the link that works for me is https://support.github.com/ticket/personal/0/946332
In certain PRs, we get a different (incorrect) view of the changes in the PR, compared to on the git commandline.
One such PR is https://github.com/adafruit/circuitpython/pull/3792
It shows commits s...
I might be inclined to work on this a bit if I can't easily satisfy my use case with a hackier system, so I'd love to collect some more thoughts about how this could/should work.
In my mind I've got two clear use cases: 1) something like image transfer, where a device with a camera needs to backhaul a small .jpg or something for processing on a gateway. 2) (my current need) in-the-field live firmware update. A gateway advertises some kind of FW update service where a device with a lower ve...
CircuitPython for prototyping has been off the charts fantastic. I really cant offer enough gratitude for how great it's been to work on adafruit feather hardware and to use circuitPython to bring it all together. I'm curious though, if I were able to take my prototype that consists of, say a feather and a few feather wings, but I wanted to reduce costs and make a specific PCB with just the components I need, could I still use circuitPython provided that the components chosen were the same as the components needed from the feather boards? Are there any difficult problems with making the jump to more custom boards while trying to stay in the CP world?
(other than the problem of designing and sourcing said board)
If you want to use a SAMD51 and simplify the process a lot, check this out. When this comes back in stock, it's a pricey way of skipping a lot of steps https://www.adafruit.com/product/4802
The project is based off of the nRF52840
Ah gotcha
[CI failure is a problem uploading artifacts, which is reported at https://github.com/actions/upload-artifact/issues/116 but not metoo'd by us yet. should not affect accepting this PR]
@mild fog you can definitely run CP on a custom board
@ionic elk I have a little time now
Awesome! Have you ever seen any info or blogs on this process?
@mild fog https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/overview https://www.hackster.io/wallarug/circuitpython-creating-custom-boards-8e979e may help
I built circuitpython at tag: 5.4.0-beta.1 (0ba541d49878f8fa62aca7822e8c7d333dd5c2f0, Jun 8 2020) and that did work on Fomu.
There were multiple English abnormalities in the Seeduino Xiao description. I fixed them.
Commit f232aef7865c4e094f060f9766418f60fb9f86ea (Jun 15, 2020) "supervisor.mk: Compute USB_DEVICES; remove from boards and ports" also WORKS.
@slender iron I have updated the ota PR.
Hi,
Now, after many hours of source code readings, trying some debug code, I have to say that I am lost. I never wrote much code in C. Mostly some small Arduino code running the bare metal. But the code base for CircuitPython is using so much wrapper code to have all the boards supported is killing me. Compared to one of my very first software on a C64, printing Mandelbrot fractals on the screen, this is beyond my brain.
Back to the topic
If a RawSample() is played, only the first cy...
f61c4e62c14e52da83b17f740b5c5409ee4b05a5 (Nov 11, 2020) -- not working
3dfed3c4aa52d06bd2eb1c28d0a1916821cc3f80 (Jul 24, 2020) -- not working
2d579cc9953a3ba965973c6d5139c007b3c1b38d (Jun 26, 2020) -- works
@digixx As long as CIRCUITPY isn't mounted by a host over USB maybe you could write the data to a wav file and then play that back?
@slender iron aew you deep diving today
I did have around 10x files from adafruit-circuitpython-bundle-6.x-mpy-20201208 in /lib
Deleted them, rebooted, seeing the same issue.
I noticed when I upgraded from 6.0.0 to 6.1.0, it kept my files in the filesystem.
Is there a command I can run to wipe it back to factory defaults?
I recently experienced that shortly after starting CircuitPython, JTAG debugging on the Kaluga would stop. I think this may be due to #3643, though I didn't bisect it. I can work around it by making the jtag pins never-reset, but I'm not sure if this is the right fix since this (I think) would stop people using them as GPIO in general.
+ common_hal_never_reset_pin(&pin_GPIO39);
+ common_hal_never_reset_pin(&pin_GPIO40);
+ common_hal_never_reset_pin(&pin_GPIO41);
+ commo...
Is anyone else still seeing issues with I2C on ESP32-S2? I get intermittent forever-waits (can ^C) on i2c = board.I2C() after soft reboot using 6.1.0-beta.2-89-gf2204d7d8 on 2020-12-16
It's actually sleeping for the correct duration, but after it finishes, it's not displaying a new line + >>> on the REPL.
I noticed this by pressing the down arrow on my keyboard after the sleep duration finished, while it looked like it was locked up ... but it wasn't locked up at all!
It just didn't move down to the next line, ready for the next command.
yeah but in some of the videos lady ada was showing a prototype so i wonder if it will still be released or not?
There have been some other very cool prototypes shown #TopSecret but "don't ask", and who knows if or when they'll see the light of day
With latest from S3โฆ
adafruit-circuitpython-adafruit_magtag_2.9_grayscale-en_US-20201217-8f9cd70.uf2
(Adafruit CircuitPython 6.1.0-beta.2-104-g8f9cd7075 in REPL)
displayio still exhibiting transparency issue at various depths and 4bpp image crash. Is there some still-pending build in the queue I should be waiting for?
From a feedback comment on the new Deep Sleep Guide:
One thing I've noticed about using deep sleep that was very confusing at first (as well as regular sleep for long periods) is that code no longer auto-reloads when I save in Mu. It seems like the Magtag is hanging. You need to mouse into the REPL and type CTRL-C.
@xobs would you like to take a look at this?
Here is the test code I'm using:
import alarm
import alarm.pin
import alarm.time
import time
import neopixel
import board
import digitalio
if alarm.wake_alarm:
print("awake", alarm.wake_alarm, alarm.wake_alarm.pin)
else:
print("no wake up alarm")
enable = digitalio.DigitalInOut(board.NEOPIXEL_POWER)
enable.switch_to_output(False)
# Sleep for 5 so USB can start.
time.sleep(5)
pixels = neopixel.NeoPixel(board.NEOPIXEL, 4)
pixels.fill(0x0f0000)
time...
@tulip sleet Is there an easy way to disable usb check... (i.e. force deep sleep).
when debugging...
@analog bridge I think it was mentioned that the deep sleep is a "fake deep sleep" while you have the REPL active. I believe you'll have to do something through the battery pins to power the board. Scott yesterday showed during the Deep Dive stream how to monitor the power consumption etc, you may find it handy.
hi @hearty tapir yes... I know about the fake deep sleep... I am looking for a way to force deep sleep even when on usb.
currently working on TouchAlarm implementation...
I am able to get it working if I explicitly call esp_deep_sleep_start() just after I set the alarm... but it doesn't work with existing sleep workflow...
@kevinjwalters Yes, technically possible, but is it worth? I dont think so. Out of curiosity I will create a defined wav file and see if it is played correctly.
Oh, I was just talking about addressing the size not the "fidelity" of the output. The SAMD51 DACs just seem to have a lot of strange behaviour. Asking the manufacturer would seem to be the next step here with some simple example C code.
@PaintYourDragon Until this PR is merged, it won't appear on S3. You need to get it from the Actions build instead.
How to navigate there: Click the "Checks" tab below the PR title, then click "artifacts", and find the "adafruit-magtag-..." zip near the top of the list.
Direct-er link: https://github.com/adafruit/circuitpython/suites/1687216126/artifacts/31633147
HEUREKA!
We have here different problems like wrong signal levels and missing the last value of the array. I noticed that small changes in values are better converted than a jump from 0 tp 65535. Creating an sample array containing several hunderts of 0,65535,0,... I observed that when a level was low the next level was higher than the average max level. Touching the wire of A0 also injected some noise which can be seen on the scope. Energie problem?
Yes. In Circuitpython the max sample...
I'm happy to approve this after @PaintYourDragon verifies the fix.
I had added such a provision to the original API, but it was too easy to get in a unbreakable boot loop in which USB went away before a looping sleep could get interrupted. This happened the very first time I started debugging sleep, and I had to erase flash completely to get out of the loop.
Are you trying to power via the USB port but have no data? I tested some of the time with a power-only USB cable. I have a switchable one and also one where I have just cut the data leads. Otherwise I also used ESP_LOGI() a lot. Also you could have CircuitPython write to a UART instead of to stdout if you are trying to instrument the CPy program.
If you just want to hack it temporarily for debugging, I think it would be sufficient to change this to if(true), in main.c:
if (!supervisor_workflow_active()) {
// Enter true deep sleep. When we wake up we'll be back at the
// top of main(), not in this loop.
alarm_enter_deep_sleep();
// Does not return.
thanks @tulip sleet...
one more question, I notice neopixel and status leds get disabled after entering deep sleep and are only re-enabled on a power cycle... is this expected behavior?
yes, because the GPIO state is reset. We'd want to turn these off anyway even if it wasn't automatic to save the current consumption of those LED's. The power-on LED (not on GPIO) on the MAGTAG has a high-value resistor to minimize its consumption as well, and it's pretty dim as a result.
I think in the case of the status NeoPixel that is turned off deliberately, since just disabling the pins that feed it would not turn it off
I think there's a problem with adafruit_bus_device-in-core and bitbangio.I2C. When I try to use this combo on esp32s2, I get a hang; if I hit ctrl-c it becomes a panic error. ```E (44776) i2c: i2c_master_cmd_begin(1113): i2c driver not installed
../../esp-idf/components/freertos/queue.c:719 (xQueueGenericSend)- assert failed!
I suspect that the in-core version of adafruit_bus_device assumes the device is a native busio.I2C device but it is not necessarily
the four front-panel neopixels have a transistor for power control
is gpio reset called before entering deep sleep?
.. unless anyone has quick words I'm going to file an issue about it ..
i think so, but I'm not sure where.
I am asking this because touch pad needs to be initialized before entering deep sleep... if io is reset before entering deep sleep, it will de-initialize touch pad
it may just be a side effect of esp_deep_sleep()
i don't see a call to our own reset routines.
True
[11, 112]
>>> bus = bitbangio.I2C(board.IO10, board.IO11); bus.try_lock(); bus.scan(); bus.deinit()
True
[]
``` though .. bypassing `adafruit_bus_device` bitbangio.I2C sees only an empty bus ๐ฆ
I think 1 Msps is the physical limit of the hardware? And is this the same DAC setting as the one in https://github.com/adafruit/circuitpython/issues/2099#issuecomment-526865939 ? How are you changing it, in C code or recompiling CircuitPython?
there is a call to board_deinit(), before both fake and real deep sleep, but that routine is empty on most boards. On the magtag it deinits the eink display
if I explicitly call esp_deep_sleep_start() just after setting the alarm... it works
quoting from the esp doc:
In deep sleep mode, CPUs, most of the RAM, and all the digital peripherals which are clocked from APB_CLK are powered off. The only parts of the chip which can still be powered on are: RTC controller, RTC peripherals (including ULP coprocessor), and RTC memories (slow and fast).
One thing we may want to handle:
Some ESP32-S2 IOs have internal pullups or pulldowns, which are enabled by default. If an external circuit drives this pin in deep sleep mode, current consumption may increase due to current flowing through these pullups and pulldowns.To isolate a pin, preventing extra current draw, call rtc_gpio_isolate() function.
For example, on ESP32-WROVER module, GPIO12 is pulled up externally. GPIO12 also has an internal pulldown in the ESP32 chip. This means that in deep sleep, some current will flow through these external and internal resistors, increasing deep sleep current above the minimal possible value. Add the following code before esp_deep_sleep_start() to remove this extra current:
rtc_gpio_isolate(GPIO_NUM_12);
for touch_alarm to work esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON); needs to be called
so you are calling esp_sleep_enable_touchpad_wakeup(void) ?
my touch alarm branch https://github.com/adafruit/circuitpython/compare/main...microDev1:touch-s2
you may want to take a look at Scott's PR for pin alarms, which is not merged yet. It mostly works but has some issues, but I think pin alarms and touch alarms are going to be very similar
the esp_sleep_pd_config() may happen automatically, similar to using rtc fast mem. It may record that you need that when you do esp_sleep_enable_touchpad_wakeup()
I tested this but not doing automatically in case of touch
On the Kaluga, I have two sensors attached to the I2C bus at IO10/11. They are detected if I scan with busio.I2C but not with bitbangio.I2C. When I scope bitbangio, there is literally no activity on the pins 10/11; there is the expected activity with busio.I2C.
>>> import board,bitbangio
>>> bus = bitbangio.I2C(board.IO10, board.IO11); bus.try_lock(); bus.scan(); bus.deinit()
True
[]
>>> import busio, board
>>> bus = busio.I2C(board.IO10, board.IO11); bus.try_lock(); bus.scan()...
I did some more tests now with forced deep-sleep enabled...
there's definitely something between setting up touch-pads and starting deep sleep which is causing touch-pad to de-initialize
the sleep doc is not very clear about how to set up the touch pads. is there an example of deep sleep touch you are using as reference? i thought it would be quite different than regular touch, considering how the pin level checking is also different (only certain pins, etc.)
the basic touchpad initialization is same for normal as well as sleep... some extra parameters need to be dialed in for sleep
there is more info about that on the touchpad page instead of sleep_modes page
@onyx hinge So looks like its an bitbangio.I2C issue not the bus device? I can look at the bus device if you think that's the problem, but may take me a couple days
I think there are multiple problems going on. I would appreciate if you can take a look at bitbangio.I2C + built-in busdevice, that would be helpful
you can probably do it on whichever micro is convenient for you
Sure never played with the bitbangio before, so totally possibly I didn't account for something
Running the following sequence twice in the same REPL causes CircuitPython to reset (not into safe mode, just a "normal" reset!)
Tested on a kaluga with DEBUG=1 at f2204d7d8
(tio is my terminal program)
import busio, board; bus = busio.I2C(board.IO10, board.IO11); bus.try_lock(); bus.scan(); bus.deinit()
True
[11, 112]
>>> import busio, board; bus = busio.I2C(board.IO10, board.IO11); bus.try_lock(); bus.scan(); bus.deinit()
True
[tio 10:05:07] Disconnected
[tio 10:05:41]...
@analog bridge ah, I see where the reset is is happening, I think, it's in cleanup_after_vm() in main.c, which calls many reset routines. That gets called when code.py finishes running.
Scott's pin alarm code may defer setting up the alarms until after the program has stopped running, to get around this, or else he prevents reset on certain pains, but I think the former is more likely.
so I'd take the lead from his code
The 32blit kickstarter (from Pimoroni) is reaching the backer. Any CircuitPythonista have one? That is an STM32 board possibly supported by CP already.
nice... I assume this calls reset_port()?
Scott's code calls alarm_pin_pin_alarm_prepare_for_deep_sleep() just before deep-sleeping. See line 157 in https://github.com/adafruit/circuitpython/pull/3830/files#diff-358598ea16b4ad1f25f165d7280842af0eb90c70c668c6b34f343ef39b2b09c5. That just sets up some pullups. Still looking...
yes, it does call reset_port()
he calls never_reset_pin_number() on the pins used for alarming here https://github.com/adafruit/circuitpython/pull/3830/files#diff-139b97e7159e35d9fe550989a19ac82e596cf83dfb92f88e250ff129c21101ec line 285
so that would prevent messing up those pins before going into deep sleep (my quick surmise)
๐ @tulip sleet thanks again for bug-fixing
what bug did i fix? ๐
ok... for clearing things up
ah ๐
What is the proper way to report a bug? Here or github?
github is best; if you're not sure you can ask here first, but github is a much better to-do list
thanks!
Here's what an attempt to read cell voltage looks like on esp32s2 near the tip of main (f2204d7d88b505155cd25b38b71ae3c35b86d438):

@tropic rain which board are you using that doesn't have json?
and what version of CPy/
Circuit Playground Express. I'm trying to show images on the TFT Gizmo. boot.out.txt is
Adafruit CircuitPython 6.0.0 on 2020-11-16; Adafruit CircuitPlayground Express with displayio with samd21g18
and I'm using libraries fro adafruit-circuitpython-bundle-6.x-mpy-20201216
yes, that board doesn't have json; there's no room. the code should not assume json. Roll back to version 1.4.0 for now, and I'll revise your t bug: https://github.com/adafruit/Adafruit_CircuitPython_Slideshow/releases/tag/1.4.0
Thanks, I'll give it a go.
Somehow, this IS due to adafruit_bus_device-in-core. I substituted the old Python-coded one by trickery. I copied it to a folder old_bus_device so that I could use the following sequence in the repl:
>>> import old_bus_device
>>> import sys
>>> sys.modules['adafruit_bus_device'] = old_bus_device
>>> import adafruit_bus_device
>>> adafruit_bus_device
<module 'old_bus_device' from '/lib/old_bus_device/__init__.py'>
>>> import
>>> import board, busio, adafruit_lc709203f; bu...
yeah we default to repeated start when using write_then_readinto...because linux does and cannot otherwise. if you need to generate a stop (which some chips need) you have to do a separate write and then a separate readinto
Testing performed: on esp32s2 kaluga with LC709203 sensor on the pins shown below, use the repl to check the cell voltage:
>>> import board, busio, adafruit_lc709203f; bus = busio.I2C(board.IO10, board.IO11); dev = adafruit_lc709203f.LC709023F(bus); print(dev.cell_voltage)
3.807
(this bug is not esp32s2 specific and was reported to affect other ports as well, but the LC7โฆ sensor is sensitive to this bug in a way other sensors apparently are not)
Closes #3795
didnt test on hardware but verified that write_then_readinto is repeated start but that plain write() is not!
We may be able to remove some of the special-casing of certain translations now that we've switch to gcc10, which produces smaller builds, but we can get to that later.
Thank you!
My pleasure ๐
We may be able to remove some of the special-casing of certain translations now that we've switch to gcc10, which produces smaller builds, but we can get to that later.
That would be great. Thank you
yes, this bug report is reproducable - i have to manually restart after updating code
Closing this, since it's on an old version and is quite old now.
You might try erasing flash completely and then reloading things.
I changed the code in \circuitpython\ports\atmel-samd\common-hal\audioio\AudioOut.c
starting at line 189
if (channel0_enabled) {
#ifdef SAMD21
DAC->EVCTRL.reg |= DAC_EVCTRL_STARTEI;
// We disable the voltage pump because we always run at 3.3v.
DAC->CTRLB.reg = DAC_CTRLB_REFSEL_AVCC |
DAC_CTRLB_LEFTADJ |
DAC_CTRLB_EOEN |
DAC_CTRLB_VPD;
#endif
#ifdef S...
I worked on a fix for Circup so it would automatically update its version from the release tags. Can someone with Library experience have a look at my changes. I don't know how to test this locally. The CI runs clean and I can install my branch and it works fine, but can I test the semver part without merging and attempting a release?
This is to fix the versioning not being automated.
These changes bring the setup.py and library_name.py in other Adafruit library repos. See https://github.com/adafruit/Adafruit_CircuitPython_Reque...
Thanks , that worked and I gotta say I'm really impressed with your quick response. This is how it should be.
@skieast ur fork is broken. tinyusb outdated, some mistake on the board.h path as well...
just clone the latest CP, copy those 2 folders of the lily, modify board.c to point into supervisor/board.h like all other boards.
build flash and go.
I havenโt been looking closely at my fork. Mostly looking at some Wifi i2c
issues. Iโll take a look and see what I can do. Thanks
On Fri, Dec 18, 2020 at 12:33 PM xmmpru83 notifications@github.com wrote:
@skieast https://github.com/skieast ur fork is broken. tinyusb
outdated, some mistake on the board.h path as well...
just clone the latest CP, copy those 2 folders of the lily, modify board.c
to point into supervisor/board.h like all other boards.
build flash and go.โ
...
i think this board is too fresh.. very unsupported, im not able to make it run..
SPIWP:0xee
mode:DIO, clock div:2
load:0x3ffe6100,len:0x8
load:0x3ffe6108,len:0x17ec
load:0x4004c000,len:0x930
load:0x40050000,len:0x2cc8
entry 0x4004c1b4
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4002ec30
0x4002ec30: _xt_highint4 at /root/circuitpython/ports/esp32s2/build-lilygo_ttgo_t8_s2_st7789/esp-idf/../../esp-idf/components...
I believe this may be due to the non-zero timeout being less than the interval, because the default interval is 0.1 seconds. I put in a check for this which will require the timeout either being zero or >= the interval.
- Characteristic and descriptor
max_lengths can be zero. Fixes #3746. - Assure that
start_scan()timeout is either zero or >= interval. This is a guess for this fix, but it coincides with working values reported in #3826. Fixes #3826. - Assure that
start_scan()max timeout is not too large for auint16_twhen passed to nRF SD. Fixes #3340. - Fixes small advertising interval values. Fix check and make sure it's at least 0.02001, to allow for rounding issues, as discussed in #2930. F...
Hey guys im trying to get a python device that runs a simple script and maybe has like a screen on there so I can display messages to show when something finished. Can anyone refer me to a not-sold-out device?
That last link was bad advice...
How about Feather S2 https://www.adafruit.com/product/4769 and one of several Feather Displays. https://www.adafruit.com/?q=feather+display&sort=BestMatch
"at" me in Help-with-projects if you need more ideas.
Introducing the FeatherS2 - The full-featured ESP32-S2 based development board in a Feather format from Unexpected Maker. The FeatherS2 is a power house, fully souped up with 16 MB of Flash ...
Adafruit Industries, Unique & fun DIY electronics and kits : - Tools Gift Certificates Arduino Cables Sensors LEDs Books Breakout Boards Power EL Wire/Tape/Panel Components & Parts LCDs & Displays Wearables Prototyping Raspberry Pi Wireless Young Engineers 3D printing NeoPixels Kits & Projects Robotics & CNC Accessories Cosplay/Costuming Hallow...
Why is the CLUE bad advice? Curious
You know what... I was wrong about that. I thought it was Arduino ... NVM, Clue was a great idea. https://www.adafruit.com/product/4500 Thanks @fathom shell
Do you feel like you just don't have a CLUE? Well, we can help with that - get a CLUE here at Adafruit by picking up this sensor-packed development board. We wanted to build some ...
I already went with py portal
Also thoughts on a pyportal? I think it's overkill now but I suggested it because it has no soldering involved and has a big screen
ah right wifi was a req
So with py portal I can just press a button and it works?
how do you mean?
like is there a button on it that runs the script
So with circuitpython your code.py or main.py script runs automatically on bootup until it ends
*after boot not on boot
wait so I just plug it in, edit the file, and boot it up?
When it powers on it boots up and then runs the code in code.py and uses any libs referenced therein. You can load your code and then restart and it will automatically run.
oh cool so I can use it as long as it has a wifi connection?
You should be able to use it without wifi
You do for power
re: usb, wifi, etc ... you should get specific about what you're looking for. most circuitpython devices can be powered by external battery or usb, but many do not include integrated wifi.
So can I just get a portable charger for it @fathom shell
you're gonna want to be careful about input voltage, I'd see if you can find a 5V only charger to be safe
The failing build is just a network problem.
I think this may be a better solution. The original
.tx_powerwas added when I was not as aware of the many variant ways of controlling tx power. Another place to look is what the bleak-related and Bluetooth HCI interface provide, so we can make this work across other platforms. I think it may not actually be possible to change the power in the ESP32 HCI firmware (I cannot remember at the moment and am away from be able to look this up).Functions esp_err_tesp_ble_tx_po...
@tannewt do you think this might be fixed?
I was able to reproduce the error. Uncommenting ESP_LOGI(TAG, "type"); on line 151 of PinAlarm.c prevented the crash. Interestingly, if I had the serial monitor of the mu-editor open it would still crash at the same point even with the line uncommented.
I also got this to crash on a Metro M4 with board.A3 and board.D0. The pin does not seem to matter much.
I single-stepped and it seems to be crashing in tc_reset(). The argument looked OK: it was the right address for TC7 when I was debugging on the Grand Central.
My basic wish is to have second USB-SERIAL device in
ESP32-S2 which will lead to hardware TX/RX lines.
I was thinking - if descriptor must be static, and list all supported
device for which same endpoints have to be shared, then
perhaps on the OS (at least linux) is possible to blacklist unneeded
drivers, so that actually endpoints will be used only by not blacklisted
drivers, and things may work. (at least in heory)
This PR adds support for setting a Touch Alarm.
Port(s) supported: (as of this PR)
- esp32s2
Test Code:
import time
import alarm
import digitalio
from board import *
led = digitalio.DigitalInOut(LED)
led.direction = digitalio.Direction.OUTPUT
led.value = True
time.sleep(5)
print("WakeAlarm :- ", alarm.wake_alarm)
print()
alarm.exit_and_deep_sleep_until_alarms(alarm.touch.TouchAlarm(IO1))
@tough flax asks:
I know that CP's USB stack uses TinyUSB and that TinyUSB supports WebUSB.... but do know if CP can benefit from that code? Can WebUSB talk to the serial port for example?
It can, though I don't know much about it. Here's a sample serial terminal: https://googlechromelabs.github.io/serial-terminal/ (https://github.com/GoogleChromeLabs/serial-terminal). I get a lot of <CONNECT><DISCONNECT>, but I find that if I turn on "Flush on enter", that problem goes away for a while, at the expense of only echoing on "Enter". I'm assuming this can be fixed. We are already using WebUSB as an alternate upload tools for the ESP32-S2 boards: https://learn.adafruit.com/adafruit-metro-esp32-s2/web-serial-esptool. Repo is at https://learn.adafruit.com/adafruit-metro-esp32-s2/web-serial-esptool
@gilded cradle did the upload tool.
@tulip sleet alarm.wake_alarm is taking weird values... It takes the value of previously set object. Example in the following case it takes value of <DigitalInOut>
led = digitalio.DigitalInOut(LED)
led.direction = digitalio.Direction.OUTPUT
led.value = True
print("WakeAlarm :-", alarm.wake_alarm)
that is some kind of bug then. It's a static entry in the module dictionary for alarm
i will look at that; i added it recently, in a bit of a hurry to make a demo work
it was there but unimplemented before that
I'm not quite sure what you're looking for. We have been thinking about a secondary CDC serial connection over USB (e.g. you'd have /dev/tty/ACM0 for the REPL connection, and then also a /dev/ttyACM1. But if you want hardware UART, then you want to use busio.UART.
above is with code in PR #3850.
in my local branch... I implemented a way to get alarm.wake_alarm.pin for touch_alarm and now I get the same crash as the one scott is getting with pin_alarm
are you using alarm_set_wake_alarm() and/or alarm_save_wakeup_alarm() in shared-bindings/alarm/__init__.c?
I didn't alter that... yes alarm.wake_alarm is using the existing implementation.
I will take a look, something sounds definitely odd.
the weird thing is that it works when I do ctrl+c just before print(wake_alarm) in main code and instead use repl to get wake_alarm
ok, I was going to test it in the repl first! ๐
we have to delay setting alarm.wake_alarm until the VM and heap are set up when the program restarts
since it creates an object
yes I noticed that while digging into main.c
Yes I'd like to have this secondary CDC /dev/ttyACM1
and a possibility to bridge its traffic to external pins TX/RX
it would be practical to run usb-serial bridge in
"background" of esp32 so that more user code
can work too if technologically possible.
On 12/19/20, Dan Halbert notifications@github.com wrote:
I'm not quite sure what you're looking for. We have been thinking about a
secondary CDC serial connection over USB (e.g. you'd have/dev/tty/ACM0
for the REPL connection, and...
I got a few feather M4 CANs and started working on a canio based node framework that allows assigning callback functions to topic IDs: https://gist.github.com/ryang14/8d09939b9aa15716d4fbeca4fe982905
This looks and sounds similar to the bug that @slender iron was working on in his deep dive on Thursday in PR #3830
It seems the "creating a library" page in the Creating and Sharing a Circuitpython library guide is having a 500 error: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/creating-a-library
The rest of the pages in the guide seem to be working fine: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library
I've got a MatrixPortal board running CircuitPython which is having some issues. If I connect the board to a PC (or any device that can handle the MatrixPortal's USB serial output), then the board runs fine for extended periods of time. If I hook it up to a charger (or a PC that is sleeping, etc), then the board will eventually hang.
I've run a few experiments and been able to demonstrate that I can get the board out of the hung state by waking the PC it is connected to.
Here's a si...
@jepler @danh i think this got done right?
hihi - from the git history and lack of response it looks like @gravitech-engineer is AWOL or out of business? we like to see people being able to use their hardware even when the OEM stops supporting it, we'll grant a VID/PID to this board.
@dhalbert please allocate/assign a VID/PID to this PR and merge it at your convenience :)
Several of the pin mappings in the pins.c file for the umfeathers2 are not constant with the other feather boards.
Notable are D5,D6,D9,D10 -- many in the "short side".
https://github.com/adafruit/circuitpython/blob/main/ports/esp32s2/boards/unexpectedmaker_feathers2/pins.c#L50
Since it is "feather" it would be nice to keep the names consistent.
Is there some reason why this is not desirable or possible for this board?
I'll be happy to create a PR to rename them if no one objects.
thats sorta up to @unexpectedmaker - its whatever they want for their board :)
I can't find an issue or PR, but there was an extensive discussion on Discord about the challenge of ESP32-S2 pin naming, in the context of Metro S2 (whose long-side pins don't match Metro M4, for example)
Sure. It's not a big deal, but I just put my umfeathers2 into keyboard-feathering and have gotten most of the functions working OK but I had to do a lot of pin remapping that I think could be avoided. Also there is one hard code pin in the featherwing_keyboard library (D6) that won't work as is. Perhaps that should be fixed in the library and passed in as an argument like all the other pins.
I agree that for other boards, it may not be worthwhile, but since the "feather" layout is so comm...
Since board pins can have multiple names, there's a reasonable argument to be made to add the standard Feather naming to the names that match the silk, etc.
@tough flax I was told we got WebSerial working, but not WebUSB. But I think the demo I posted is WebSerial.
Thanks to @tulip sleet sleep memory, I made a kind of booloader for the MagTag. You can choose from 4 usage, hold the corresponding button, turn on the MagTag... and it will start that program at every startup (even after sleep): https://twitter.com/DavidGlaude/status/1340365817138044933?s=20
I made a boot manager for the MagTag by @adafruit to choose between many project from the learn guide.
With a little bit of @CircuitPython in https://t.co/54VinvBcT7 holding a button and turning on select one usage of the connected eInk display.
https://t.co/pTidfyIJnp
I put a PR in for the library https://github.com/adafruit/Adafruit_CircuitPython_FeatherWing/pull/66 and it works OK.
ahh - I see that the D-names do match those on the underside silkscreen so I guess that is how they should stay.
I had not looked at the bottom silkscreen and through they could be freely changed.
I'll close this.
but I was thinking - if in the OS the microphone driver is blacklisted,
then usb-serial may normally load and work.
We want to provide run-time choice of the USB devices that CircuitPython presents. That is #1015. Blacklisting might work on Linux, but we want an easier mechanism and one that is OS-independent.
Several other issues (#231, #3849, for example) want to communicate serially with a host computer without the REPL interfering. We have discussed providing a second USB CDC serial device. This probably needs dynamic USB descriptors (#1015), because of the shortage of endpoints, and the confusion that an always-present second CDC might present.
I rewrote this as a more general issue in #3853 and will close this in favor of that issue.
The secondary serial channel idea mentioned in this thread now is covered in issue #3853.
kk - we'd still need a way to read individual characters from the secondary USB-serial connection
kk - we'd still need a way to read individual characters from the secondary USB-serial connection
Yeah, Python is still bad at that.
@tulip sleet I get that WebSerial is easier, but it's still experimental on Chrome (and unavailable elsewhere) so that's kind of a problem... but I will take a look
I suggest to test-implement 2nd CDC channel with static descriptor,
observe problems what happens with host os and fix problems then.
@thorny jay That is awesome!
Great that you like it.
I wonder if I can do "import table[2]" to put the boot config into a file. Also have another meaning for 0 because that is uninitialised memory value, so a power on without pressing a button.
Update: Yesterday I finished my project to the point where I could plug in the battery and let it run overnight sitting on the fridge near the router. It managed to last the night without crashing from a network error.
Today I updated CP to the latest daily build and am still seeing intermittent connection errors from the computer in the back room. Sometimes "unknown error" and sometimes "No network with that ssid". When this happens, I re-save in Mu and it usually works on the first or se...
@endico, here is what I needed to do to get the proper retries to work and restart things correctly ( from the christmas countdown for context )
`
create MagTag and connect to network
try:
magtag = MagTag()
magtag.network.connect()
except (ConnectionError, ValueError, RuntimeError) as e:
print("*** MagTag(), Some error occured, retrying! -", e)
# Exit program and restart in 1 seconds.
magtag.exit_and_deep_sleep(1)
`
HELP!!! is anyone, besides me, trying to install the weather forecast display on the MagTag??? I'm having nothing but grief. I get a note about adafruit_imagload (from line 4 of the code) but adding that library to the lib folder results in other errors. and... OBTW the doc does mention this (not with the list of other libraries, but on a different page), but when I install it from the latest bundle (20201219) all I get is more errors (from line 176). Does this stuff get a QC check???
Is there a CircuitPython way to import a file given it's name as a string? (like this question for CPython): https://stackoverflow.com/questions/301134/how-to-import-a-module-given-its-name-as-string)
I'm writing a Python application that takes as a command as an argument, for example:
$ python myapp.py command1
I want the application to be extensible, that is, to be able to add new modules that
__import__ is available, the other solutions likely are not.
Could you start a thread on the forums? Include the exxact errors you are getting and the versions you are using, including the version of CircuitPython you are using. Thanks.
or try #help-with-circuitpython, with a few more details like the above
Hi,
Thanks for your email. Where we can locate the VID/PID for this board?
Thanks
Sharnon
From: 'ladyada' via Engineering engineer@gravitechthai.com
Sent: Sunday, December 20, 2020 12:20 AM
To: adafruit/circuitpython circuitpython@noreply.github.com
Cc: gravitech-engineer engineer@gravitechthai.com; Mention mention@noreply.github.com
Subject: Re: [adafruit/circuitpython] Add Gravitech Cucumber R board definition (#3349)
hihi - from the git history and lack of respons...
I am trying to "rate" the MagTag guide based on criteria. The goal is to identify those that could get some love. This is all related to beeing able to put more project on a single MagTag and have a selection button to switch from one usage to another. Here is a read-only version of the document in sharing. Maybe to be discussed "in the weed" (I made it read/write by all to help reading or contribute): https://docs.google.com/spreadsheets/d/1ZBrLID3p-dKbLkJ6x4Uq77l1FHkGS5ZRIoqBoD2kw_w/edit?usp=sharing
Feuille 1
Name,Learn Guide,GitHub,US Centric,Small images,in bmps folder,Binary fonts,in fonts folder,Entry point,Use button,Use sleep
This is the name in the learn guide, it is descriptive but does not harmonized:
"MagTag xxx"
"with Adafruit MagTag"
"for Adafruit MagTag"
or no indication that t...
on circuitpython.org what is the difference between CircuitPython 6.1.0-beta.2 and Absolute Newest? Where is the current Stable release?
I'm looking in to some custom built split keyboards and was wondering if anyone knew if I could run CircuitPy on this keyboard with the Elite-C controller?
https://splitkb.com/products/kyria-pcb-kit
Available, but in limited stock! More will come in by next week. The Kyria is a 40% split keyboard. Its main features are a large and customizable thumb cluster that allows you to move more work from the pinkie finger to the thumb, an aggressive column stagger that allows for a more comfortable hand position, andย two r
it looks like it's running a 32u4 and that's not gonna run Circuitpython
I'm confused about the comment about the 32u4. Why is that an issue? This appears to be 32u4 and works with circuitpy. https://learn.adafruit.com/adafruit-feather?view=all
that's feathers. Not all feathers support CPY, it runs on a few supported 32 bits chips with enough ram and flash
supported boards are listed on circuitpython.org, and any board with a similar chip can probably be added to it (provided the native USB is available on the board)
Maybe I should ask a different way. Can I put a CircuitPy boards on that keyboard and manage it with python?
oh probably
@jaunty juniper Are you asking if you can enter keystrokes to the REPL from a keyboard attached to a board running CircuitPyhton? I have not seen any examples of that. Has anyone?
you meant to tag @feral spoke ๐ it's a good point, I might have misunderstood the question
yes, thanks.
@solar whale I just want to use python to customize the firmware of the keyboard vs C and the QMK....but I like the PCB and layout of that board.
OK -- I guess I misunderstood. Not something I am familiar with. Sorry I can't be of any help.
@gravitech-engineer USB VIDs are purchased or allocated by the manufacturer of the board - for your USB boards, what VID are you using for bootloader and runtime, did you purchase a VID or are you using someone elses?
Great! import('magtag_weekly') works for me.
@feral spoke there's a keyboard emulator page for HID devices here https://learn.adafruit.com/circuitpython-essentials/circuitpython-hid-keyboard-and-mouse
Doesn't somebody make circuitpython powered keyboardy stuff? I can't remember who though.
Yes there is a MK60 board out there, but I want to use a diff board, but run python for firmware
Let me take a swing and someone official can correct me if Iโm off. 5.x is the Stable release. 6.x Betas are the attempts to stabilize 6 for existing boards (non esp32-s2). When 6.x Beta something shows to be stable it will become a 6.x stable release. Main is the development branch and where esp32-s2 implementation is ongoing.
I hope that helps.
(And that it is correct)
Thanks, David. I fixed my code per d-c-d's suggestion and I'm no no longer crashing on connection errors. I'm still getting plenty of 'No network with that ssid' and Unknown failures but now the code is retrying, and eventually connecting.
6.0 is Stable (not 5.x) and 6.1 is currently beta but the only recommended for ESP32S2 such as MagTag.
And I am not official. ๐
Ok, CircuitPython 6.1.0-beta.2 is one particular chosen Absolute Newest from a few weeks ago. And by it's name, it is a beta release. But it is also the recommended version for MagTag and other ESP32S2 board. Absolute Newest is build every time one PR is accepted. It's name should contain the GitHub hash for that particular change in the code. In addition, when someone propose a PR, artefacts are created and compiled by the CI (and can be retrieved to test that particular build). Cc: @idle wharf
ooo that's nifty ... @feral spoke the kmk readme is recommending the M4 Express or nRF52840 Express adafruit feathers or similar devices due to RAM concerns. so not all CircuitPython boards will be appropriate. the big questions i'd have is how many pins you need to connect the board to your PCBs, and since you're doing a split kbd, whether you need one board for each half.
the 4 pads at the bottom are soldiered jumpers for the current build...but it appears to be 24 pin. ( and yes, there needs to be one for each board )
This is not Feather size, maybe ItsyBitsy?
There are people from Adafruit that build their own keyboard. This may make more sense to them, and there might be a channel for those discussion.
teensy 4.0 has a circuitpython release, and that's probably closer to the intended form factor
Maybe that is the form factor: https://circuitpython.org/board/nice_nano/ (nice! keyboard: https://nicekeyboards.com/)
the nice-nano should work, it's nRF52840-based
Good luck finding one...
hmm..looks interesting...and it's wireless too ๐ What is the chance that @meager fog chimes in on this topic? ๐
Hi here! I'm cross posting a question here that was originally posted on help-with-projects. I'm working on trying to get a low cost switch interface for assistive tech users to plug their audio jack switches into in order to connect to a computer. I've been successful with getting a bluetooth version working using the Itsy Bitsy running circuitpython but when trying to connect the switch using the QT Py via USB/ HID, in the accessibilities setting (Mac 10.1 5) I get the following error: Unsupported switch input. Try a different switch or change the mode of your switch hardware. Is there something in the library settings related to USB connection I can change to have the computer "see" the switch. The keyboard HID works as expected and sends keystrokes without an issue.
welp... the nice-nano being 3.3v doesn't support OLED and LEDs on the keyboard. Maybe I just have to wait longer until the interwebs has a good split keyboard design that I can run a python based firmware ๐
that might be work-around-able w/ level shifters ... most (all?) of the circuitpython boards are going to be based on 3.3v mcu's
I spent a while looking at the assembly code of both the good and bad versions. I don't see an error in the assembly code. It's a bit tricky to read because xtensa uses register windows, which make the registers used for in/out arg passing vary based on the caller or callee, and also based on whether it's a call8, call4, etc. See http://wiki.linux-xtensa.org/index.php/ABI_Interface.
We are debugging https://github.com/adafruit/circuitpython/blob/39233510392107e9087e90757dd96da88b78b0f7...
I'm unlucky with the MagTag ... when I have time and realise that there was a notification email, it is already gone from the shop again. ๐
I guess that this will not change over the holiday period now, so I'll continue to play with my featherS2 ๐
If we could set a watchpoint...
@dhalbert You can set a watchpoint from within the program using cpu_hal_set_watchpoint.
Do I understand right the gist of the issue: you are saving a micropython object in RTC slow memory bef...
I've got a makeshift MagTagAlike with a FeatherS2 and EPD FeatherWing queued up to work on ๐
Kind of how I used Feather M4 + TFT FeatherWing (and still do) before PyPortals were available
This PR adds a few new features to support running a TCP server on the ESP32-S2:
- Adds
bind,listenandaccept, which allow connecting to remote sockets and sending/receiving data from them. - Removes the property that all sockets of type
SOCK_STREAMautomatically use MbedTLS instead of the LWIP socket API, and makes that decision on the fly based on what functions are used first. - Adds in additional logic to the various send and receive functions to determine when to use TL...
@tannewt ready, thanks!
@crimson ferry did you see any Beacon again? ๐
It is so disappointing if you theoretrically know what you want to achieve but C has a different agenda ๐ฆ
I'm trying to come up with a workaround for https://github.com/espressif/esp-idf/issues/6267 by checking if the struct member is NULL for &self->ap_info.record.country, but instead it is actually "<null>". I put an "else" in there, to disregard this for now and use esp_wifi_get_country(&self->ap_info.record.country) instead, which appears to work fine - but when I later try to access "self->ap_info.record.country" I have a backtrace. I think that my approach to overwrite that portion with valid data is not that valid.
@hearty tapir I have not seen a Beacon again
I can at least confirm that none happen during a backtrace either ๐
I saw plenty this night
Our board doesnโt have any bootloader in it. There are two USB ports. One connect to the FTDI chip and another one connect directly to the ESP32-S2 OTG port. We can get one if it is necessary for circuitpython to work.
From: 'ladyada' via Engineering engineer@gravitechthai.com
Sent: Monday, December 21, 2020 12:38 AM
To: adafruit/circuitpython circuitpython@noreply.github.com
Cc: gravitech-engineer engineer@gravitechthai.com; Mention mention@noreply.github.com
Subject: Re: ...
FeatherS2 with ESP32S2
6.1.0-beta.2-124-gfd21ff59d on 2020-12-18
import supervisor
time.sleep(5)
print(supervisor.runtime.run_reason)
supervisor.reload()```repeatedly gives```soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
supervisor.RunReason.AUTO_RELOAD
```but expected `supervisor.RunReason.SUPERVISOR_RELOAD`?
Also get AUTO_RELOAD by typing CTRL-D in the REPL (expected REPL_RELOAD)
Pressing the reset button on the Feather S2 gives microcontroller.ResetReason.POWER_ON supervisor.RunReason.AUTO_RELOAD expected STARTUP?
yes please allocate a VID/PID for CircuitPython. You will also need one for Arduino (when you submit the PR for adding board support to espressif)
@dhalbert You can set a watchpoint from within the program using
cpu_hal_set_watchpoint.
Great to know, thanks!
Do I understand right the gist of the issue: you are saving a micropython object in RTC slow memory before sleep, and (at least) one object field has incorrect value after wakeup?
No, it's not that tricky. the object is created after CircuitPython restarts, when the VM and our object heap should be in good shape. We check what kind of event woke us up and then create ...
@thorny jay you may have nailed what you answered, but didn't fully answer my question. To the beta description and absolute newest are one in the same. If the magtag is running beta code, I would say its not a production board. Why would something like this get released to the masses on beta code?
ah you are saying that the MagTag page doesn't have a stable release
@jaunty juniper if what @thorny jay said, its running the beta which is not a stable release according to their description and absolute newest also does not sound like the stable release either. So my question is what is the stable release for the Magtag?
Sorry, I don't have to deal with this. I do not work for adafruit. Maybe you should wait for working hours in the US and/or contact the support. This is a community and I am an happy customer running the latest 6.1. on my MagTag. I have happily run many of the guide and made my own project with it. Regards.
there is no stable release of CircuitPython for the MagTag yet. but that's fine actually. It's not that the board is in beta, just the CircuitPython distribution for that board
I converted this to a draft while you sort out the CI. Undraft once it's happy and I'll review.
Can you take another look at this @tannewt ?
Related to issue #3782 and PR #3824
Everything seems in order, probably should add a description to the PR. @tannewt aggregate this with my PR?
?serverinfo
Yes, that's what I'm monitoring. I must be sure we have the milestone graphics in time for the milestone
๐
@tulip sleet regarding wake_alarm... delaying saving it does seem to work... I have modified the code and now I save the wake_alarm manually from code.
import alarm
alarm.save()
print(alarm.wake_alarm)
Is there a callback to know whether or not the heap is configured?
@analog bridge There is bool gc_alloc_possible(void). And the new obj allocator should return NULL if there's no heap. But you should not need to make this decision at run-time. we should be setting that object when the heap is ready. It seems like we're calling all this too soon. I am planning to take a further look today.
The out-of-core adafruit_bus_device can handle any kind of bus-like object (for instance, bitbangio.I2C and adafruit_bitbangio.I2C). The new in-core adafruit_bus_device can only handle busio.I2C, and crashes hard on other object types.
We could consider disabling the built-in module until this problem can be resolved.
I'm not sure what kind of HID device switch devices present themselves as. Could you point to some other device that works on the Mac, so I can look up the technical details? Does this work on Windows (assuming Windows also supports switch devices)?
@tannewt hihi please take a look at this issue some time this week, @brentru is blocked on getting MQTT working on ESP32S2 because of it :)
the object is created after CircuitPython restarts, when the VM and our object heap should be in good shape.
I ran some tests and found out that delaying the object creation does seem to work.
I am calling alarm_save_wake_alarm() from user code :- https://github.com/adafruit/circuitpython/commit/16a203febe1678fa6845de51ae051d5844f793c3
import alarm
alarm.save()
print(alarm.wake_alarm)
Above delays setting wake_alarm by 90 ms and avoids the crash.
It looks like ...
I haven't experienced this since I was developing the MagTag library.
Doing a debug build after the gcc10 PR now fails. The failure can be avoided by removing -flto, but that can cause firmware overflow. It has to do with the inlining.
../../py/vm.c: In function 'mp_execute_bytecode':
../../supervisor/shared/translate.c:125:66: error: inlining failed in call to 'always_inline' 'translate': optimization level attribute mismatch
125 | inline __attribute__((always_inline)) const compressed_string_t* translate(const char* original) {
| ...
This also crashes on a Metro M0, so it's not restricted to SAMD51. I made a build with frequencyio enabled.
<@&356864093652516868> It's about 2.5 hours until the last Circuit Python Weekly of the year -- there's no meeting on the 28th of December. Please add your notes to the document if you can. If you plan to speak, at a minimum we ask that you add your name as a placeholder. If you haven't participated before, ping me to make sure you're a member of the circuitpythonistas role. If you're just listening in (lurking), no need to do anything. Link for the notes doc: https://docs.google.com/document/d/1s3bS3z-5WW_0D5NdlRlKpDB-n_aP6eMbeFvtknM59nA/edit?usp=sharing
CircuitPython Weekly for December 21st, 2020 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to particip...
I will not be at the meeting, I have an appointment
Take care!
@ladyada I can fold this into #3854 or do a separate quickfix for it if you'd like. I'd considered removing the block of code that does this myself, but thought it might have been intentional behavior for one reason or another.
@hierophect please chat with @tannewt and @brentru, im not the one using the code :)
Adding info from #3833 - storage.remount("/", True) resulting in RuntimeError on 6.1.0-beta.2
When working through this CircuitPython storage example on QT Py M0, running 6.1.0-beta.2, it fails to work properly - the temperature logging file is never created and the filesystem never switches to read-only. Checking boot_out.txt, I find the following traceback:
Traceback (most recent call last):
File "bo...
Thanks so much for getting back to me. This is an example of a commercial switch interface: https://www.rehabmart.com/product/atec-usb-computer-switch-interface-38517.html. I don't really know how it presents itself but I have been successful with connecting switches just using the standard Arduino library although I can't remember what board I was using. I'm going to try and load the CP 5 firmware when back from work and see if that might resolve things? Tried the Trinket (not MO) and it's HID/ keyboard library. Will report back and see if that works.
@prime flower I'm looking at your recv_into issue since I'm trying to more generally line up the error behavior of socket to Cpython. But I'm trying to figure out how Cpython actually returns the timeout error - from the Cpython Module/socketmodule.c file, it just returns Null https://github.com/python/cpython/blob/03c8ddd9e94c7bddf1f06cf785027b8d2bf00ff0/Modules/socketmodule.c#L3544
This isn't the first time I've seen CPython returning more specific errors in practice than the source code implies it should. Does anyone happen to have insight on why this happens?
@ionic elk When I run MiniMQTT on CPython, it returns a socket.timeout which I can Except. It also does not close the socket if nothing was received within the timeout, the esp implementation seems to close the socket which is problematic for MiniMQTT because the client should poll for new data from the broker/server.
The specific error in the issue occurs here (https://github.com/brentru/Adafruit_CircuitPython_MiniMQTT/blob/cpython-s2/adafruit_minimqtt/adafruit_minimqtt.py#L872), where it attempts to read from a socket within a timeout and then throws an OSError and closes the socket (?).
I'm about to eat lunch but can talk more later.
@prime flower sure, as per your post the problem is almost certainly this block
if (received == 0) {
// socket closed
common_hal_socketpool_socket_close(self);
}
but I'm trying to figure out what to replace it with... I've been rooting around the Cpython module trying to figure out how they do things
yep - points that's it
I guess that Cpython routes everything through sock_call_ex which I think is done to make things asynchronous. It handles timeouts and sorts null returns into errors, rather than the socket functions themselves doing it.
so I don't know how relevant it is. I could simply put in an OS error in that bloc instead of the socket close, but I don't know if that's the behavior we want?
This isn't the only case where I'd like to bring our socket module in line with Cpython so I'm trying to wrap my head around how they do things
Yeah, understood.
Could we instead raise a timeout error if nothing has been received by the server during the time the client attempted to read?
Also - blocking/non-blocking functionality might need to implement something similar. I had issues getting non-blocking sockets working on the esp32-s2 implementation (setting settimeout to 0, https://circuitpython.readthedocs.io/en/latest/shared-bindings/socketpool/index.html#socketpool.Socket.settimeout)
I don't think we have any non-blocking capabilities at the moment
I don't know if we'd need to do that through FreeRTOS or what
LWIP does not have obvious looping operations that we could extract out and put our own background tasks calls into
for now I can roll without non-blocking sockets, I'll just use a timeout and handle that. ESP32SPI impl. of MiniMQTT uses that and is OK.
Could you open a thread on https://forums.adafruit.com and include the details, including the source code you're using? Then ping me with the forum URL and I'll take a look. It's probably a little bit too involved to do interactively here.
@prime flower for now, so you're unblocked, would you like me to just swap out the socket close for a quick OSERROR(0) so you can keep working?
we could always revise it later
I don't think the socket close should be there in any case, but there could be other reasons I don't know of for why that's in there.
Will do ๐ TY!
@ionic elk Ok, sure. I'll try it out once you've added that.
I may be doing something wrong or misinterpreting, but supervisor.RunReason isn't acting as I expect.
FeatherS2 with ESP32S2:
6.1.0-beta.2-124-gfd21ff59d on 2020-12-18
import time
import supervisor
time.sleep(5)
print(supervisor.runtime.run_reason)
supervisor.reload()
repeatedly gives
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
supervisor.RunReason.AUTO_RELOAD
but expected `supervi...
hmmm. I'd like to fold this into my existing PR, since that needs a lot more error stuff added to it anyway, but I may need to check out other things that are messing up the build
@prime flower do you have a local build setup for Circuitpython? You could try deleting the socket close yourself as a branch.
if not I could put in a new PR for it
@ionic elk I dont for ESP-IDF builds
@idle wharf You around?
I'm only partially here, in a meeting, but looking into Circup.
I'm around
You seemed hesitant with your automation PR. Reason?
I was about to merge it and then read closer.
I can't prove that it works locally
Hmm.
But someone who does this all the time might look at it and go... "that's fine."
We can always revert it. Maybe it's worth merging to run it.
Ah ok
I see what you meant. I'll look at it closer and then probably merge it and we'll see what happens.
I'm not certain why it wasn't done that way to begin with.
Which is my only hesitation.
@igrr We've been puzzled by multiple i2c problems in CircuitPython. This one is pretty simple to reproduce, can you take a look and see if you can spot what we're doing wrong with the esp-idf APIs? Thanks!
It seems like circup isn't plugged into the library process since its not in the bundle so maybe it was more of a one off and got lost ? (Totally guessing and assuming stuff)
Right. But automating version numbers seems like a logical desire.
Regardless of ties to lib process.
ยฏ_(ใ)_/ยฏ
Totally agree with you
Anyway, my vote is merge and revert if necessary. You in?
I'm in !
Excellent. I'll do that and release it and see what happens. And have you test it.
You can't fix things if you don't break them. ๐
I'm doing the day job, but can keep an eye on this too. Its easy enough to test it.
Thanks for following up @idle owl !
You're entirely welcome! Thank you for keeping it on our radar.
@idle wharf Green! And PyPI shows it updated!
Test it at your convenience ๐
Make sure it actually runs - in the event that we made it so not everything gets packaged properly.
checking it right now
@idle owl circup list, freeze, show, update all worked. Pip list shows the version correctly. circup --version does not. I'll open a bug for that and will fix it tonight.
@idle owl not fully. but what's up?
There's a screenshot in your Tides Viewer guide that's not accurate anymore. There's no easy way for me to update it except to redo it completely. https://learn.adafruit.com/admin/guides/3194/editor/20984
Accounts
@tidal kiln If you have time today to update it, or potentially reword the guide to not require the screenshot, that would be great. If not, I'll add it to a todo in Basecamp for when you return.
@tidal kiln Oh I didn't even notice you hadn't mirrored pages. Yes, entirely.
thank for pointing that out. i'll take care of it.
I'm going to add a warning that you should leave on that page. Otherwise, it's all you. Thank you!
Thanks for letting us know
have a good one ๐
You too!
Good afternoon all you wonderful folks -- happily lurking, last notes doc of the year updated.
Thank you for updating the doc!
14" in Northeastern PA, 5" in Bergen County NJ
๐ That's teamwork.
@inland tusk Are you participating today?
@strange pike Are you listening in today? Or would you like to participate?
just listening thx
Excellent, welcome!
I always awkwardly struggle to get to the end call button on video calls. So I made this https://t.co/4z4zsxNkeQ
8635
53554
I'll need to set up circuitpython build environment again to debug this, but upon cursory look i don't see anything wrong with I2C APIs usage. Just a few notes, i doubt any of this is the cause of this issue, though:
- https://github.com/adafruit/circuitpython/blob/fd21ff59d996274f7c11e3b907dd81eff411d0b3/ports/esp32s2/common-hal/busio/I2C.c#L93 Binary semaphore is used to implement exclusive access to a resource, instead of a mutex semaphore. Mutex semaphores in FreeRTOS implement priori...
@onyx hinge there is a mild echo through your audio. It's turning green when kattni is talking
weird, I turned down my headphones volume
and i can hear you typing
It sure is nice!
I'm out of alphabetical order -- oops...
Saved PC:0x40028200
Indicates the value of CPU program counter at the time when the watchdog triggered. 0x40028200 seems to be part of the vector table, specifically the Level4InterruptVector. This interrupt level is associated with various debugging features. On the ESP32-S2 these are interrupt watchdog interrupt and memory protection interrupt. Normally this level 4 in...
no problem
@gloomy shuttle Are you listening in today?
yes
Excellent, welcome! We have a notes doc that we use for keeping track of folks, and I wanted to make sure I had you accurately in the list as listening in.
Jeff, if you can read that for me. Thanks.
Help Support the Channel with Patreon: https://www.patreon.com/tastinghistory
Tasting History Merchandise: https://bit.ly/3oLyAhW
Yesterkitchen's Pumpkin Pie: https://youtu.be/lfUaBJSouPk
Scappi: https://youtu.be/o4YmvQt29ko
Follow Tasting History here:
Instagram: https://www.instagram.com/tastinghistorywithmaxmiller/
Twitter: https://twitter...
That is good question... what show are cancel and what show are running. I would love to try to make it for Show & Tell.
Show and Tell is on this week.
@prime flower what board are you using?
@ionic elk for what?
I thought I could get you a board bin mid CI but actually I guess I can't
anyway #3854 has the fix in and should pass CI pretty soon. Fixed the stub stuff
@ionic elk whoo! I'm working on some other tasks before tackling that - how would I pull a .bin from the CI?
didnt know that was possible...
I can actually just build you one rn
๐ that'd be great
but yeah once it passes CI it'll have a list of builds
I made a boot manager for the MagTag by @adafruit to choose between many project from the learn guide.
With a little bit of @CircuitPython in https://t.co/54VinvBcT7 holding a button and turning on select one usage of the connected eInk display.
https://t.co/pTidfyIJnp
@prime flower here's where you find them
sweet, thank you!
@lone axle frame looks useful, can I put other widgets within a frame?
It doesn't have any specif API for adding things inside but that is the intended use yep. For now its just up to user code to position things inside of it.
@gilded cradle Was there some iteration of the MagTag lib that needed ESP32SPI at some point?
It is extending Group though, it could perhaps override append() to handle the positioning and put stuff inside visually.
No...
@candid sun Is there a specific reason why the MagTag Daily Christmas Countdown needs the adafruit_esp32spi library? I'm not seeing it used in an obvious manner.
latkes are good for all occasions
@idle owl i think i was thinking that the magtag library needed it
-
Question re SDA/SCL pins.
-
I'm not sure; did you actually try the W25Q64FV on a board?
Did you mean to add these pins in this PR? There is no board.I2C() defined?
@candid sun Alrighty. I'll ask Noe to test it without.
@idle owl apologies if i was mistaken. i can also test if that's helpful
@candid sun Sure! That would also work.
@candid sun No apology needed - I'm going through the MagTag guides to get a warning added about updating libs, so now's the time to find it. ๐
lots of examples for guides here https://github.com/adafruit/Adafruit_Learning_System_Guides
@idle owl cool cool ๐บ yeah just tested and it does not need that library
@candid sun Excellent, I'll pass that on. Thank you for testing!
Thanks everyone ๐ Happy holidays -- hope you and yours have a safe and enjoyable season.
Thanks.
happy holidays all
@idle owl no problem!
One more year in the bag ๐
@ionic elk Thanks for the quick fix, will test and update the issue later today. Fighting with a compiler and CI script rn ๐
...the discord angry emote is really angry
Woah, very angry indeed. Got up off the wrong side of the bed levels of anger ๐
๐
@lone axle I disconnected you from the voice channel
Thank you
Hi @onyx hinge , I'm not sure it is related but maybe for #3843 this could also be caused by one "fix" by me. I saw it as a fix, but maybe that made your JTAG misbehave: https://github.com/adafruit/circuitpython/pull/3817/files
Here is the notes document for Mondayโs January 4's CircuitPython Weekly meeting. It is on January 4 (we are skipping a week during the holidays) 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/1pOGIqgcxtlSQ3GSRD1UtbvKXwCyFx_1Gx_n2GhrGD8A/edit?usp=sharing
CircuitPython Weekly for January 4, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to participate, ...
The good news is that I see a country code where before was no country code. I'll still need to cleanup the extra characters there and I don't believe what I do is "valid" (even a LinkedIn Learning C-course later).
my MagTag is complaining about display rotation with a fresh install:
File "adafruit_magtag/graphics.py", line 57, in __init__
AttributeError: 'EPaperDisplay' object cannot assign attribute 'rotation'
Have I goofed on something simple? This is a fresh install
ah I guess it's a feature so recent it's not even on my main branch yet
This is as good as it gets ... feels a bit hacky, but the workaround works fine. ๐
If I move the network setup outside the loop... this runs indefinitely.
I wonder if re-re-initializing the network is creating a mess....
....
print("Get on the network")
wifi.radio.connect(config.SSID, config.WIFI_PASSWORD)
print(f"ip: {wifi.radio.ipv4_address}")
print(f"hostname: {wifi.radio.hostname}")
## SETUP BLOCK ##
print("Setup Requests & IO_HTTP")
POOL = socketpool.SocketPool(wifi.radio)
REQUESTS = adafruit_requests.Session(POOL, ssl.create_default_context()...
@slender iron would you mind to have a look at my concerns (that I'd annotate on GitHub) and advise better ways if my solution is invalid or unsecure? (referring to the above screenshot)
@hearty tapir I don't mind looking at things on github. just tag me
is way behind on email at the moment
I have a beta board but haven't poked it at all. The basics shouldn't be too bad. It's the RGB display that will need work.
The โartifactโ version works and appears to fix both the transparency and crash-on-odd-size-BMP issues. Thanks.
@hierophect @brentru You can't just remove the socket close because it is valid sometimes. I think what's missing is a test against the timeout condition. If the while loop has timed out, then we don't want to close the socket.
oh I am having "AttributeError: 'SPIDevice' object has no attribute 'spi'" with the sdcard module but there is already an issue about adafruit_bus_device in core being out of whack, which seems to be the problem
@idle owl tides guide updated - lib folder screen cap updated and mirrored in more pages from magtag main guide
I followed the ESP-IDF Getting Started guide for MacOS and got an error when trying to compile the hello_word example. I'd like to use the IDF for my Feather S2 or MagTag.
FAILED: esp-idf/cbor/CMakeFiles/__idf_cbor.dir/tinycbor/src/open_memstream.c.obj
@solar basin I've never actually used the idf on it's own
what version of the idf are you using?
I pulled the repo and switched to 4.2 because I saw you had targeted that in CircuitPython
The problem is that we are hanging indeifinitely in the while loop in the code below.
void tc_reset(Tc* tc) {
tc->COUNT16.CTRLA.bit.SWRST = 1;
while (tc->COUNT16.CTRLA.bit.SWRST == 1) {
}
}
COUNT16.CTRLA.bit.SWRST is actually a write-only bit. I believe we are checking for SWRST finished in an incorrect wayI think it should be:
while (tc->COUNT16.SYNCBUSY.bit.SWRST != 0) {
We need to check the SYNCBUSY register bit, not the bit we set. Th...
Yup, I'm moving them there now
@tulip sleet has the crash I hit on thursday been solved?
@slender iron nope. I determined that it wasn't a compiler bug, as far as I can tell looking at the assembler code. microdev thinks the object is being created too early. If they defer creating the object, it works
i wrote up my research in the PR
my first prio based on the mtg today is to fix the storage.remount() bug. I was also working on the FrequencyIn bug. I found a problem, but it doesn't seem to be the cause of the bug.
kk, ya it's good to have you bug hunting
- The SDA/SCL pins commit looks like it got added to the pull request after I'd created it when I added those to my fork - wasn't the intention that they be part of this pull
- Yes, tested W25Q64FV working with build of 6.1.0-beta.2 and head.
@slender iron also Limor is quite interested in a second CDC channel, and not necessarily gating that on the presence of dynamic USB descriptors. Second CDC is a 6.2 kind of goal for the new year
could you push a new commit that removes the SDA and SCL pins?
Reported by @neradoc on Discord, this issue is separate from other problems encountered with adafruit_bus_device.
It wasn't immediately clear why adafruit_sdcard uses this property (efficiency?) but as the property was not _spi it was arguably fair game. Possible resolutions that occurred to me:
- change
adafruit_sdcardto not use the property and leave in-coreadafruit_bus_deviceunchanged for the purposes of this PR - add the property to
adafruit_bus_deviceand leave `adaf...
@jaunty juniper I think that's distinct from the other issues I've reported, so I filed a fresh issue for it. Thank you for your report!
@tulip sleet I think we should do dynamic descriptor
with the move memory work from cwalther it should be pretty straightforward
Hey @slender iron or dan, question for you
@slender iron I think there are two levels: one is just turning existing devices on and off, and the other is allowing user-specified HID descriptors. Also there's USB and there's HID. The CDC is not HID-related.
but we can strategize later...
I'm writing some driver code for a board I plan to develop support for with circuitpython, and I am starting with the C code side of it. Do I need to define a specific i2c read/write method for either the C or circuitpython driver code?
if the chip you are using is already supported, then you don't need to write driver code
this is how the device expects i2s to be written to
as far as I can tell, it isn't supported
yet
sorry, I misunderstood, this is an I2C device... I was thinking you were porting CPy to a new boqard
I think @meager fog may be developing a board around the Atmel QT touch chips but I'm not confident
if the chip is similar to one we already have a driver for, then you can probably take some of that code. You don't need to write C code
Add lots of touch sensors to your next microcontroller project with this easy-to-use 12-channel capacitive touch sensor breakout board, starring the MPR121. This chip can handle up to 12 ...
not atmel, but just came out
yeah, MPR121 is an older cap touch chip and she did a Great Search about capacitive touch chips which is sort of what inspired the board I'm working on
I am writing both circuitpython and an arduino library for it. Kind of a big undertaking for me since I've not really done this before
take a look at existing drivers that access registers on I2C peripherals. I don't think what you want is new, it can all be done in CircuitPython. We have the register library to help
I'll take a look at the register library, I think Kattni suggested it as well
@tulip sleet think your ble fix pr should go in a 6.0.1?
what do you think the timeline is for 6.1 stable? I think it's kind of unknown, could be 2-4 weeks.
yes, it probably should, and also the storage.remount fix
ya, I agree. I'd like to do another beta
which looks quite simple; i am fixing it now
i have to take the adafruit magtag rename out of the ble PR
i can make a new pr and cherry-pick the ble fixes out of the main PR branch
These all look good to me! I think we should merge them into 6.0.x though so we can do a 6.0.1 release.
either way
let's merge this PR and I'll make a new PR with git cherry-picks.
no
i am a bit baffled by the frequencyio bug, which also rightly should go into 6.0.1
fixes should go in their release branch first
so we can merge the release branch back into main without two fix commits
ok, no problem, i will revert the magtag name commit and repush and
๐
will re-request a review
I think we should have the second CDC available as a UART compatible (aka stream). It'd be similar to how we have objects for MIDI stuff.
Looks good! One comment that you can make a follow up PR for if you like.
Note, most boards name this pin VOLTAGE_MONITOR or BATTERY.
I think so. We can re-open if it crops up again.
I'm all for expanding what we reconnect on. Perhaps we need to invert the test and only not reconnect on the reason we get when we've triggered the disconnect.
I was hoping the new reset code would preserve it by leaving the mux alone. I think the right fix is to preserve any pulls as well on those pins.
This seems very niche because it depends on pasting multiple lines into the REPL. Does it work as expected when you do each line individually?
Maybe we aren't correctly supporting open drain outputs in the digitalio code.
This might be fixed in my PinAlarm PR. It tweaks how we notify the CP task from other tasks.
@digixx Please make a PR! That's an awesome find!
Note that this alternative numbering is an artifact of ESP Arduino not being able to remap numbers. They don't have a layer of indirection for pin numbering (yet: https://github.com/espressif/arduino-esp32/issues/4479). This impacts CircuitPython when folks use the arduino numbering on the board itself.
TinyUSB has a dual CDC example already here: https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_dual_ports
@gamblor21 We should check the type of the incoming object and raise an error if it won't work. That will prevent the crash.
In the longer term and under a compile flag, we can have the C code either recognize bitbangio or use the Python mechanics for the call.
I'm not sure if there is a reason that is 1:1 with manual disconnect, so maybe that's better as a variable. There's also the possibility of manual disconnect coinciding with some network issue that also triggers a disconnect (probably rare).
This mentions Reasons for various disconnect causes, but doesn't mention a Reason associated with with a manual disconnect.
What is the original bad code? Maybe sockets are being leaked when recreating the Session.
Ok, no problem! Please don't advertise it as CircuitPython until the changes are upstreamed.
This only matters when a native module holds onto a pointer usually. The Python references will be updated internally. (We only move at the end of an import before multiple copies can be made.)
during discussion today i asked if we could implement secondary CDC UART on one or two platforms that have the spare endpoints now, rather than blocking on a dynamic descriptor implementation
Thank you for the PR! Just a couple comments.
I wish my pin alarm PR was already in. I heard you hit the same issue I did. I hope we can figure it out soon.
Please factor this out into the touch alarm code. (See my pin alarm PR for how I've done it there.)
Does this work when pretending to deep sleep? Generally, you can use an internal callback to notify the main CP task to wake back up.
Looks good to me! Thank you!
In my mind I've got two clear use cases: 1) something like image transfer, where a device with a camera needs to backhaul a small .jpg or something for processing on a gateway. 2) (my current need) in-the-field live firmware update. A gateway advertises some kind of FW update service where a device with a lower version can request the new
code.py, copy it over, and restart.
I'm picturing that the device will have a BLE Server that allows a Client to read and write its files. The "hey I...
I've followed up with recommendations on #3854
What I'm reproducing now is a wifi.radio.connect issue and possibly the original issue is fixed.
Consistent failure on the 2nd loop fails.
>>> import wifi
>>> from time import sleep
>>> import config
>>> import ipaddress
>>> while True:
... wifi.radio.connect(config.SSID, config.WIFI_PASSWORD)
... print(f"Ping: {wifi.radio.ping(ipaddress.ip_address('8.8.8.8'))}")
... sleep(60)
...
Clean build on main
idf.py --version
ESP-IDF v4.3-dev-1198-gd0674...
I think I know how to do that (or where to look to figure it out). I'll try to understand how the other bus-like objects work but if I catch someone on discord one day probably could be explained quickly if time works for that.
@slender iron I wanted to help push the ntp library over the finish line.
Should I send you a PR or would you prefer I go direct to the NTP repo?
(Same as #3848, but applied against 6.0.x instead of main; MagTag name fix not included because board is not in 6.0.x)
- Characteristic and descriptor
max_lengths can be zero. Fixes #3746. - Assure that
start_scan()timeout is either zero or >= interval. This is a guess for this fix, but it coincides with working values reported in #3826. Fixes #3826. - Assure that
start_scan()max timeout is not too large for auint16_twhen passed to nRF SD. Fixes #3340. - Fixes small adve...
BLE changes applied against 6.0.x instead in #3861. Closing this in favor of that PR. Will merge 6.0.x changes into main afterwards.
Sure, let me take a look at it this evening.
Fixes #3709.
Undoes https://github.com/adafruit/circuitpython/commit/bda3267432aee57e704a20308b724369cceeb6ca from #3680. The problem is that a board that starts unconnected does not start with unejected drives; they should be ejected when boot.py is entered.
The original change saved 20 bytes. I tried reversing the sense of the ejected[] array, calling it not_ejected[]. (mounted was too confusing, because it has two meanings: one for TinyUSB, and one for the filesystem.) But t...
Fixes #3831.
Add "Adafruit" to MICROPY_HW_BOARD_NAME for a few boards for which it was missing. This makes these boards consistent with the other Adafruit boards. In particular, it makes them easier to find in the Support Matrix in readthedocs.
yes! think about interfacing with processing, unity, cnc etc. just need bidirectional byte stream (e.g. like pyserial which is the cpy equiv)
Resubmitting clean pull request as requested.
Clean pull request is fine, but not required. I'll use the other one, thanks!
I think that the problem may be that the .wake_alarm is not being protected against garbage collection. I am pursuing this theory.
I was working in a clone of tannewt/circuitpython, instead of as a remote, so I don't seem to be able to push to the PR. However, here is a patch file with fixes that prevent the crash.
0001-mark-alarm.wake_alarm-during-gc-sweep.patch.zip
The test program above is acting oddly, so I wrote a simpler program. Tested on battery power on and USB (simulated deep sleep).
...
^^ @slender iron I think I have a fix for the pin alarm crash. I committed it locally but can't push to the PR branch:
halbert@salmonx:~/repos/tannewt/circuitpython$ git push
remote: Permission to tannewt/circuitpython.git denied to dhalbert.
fatal: unable to access 'https://github.com/tannewt/circuitpython.git/': The requested URL returned error: 403
I'm a little confused because I thought that wasn't the usual error when I didn't have maintainer permission to push to a PR. But maybe I'm wrong.
in any case, you can apply the patch file to try.
Wow, that sounds amazing! ๐
(I mean that the issue is fixed, not that you have permission issues :))
This kind of error happens more often than I would like. We create an object on the heap, but forget to make sure that whoever is holding that object is included in the gc mark phase, so that the original object is not garbage collected. The holding pointer is in static storage and we forget to have it scanned by the gc.
One way this is done is to include the pointer to the object in the ROOT_POINTERs. The other is to write a special gc routine that knows where these pointers are. It should be on a checklist that whenever we create a statically allocated thing, we need to make sure that if it holds any Python objects, they get included in gc.
I'll push a PR this (my) evening for "wifi.radio.ap_info.country". I'm not sure if I'd need to keep this detail in mind as well.
well, I'll take a look when reviewing ๐
That would be great, thank you ๐
I've completed LinkedIn Learning courses on C Essentials, something on C Structures and Embedded Applications in C - but taking courses doesn't teach experience ๐
The radio object is a singleton, and has its own gc routine: see common_hal_wifi_radio_gc_collect() in common-hal/wifi/Radio.c
Yes, that is the one you added ๐
most embedded programs don't have gc ๐
(when the bug hunting for i2c remove/deinit went on)
so if you have added a Python object to the wifi_radio_obj_t struct, it needs to get added to that routine
I'm planning to add a debugger (jlink or similar) to my setup - but I need to be careful not to make it a shopping spree
https://www.adafruit.com/product/3571 is fine and only $20
I'm overwriting an existing structure partially to workaround the ESP-IDF bug that is currently present - therefore this may be a cornercase.
but it only helps a little with ESP32-S2 debugging, providing the basic JTAG interface
Yes, that is the item I have already bookmarked. This will certainly be in the shopping cart sometime soon. I prefer to combine some parts to make the shipment more economical.
@tulip sleet I literally just woke up thinking that was likely the issue. The extra log causes the pointer to linger on the stack and get collected
@tulip sleet do you need an ssh remote instead of an https one?
no, i have not needed an ssh remote when doing this in the past. In any case, I think you can just git am the patch file. I made the patch from the top of the repo
Kk
@slender iron can you remind me why do we not use the "stub" for uploading esp32s2 firmware with "make flash"?
nice find @tulip sleet ๐
one question... Is cleanup_after_vm() called after _setup_sleep_alarms()?
@analog bridge it is after a deep sleep, because the VM is shut down, since the program exits
@onyx hinge I think it was because the USB bootrom can't do it
@gilded cradle weren't you successfully using the stub with the USB on magtag to program it?
Either way works for me
@onyx hinge yes, I use stub loading. It writes a small binary program directly to ram and tells it to run.
@slender iron it may possible have to do with your repo not being a direct fork of adafruit/circuitpython, but of micropython instead. Not sure. I tried a couple of other things, not worth spending a lot of time on.
@slender iron should I wait for PinAlarm pr to get merged... than I can resolve conflicts with TouchAlarm
yes please
you may want to modify your code based on imitating the final version of pin alarm
maybe, i never got a .wake_alarm that was not None, but the simpler example seems to be good, and prints the pin name
or maybe it was a display refresh issue, but I'm not sure.
i added the sleep_memory thing to make sure it was cycling
@slender iron flashing magtag (with a debug build) takes ~17s with stub, ~37s without stub. --after-reset=hard_reset doesn't work over USB, but the stub DOES work and is faster overall. Maybe some older esptool did not have a working stub for usb? github shows that was added in May 2020..
Thank you for the pointers @igrr!
- I eliminated the semaphore (it is used to implement Python-level locking of the device, and is not relevant to the code that causes the problem) without affecting the outcome
- I did not have success setting a gdb breakpoint at *0x40028200, it was never triggered.
- I did observe that during a "normal" failed I2C probe, i2c_master_cmd_begin() returns -1. However, when the I2C device is re-used, it is returning ESP_ERR_TIMEOUT.
- If I introduce i2...
If it works now, go ahead and change it
Very long ago, this was apparently not supported in esptool yet, at least when operating over USB CDC. This now works just fine, and our esp webtool relies on it as well. It makes flashing faster, too.
@slender iron thanks, done!
hmm does the blackpill have markings for i2c? how'd these pins get picked? im for this PR, just wanna make sure we are consistant :)
ok, I've pushed the fixed version of pin alarm. Thanks @tulip sleet !
So, I finally managed to get the IDF working, but I can't find any instructions for flashing CP back onto the FeatherS2
Hi @djix123, thanks for the PR! The Blackpill does not have silkscreen markings for a default I2C channel, and there are actually 8 different equally viable combinations of I2C outputs on the pins it exposes. We don't typically mark pins as default unless they are clearly outlined on the silkscreen as such.
If you selected these pins for compatibility with python sketches written for the Feather F405, please note that:
myi2c = board.I2C()
is functionally identical to:
`myi2c = busio....
@solar basin hold down the DFU button, and press reset. Then it will be in bootloader mode and you can use esptool.py to upload the .bin, or follow simpler directions in the magtag or Metro ESP32--S2 guides. You can install a UF2 bootloader so you can load UF2's in the future.
@solar basin esptool.py erase_flash
then https://feathers2.io/install_uf2.html
then drop on the latest .uf2 firmware from https://circuitpython.org/board/unexpectedmaker_feathers2/ - thats how I do it ๐คทโโ๏ธ
could be because we have board.I2C() in many example codes and they have a confusing error that folks may think means I2C is not supported. (i am not a big fan of board.I2C() for this reason even though it is easier to read )
Thanks!!!
after entering bootloader mode as @tulip sleet mentioned
You all are awesome as usual!
@slender iron is there some debugging you want to do on light sleep? I started reviewing days ago but stopped due to the bug.
fwiw, re: --no-stub, I found that I didn't need it when using the UART-to-USB, but did need it when loading over native USB (esp32-s2)
@tannewt can you double check if you submitted your review form in the web page? I don't see anything on my PR.
I have run into an issue... cleanup_after_vm() is called after _setup_sleep_alarms() and resets the previously set touch configuration.
Is it advisable to use something like peripherals_touch_never_reset() to prevent this?
@analog bridge, yes, exactly, you could use the same technique used for pin alarms, if that makes sense in this case. In any case you'll need to special-case those pins.
using never_reset(pin) won't work here as cleanup_after_vm() calls touchpad_deinit().
I am using prepare_for_deep_sleep() which is called from alarm_enter_deep_sleep() for touchpad configuration in case of actual deep sleep but the issue here is with pretend-to-sleep whoes configuration is set in _setup_sleep_alarms().
Yes, @ladyada - added them because of the many examples that use board.I2C() ... the actual pins chosen - board.B6/board.B7 are the defaults that the STM32 Arduino core chooses for this board.
i guess thats ok then! better than nothing :D
I think it's ready
I think we'll want to stop doing light sleep at all but that's an existing bug
esp light sleep shuts everything down
@analog bridge can you just keep some info that touchpads will be used for sleep, and suppress the call to touch_pad_deinit()?
@slender iron I think "Circuitpython Light Sleep" != "ESP32-S2 Light Sleep". Other chips make it easier to keep some peripherals awake during a lighter sleep, I would think. We could make CPy Light Sleep for the ESP32-S2 not doing anything more than time.sleep() does.
I was just writing up installation instructions for my new MagTag projects and I realized how many libraries are necessary just for a plain MagTag installation. 10! That's at least 3 more than a few weeks ago when I started. What's the point of refactoring if the new libraries are required anyway? It just makes it more complicated for newbies. I can think of at least 3 libraries that I'm not using, fakerequests, neopixel and io. (i guess neopixel is used to flash when its booting up or starting the network or something)
although I used fakerequests during development and it rocks
@tulip sleet ok... I'll go with peripherals_touch_never_reset() to suppress touch_pad_deinit().
or could you just pass params to touch_pad_deinit()
that would require altering peripherals_touch_reset() function which will break consistency with other module reset calls
@alpine nimbus the refactoring makes it easier to keep all the "portal"-type code working the same way. ... We have been talking about a way of specifying a single URL that would download a custom zip package of the specified libraries
but that requires web infrastructure work; not hard, just another thing to do
@tulip sleet Thanks. That would be. nice
right, I think cp light sleep should idle, not esp light sleep
@alpine nimbus https://github.com/adafruit/circuitpython-org/issues/491
@alpine nimbus you can also use the magtag without the library
splitting the big library apart should hopefully make it easier to use the pieces you need
The neat thing about the magtag (or at least my project that uses it) is that you don't need to do soldering or know anything about electronics and not much about software. I'm trying to make it as easy as possible for non-tech people to set up so that would help a lot.
Thanks for the PR! Sorry I left these pending. Thanks for the ping!
I don't think you want to do this because you may leak sockets. Instead, detect if you've timed out here and then throw the OSError.
bool timed_out = false;
while (received == 0 &&
status >= 0 &&
!timed_out &&
!mp_hal_is_interrupted()) {
timed_out = self->timeout_ms == 0 || supervisor_ticks_ms64() - start_ticks <= self->timeout_ms;
Then, you can check timed_out after the loop to raise the OSError on timeout.
Yes, we should have a ssl.SSLSocket. The server API is separate.
One person already told me he bought a magtag because of it although he's a software dev so I doubt he'll have any trouble.
@tannewt can you double check if you submitted your review? I don't see anything on my PR.
Yup! They were pending. Sorry about that. You should see them now. Thanks for the ping.
Oh, I just thought of something. Maybe in the future MagTags will ship with software already loaded so people won't need to install any libraries at all. The board in the new adabox is like that but I don't know about standalone boards.
@anecdata I think the simplest thing would be to trigger a disconnect and see what reason you get back. :-)
during discussion today i asked if we could implement secondary CDC UART on one or two platforms that have the spare endpoints now, rather than blocking on a dynamic descriptor implementation
We certainly could. I think that'd get us most of the way to supporting dynamic descriptors. We have most of the prerequisites in place already.
I think I know how to do that (or where to look to figure it out). I'll try to understand how the other bus-like objects work but if I catch someone on discord one day probably could be explained quickly if time works for that.
Feel free to mention me when you have time. We can also coordinate a time too.
@gravitech-engineer hi please reply to the request so we can add support
Learning guides aren't the only place this would be used. I just released a small MagTag project on github with an eye toward making it as easy as possible for non-technical people to use. Currently there are ten libraries that need to be installed and with the refactoring I imagine that will increase. Instead of listing them all, I pointed people to the MagTag guide. It would be even nicer though if I could just give people a single link.
yeah we would ideally use circup in some way. as our boards/projects get more complex, having it built into the IDE could be beneficial
I sent a PR to Tannewt to finish up his NTP changes.
https://github.com/tannewt/Adafruit_CircuitPython_NTP/pull/1
When that PR makes it to cp/main, I'll close this. (woo hoo!)
Looks good to me, with some minor naming changes. But what do we want to do about light sleep? Is the code here fine for idle-based light sleep?
Is this comment still correct? It looks like all the messages are attempted to be written out no matter what now (no longer depedent on serial_connected_at_start state).
Let's regularize the naming here, to either use an underscore or not. Probably time_alarm is better.
I got confused with low and high pin numbers here. See above.
@ruby lake where did you get that link from?
one moment
The link is contained in the sentence "For example, the Circuit Playground Express guide has a great page on how to install the library bundle for both Express and non-Express boards."
I am using alarm_touch_touchalarm_ to maintain consistency with the python side.
@ruby lake - fixed - that phrasing was from ages ago when the entire bundle could fit. Thanks!
I figured some things just sneak into the cracks, I just happened to by tinkering with a gps feather.
I don't think we are entirely consistent elsewhere as to whether CamelCase turns into under_score or not. Either is fine with me.
@tannewt Can you do it for me? I have problems commit a request do to GPG issues on Ubuntu.
Tons of good food for thought, thanks!
I'll do underscore because it's easier to read.
@FoamyGuy we recently fixed a few things with displayio and eink, do you want to try again?
Actually I take that back. PulseOut, TouchIn and IncrementalEncoder are all no underscore.
To reject things with the wrong type, you can simply check that the type is the desired one, similar to this code in canio:
mp_obj_type_t *type = mp_obj_get_type(match_objects[i]);
if (type != &canio_match_type) {
mp_raise_TypeError_varg(translate("expected '%q' but got '%q'"), MP_QSTR_Match, type->name);
}
To make it work with busio and bitbangio (core implementation) you can just check the object's type and make a decision, similar to thi...
could we do a duck-typing thing where we just look in the type's dictionary for the operations we want?
I haven't found a way to do that from CircuitPython, so I suppose it's about time to begin the trek up the learning curve of how to make changes to the core ;-)
I understand the 3 methods you suggested @jepler. The first one is probably pretty quick to do, the second I'd have to figure out how to test bitbangio (core). Would the third with pure python fix all the problems? Would that result in a slow down for having this all in the core (the original point?).
I understand in the theory of what you're suggestion @dhalbert but I'm thinking that will take me a bit longer to figure out.
I should be around on discord for the next bit if someone want...
The third suggestion is how duck typing is implemented in the core (to the best of my knowledge)โin that case, it calls the _transmit method on the self_in object, no matter its type. If the method was not present or the argument requirements weren't met, it would throw an exception.
@onyx hinge Just to confirm here would the 3rd method for bus device be the best then? It will probably take me a bit longer (maybe) but if it will work better no issue
I believe it's the best all-around solution for compatibility. For code size and performance, well, it needs to be tested. but before it can be tested, it will need to be written.
I think right now we have a little bit of wiggle room on binary size due to the gcc10 transition, though I don't know the exact "free space" figures for the most constrained builds.
It doesn't seem that hard just have to wrap my head around it. If its too slow could probably do a detect native I2C and if anything else do the python
that's sure an alternative -- mix two approaches
Apologies for giving you background you didn't need, but perhaps it will be helpful to someone else interested in the task
No worries it was all super helpful, I just want to make sure I do the best solution to it
I found when I did it the first time I used other modules as examples, having someone point out look here and there is a huge time saver, rather then having to hunt for them
After tracing this more carefully this is due to raising an exception in an interrupt handler, which does not work properly:
https://github.com/adafruit/circuitpython/blob/8b03951fee166b1eea06d114fc347982b7b186bf/ports/atmel-samd/common-hal/frequencyio/FrequencyIn.c#L85.
This is inside frequencyin_emergency_cancel_capture(), which is called from frequencyin_interrupt_handler().
frequencyin_emergency_cancel_capture() gets called almost immediately after the FrequencyIn() is create...
Yep, I will try this out tonight.
Fixes #3788.
More info in https://github.com/adafruit/circuitpython/issues/3788#issuecomment-749839525:
Remove this mp_raise:
https://github.com/adafruit/circuitpython/blob/8b03951fee166b1eea06d114fc347982b7b186bf/ports/atmel-samd/common-hal/frequencyio/FrequencyIn.c#L85.
This is inside frequencyin_emergency_cancel_capture(), which is called from frequencyin_interrupt_handler(). Interrupt handlers should not raise exceptions.
Simply commenting out the `mp_raise_RuntimeError()...
Looks good to me, with some minor naming changes. But what do we want to do about light sleep? Is the code here fine for idle-based light sleep?
I've removed ESP light sleep and now just idle. I also tweaked the messaging in main to add "Code stopped by auto-reload."
Please take another look!
When the necessary socket bind/accept/listen support is added for esp32s2, would that theoretically allow waking from light sleep when the device receives an incoming connection? Or would simply keeping the wifi connection alive rule out sleeping?
Looks good to me! I did not run further tests.
I'll have to revise the sleep guide about light sleep power consumption (doc and graphs), and see if we see any reduction during the sleep.
@night perch we ended up not being able to use ESP32-S2 light sleep because it disables nearly all the peripherals. So we are just going to idle now during "light sleep". We will do some measuring to see if there is some power consumption reduction while idling.
Indeed this is fixed using the newest from S3. I know it was still an issue on the beta.2 release, but I didn't try the ones in between, not sure exactly where the fix came.
Adafruit CircuitPython 6.1.0-beta.2-171-g8b03951fe on 2020-12-22; Adafruit MagTag with ESP32S2
Got it, thanks. Great tutorial you wrote on sleep btw.
thanks! it will need revision soon: we'll add pin alarms and touch alarms when they're merged in
Another use case: interactive experience, good for teaching
- You have a LED matrix display (could be any other display)
- you want to enable/disable a certain pixel from REPL
right now, whenever I type something on REPL, I see it on the display as well, and the pixels get "erased".
Is this line in start_station redundant? https://github.com/adafruit/circuitpython/blob/8b03951fee166b1eea06d114fc347982b7b186bf/ports/esp32s2/common-hal/wifi/Radio.c#L59 looks like it sets the wrong enum type/value, and it's overwritten correctly anyway in connect shortly after start_station is called: https://github.com/adafruit/circuitpython/blob/8b03951fee166b1eea06d114fc347982b7b186bf/ports/esp32s2/common-hal/wifi/Radio.c#L157 (scanning also calls start_station, but I don't think it requires any particular interface config/constant)
Weโre in the process of getting VID.
Thanks
Sharnon
From: 'ladyada' via Engineering engineer@gravitechthai.com
Sent: Wednesday, December 23, 2020 1:18 AM
To: adafruit/circuitpython circuitpython@noreply.github.com
Cc: gravitech-engineer engineer@gravitechthai.com; Mention mention@noreply.github.com
Subject: Re: [adafruit/circuitpython] Add Gravitech Cucumber R board definition (#3349)
@gravitech-engineer https://github.com/gravitech-engineer hi please reply to the req...
nevermind, found a solution that works for me.
Compiling it with make CIRCUITPY_TERMINALIO=0 does what I needed.
Can you provide some boot or commandline option
for usb-storage to be directed towards SD card instead
of internal flash?
Good catch! I'd even say that https://github.com/adafruit/circuitpython/blob/8b03951fee166b1eea06d114fc347982b7b186bf/ports/esp32s2/common-hal/wifi/Radio.c#L59 will not have any effect, as it has to be the wifi_interface_t interface https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv419esp_wifi_set_config16wifi_interface_tP13wifi_config_t
It likely errors out, we could check with ESP_ERROR_CHECK(). I wonder now, if this is the corner case that you mentioned in which an APSTA is visible .... assuming you do import wifi and scan, but don't issue a connect.
I've now tried a lot of different combinations and still I have no luck to catch a beacon.
I haven't caught another either, and I'm starting to question my sanity at the time I did ๐
This adds support to access the country code as announced by the Wi-Fi access point (if it announces it).
The workaround via esp_wifi_get_country() is necessary as esp_wifi_sta_get_ap_info() returns wifi_ap_record_t where wifi_country_t is empty. Reference to ESP-IDF bug report/issue: https://github.com/espressif/esp-idf/issues/6267

The discussion with @t...
I wonder if "git" wakes up in the morning and thinks "What weird effect could I come up today with to confuse BennyE?!"
I thought once that I got it, but it was the the neighbours robot vacuum cleaner (they'll show up as ECOVACS and they have an espressif inside)
I get a bunch of Espressif "Sentry_" SSIDs with some hex digits, I assume they're some kind of security device in the neighborhood or in visiting cars
(I do remember that you mentioned that it was your board mac + 1)
From a security POV many of the security-devices are questionable .. ๐
(yes, the Beacon MAC was base+1, as expected for AP)
@tulip sleet I don't really understand why the CI is unhappy with PR #3868 but at least all the xtensa builds were successful. I should probably apply the following to my PRs "Am I confident to make this a PR without a DRAFT PR first? If yes, make it a DRAFT" ๐
There is a new blank line at the end of common-hal/wifi-Network.c. That is the only error I see right now; it's checked by the pre-commit job
the trailing whitespace checker checks for that and also missing newlines at the end of files. Some editors have a setting or a plug-in to automatically clean up trailing whitespace on each line and at the end of a file, and ensure that they end with a newline.
I'm using vim in my Win10 Ubuntu WSL. I haven't done any specific tweaks to make tabs spaces or similar. Do I need to do something about this? I'm planning to add some more wifi related enhancements.
don't use tabs; always use spaces. But there are vim solutions for this: https://unix.stackexchange.com/questions/75430/how-to-automatically-strip-trailing-spaces-on-save-in-vi-and-vim https://vi.stackexchange.com/questions/22497/how-do-i-trim-whitespace-automatically etc.
I've always manually hit the spacebar, there should be no tabs nowhere ๐ I'll look at the links, thanks
i've found it good practice to check w/ git diff --ws-error-highlight=all before committing or submitting PRs ... it's not a big deal if i'm changing whitespace in my own code, but for contributing to a project i try to minimize changes as much as possible
@crimson ferry , are you going to fix the Radio.c line 59 or should I?
I'll make this part of my workflow. Thank you
https://stackoverflow.com/questions/97694/auto-indent-spaces-with-c-in-vim might save you time. I use the tab key all the time (in emacs), but it's set up for spaces. Emacs has sophisticated autoindent modes. I was present at the creation of vi and used it for several years when I had to (1978-1984), but returned to emacs
@hearty tapir Feel free, I'm still very early in the learning curve on C/C++, structure of the core, etc. I'm hoping I can focus on code and let GitHub do the builds for me (I know nothing about building software), but it's going to be a while before I'm comfortable PR-ing anything.
of course many more modern editors like vscode also have nice autoindent
(...just when I thought I was making some progress understanding parts of Radio.c (which make some sense being tied to a good API), I remembered about shared-bindings which lives between languages and is still pretty mind-boggling)
I saw the shared-bindings during some of the deep-dive streams already and therefore took something that existed already (rssi) as example and walked through the files to understand the structure before adding the country code. I picked the country code, as I thought it would be the most simple element and didn't (possibly) imagine I'd run into the esp-idf bug that I now (hopefully) workarounded.
That's my plan too, try to find something simple that has good close templates in other features.
I tested with adafruit_bitbangio and that works on Kaluga. However, on further inspection, adafruit_bitbangio.I2C doesn't seem to use drive_mode=digitalio.DriveMode.OPEN_DRAIN which is a surprise! I thought that would answer the open drain question but I guess it doesn't.
@slender iron I am going to start release notes for a 6.0.1 release that includes the merged and pending fixes: BLE, remount (EDIT:remount error started in 6.x, so not included), FrequencyIn. ... Do you think it's worth backporting the json speedup? that is well-loved and is the only other thing I can think of at the moment.
I wired up a couple of LEDs and can confirm that open drain doesn't work, or at least not as I expect it.
In push/pull mode, one LED lights brightly depending whether the pin's value is True or False.
In open drain mode, neither LED lights no matter whether the value is True or False. However, the upper LED should light when value is False.

I did verify that in input mod...
This appears to be another problem due to adafruit_bus_device-in-core. The pure Python version first tries a zero byte write to probe for the presence of a device at an address, though if that is not possible (when is it not possible?) it also tries a 1-byte read:
try:
self.i2c.writeto(self.device_address, b"")
except OSError:
# some OS's dont like writing an empty bytesting...
# Retry by reading a byte
try:
...
Several issues have been found in the implementation. While they're unresolved, it may be better to disable the built-in module. (This means that to work on fixing the module, it'll be necessary to revert this commit)
Related issues include: #3821 #3856
I agree it's better to revert this for now to remove the regressions.
main() in main.c is run once and only once, on power-up, right? So I'm guessing that the case where wifi_inited would be true when port_init() calls wifi_reset() is RFU; ditto for the use of wifi_ever_inited (we never deinit wifi currently except at power-up)?
I replicated this, but it seems to depend on the host computer!
On Linux using picocom: this works:
Adafruit CircuitPython 6.1.0-beta.2-125-g3b4c14f3e on 2020-12-21; Adafruit QT Py M0 Haxpress with samd21e18
>>> import time
>>> time.sleep(2)
>>>
On MacOS 11.0.1, using screen, I have to type return to get the prompt to appear:
Adafruit CircuitPython 6.1.0-beta.2-125-g3b4c14f3e on 2020-12-21; Adafruit QT Py M0 Haxpress with samd21e18
>>> import time
>>...
@crimson ferry thereโs an interesting post on ESP32 forum about making WiFi that reliably can be started and stopped. https://esp32.com/viewtopic.php?f=13&t=18633
Espressif ESP32 Official Forum
Iโm not sure when WiFi is stopped in CP though.
Maybe when code.py vm is killed and you move to REPL vm?
I played around with that, when we tried to fix the i2c issue. We no longer remove the event loop and also netif init only once
That is the function I also suggested to Scott, but after the i2c fix by Bruce it was no longer necessary
Either way is fine with me. (I imagine you already decided.) Iโve got a dentist appointment now but will be around later
@slender iron I didn't decide but did put the json fix in the release notes. I will do some PR's for you or jeff to review
considering how slow the old json is, i think it's almost a bug that got fixed
@idle wharf afaict, wifi is only stopped (and [re-]started) using radio.enabled. Thanks for that link, I hadn't spotted that call in the API yet.
I scan that forum every couple of weeks... occasionally asking questions.
I had been using enabled to try to reset wifi for a while to try to get around a bug, but it didn't do much discernible... maybe related to that post
You still hit an issue with Wi-Fi?
WiFi does have some things that need to be worked out.
If you do while True: connect, ping, sleep(60) you will fail on the 2nd or third loop.
This backports #3728 to 6.0.x. It would be great if someone else could test this, because I'm not sure what a good simple test would be.
@hearty tapir it was a long shot to try enabled, probably are Requests issues
@tulip sleet You wouldn't happen to have a .uf2 or .bin for the magtag for the very latest version of CircuitPython (with the Alarm library that had SleepMemory added) would you? I'm working on building it myself but it seems to be a pretty long process the first time
@idle wharf common_hal_wifi_radio_connect doesn't currently check for existing connection/enabled, but I'm not sure the implications of that... there is a note on esp_wifi_connect: "2. If the ESP32 is connected to an AP, call esp_wifi_disconnect to disconnect." but there isn't an error response that says, "hey, you're already connected" so maybe it's no problem
none of the Espressif examples I've found have restart or even shutdown scenarios for connections or wi-fi running or wi-fi init, but they do say netif_init only once, and netif_deinit isn't implemented
this is why there was โdestroy()โ used
If the fix you're wanting is merged, you can get latest builds off the S3 link on the board specific page. https://circuitpython.org/board/adafruit_magtag_2.9_grayscale/ Click the "Absolute Newest" button
@hearty tapir which led to my question about why we need to call wifi_deinit and netif_destroy in wifi_reset if it's only called on power-up (above) ...maybe RFU or a low-power thing?
@idle wharf I had no idea that was a thing. Probably should have read a bit further down the downloads page lol. Thanks!
@tulip sleet at my desk now
i am trying out the 6.0.x with json speedup build. Want to take a look at the PR's?
yup, I can
something weird is going on with the json update; still testing
ok, I was building it with gcc10 by mistake
should we suffix the build invocations so they call for arm-none-eabi-gcc-9.2.1 instead of arm-none-eabi-gcc ?
it was just my problem lcoally, but we could do that. it's not a CI problem
for Scott, that wouldn't work if his toolchain advances versions due to arch keeping up with the latest
it would make it possible to move seamlessly between 6.0 and 6.1 without modifying PATH which would be nice
do you want to backport that change to 6.0.x, or just do it going forward on main?
a reasonable question... I could arrange my symlinks so that the unsuffixed one was 9 as long as I needed it to be
I found this more complete scenario really helpful from espressif: https://github.com/espressif/esp-idf/blob/master/examples/common_components/protocol_examples_common/connect.c look around line 278 on how they implement deinit
It is that example that let me try out esp_wifi_clear_default_wifi_driver_and_handlers()
I'm thinking maybe this is not worth it because most ESP32-S2 users are on 6.1.x.
@tulip sleet I was thinking about that but it would help older portal projects
though they can always move to the beta
i will test on a metro esp32-s2. The test json limor gave me is too big for samd51 anyway
whoa. too big for samd51 is very big
the file is like 250k
@hearty tapir nice one, that's got a little of everything
This means that you can build 6.0 and main with the same PATH, as long as the unsuffixed compiler is 9.
You can make CCSUFFIX= to use the unsuffixed compiler at any time, or make CCSUFFIX=-12.3.4 to select a particular suffix.
@slender iron we could discuss in the meeting tonight; it's getting relatively close to that time anyway, and maybe we don't want to release 6.0.1 on Christmas eve
ya true. we could do next monday I think
i could make a new beta earlier than that if we wanted with the BLE and FrequencyIn fixes, so anyone who's stuck could be pointed to the beta. But I"m not sure how stable main is right now
They use the same API / functions also for wired Ethernet
or at least very similar.
@digixx I can as a last resort. You can do it through the github website though: https://docs.github.com/en/free-pro-team@latest/github/managing-files-in-a-repository/editing-files-in-your-repository
@tulip sleet I think I'd rather just post the beta on monday as well
we can merge before that so S3 picks them up
yes, so we can decide on the json->6.0.1 tonight, and merge that or close it, and merge the rest as soon as approved
kk
There is that discussion about the power LED on the MagTag and @ladyada that want to have it.
But I discovered there is a way to have a LED only when 5V is present and not on when battery powered, this is what the FeatherS2 is doing:
The red power LED doesn't light up when running off battery
That is by design! The power and charge LEDs and corresponding 2K resistors drain the battery, so they have been isolated to the 5V power domain, so they will only light up and draw power when the board is either being power by the USB plug, or by a 5V power source connected to the 5V header pin.
(see https://feathers2.io/)
@thorny jay @meager fog used a 10k resistor on the power LED to minimize the draw. I think it may have been conscious choice to have it powered in both domains, but I am not sure. Of course, one might use a USB power pack connected to USB as well, but usually those are hefty, so lighting an LED is not a big deal.
Looks good to me! I did not run further tests.
I'll have to revise the sleep guide about light sleep power consumption (doc and graphs), and see if we see any reduction during the sleep.
Looks good to me! I did not run further tests.
I'll have to revise the sleep guide about light sleep power consumption (doc and graphs), and see if we see any reduction during the sleep.
I've seen about 30mA. The PinAlarm also takes ~1.4mA while deep sleeping because it has the RTC peripherals enabled.
Discovering my FeatherS2, the replacement just arrived today. That is two travel from Australia to Belgium. ๐
@ricardoquesada If you are using displayio, the terminal shouldn't override your displayio Group. How are you setting a pixel?
It would help other SAMD51 portal projects though. If it's not too much work I think it's worth having.
I haven't found a way to do that from CircuitPython, so I suppose it's about time to begin the trek up the learning curve of how to make changes to the core ;-)
hmm, we never actually call
esp_wifi_disconnectanywhere?
The only way I can think of is to set the radio.enable = False.
I tested a very chonky (250kB) .json on ESP32-S2 and it worked.
Can you provide some boot or commandline option
for usb-storage to be directed towards SD card instead
of internal flash?
It's not a high priority for us and it's not simple. The native sdcard support is a good start though.
Darn it, I meant to PR this against 6.0.x.
In the core, we should use the probe function in the common hal.
Note, I don't have 10.2.1 yet. I'm not sure this is worth the headache of needing to update this version every release.
Thanks for the PR! Just a few requests.
Did you get the 6 length issue sorted out?
This test is fine. I don't think you need the comment above. Instead you can put the comment below there and remove the log lines.
No need to keep this in. Please remove.
I meant to do this in the first place, but forgot to set the base branch when creating the PR.
@gilded cradle https://forums.adafruit.com/viewtopic.php?f=60&t=173253
Ok @slender iron, got it
thank you!
This is how it looks like if strlen(cstr) is used. I don't really know what to do about it.
wifi.radio.ap_info.country
'DE \x01\r\x14'
Re-approving in anticipation of a clean build.
@tulip sleet need my review on anything else?
@slender iron #3872, and #3870 if we decide to pull the JSON fix into 6.0.x
donezo
thansk!
@slender iron I'll change the esp_wifi_get_country() to return mp_const_none if != ESP_OK. Does the way the cstr looks like ring any bell?
As per espressif docs the wifi_country_t.country.cc[3] so not sure why I see what was pasted above (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv4N14wifi_country_t2ccE)
I'm trying to make the Stage library run on the Meowbit, but in order to do that, I need to re-initialize the display. I'm doing it with this code:
import board
import digitalio
import gamepad
import stage
import displayio
import busio
import time
_TFT_INIT = (
b"\x01\x80\x96" # SWRESET and Delay 150ms
b"\x11\x80\xff" # SLPOUT and Delay
b"\xb1\x03\x01\x2C\x2D" # _FRMCTR1
b"\xb2\x03\x01\x2C\x2D" # _FRMCTR2
b"\xb3\x06\x01\x2C\x2D\x01\x2C\x2D" # ...
Thanks, I'm setting the pixels like the following:
# Enter this from REPL
import board
import busio
import displayio
from adafruit_matrixportal.matrix import Matrix
matrix = Matrix(bit_depth=2)
display = matrix.display
bitmap = displayio.Bitmap(64,32,2)
palette = displayio.Palette(2)
palette[0] = (0,0,0)
palette[1] = (255,0,0)
grid = displayio.TileGrid(bitmap, pixel_shader=palette)
group = displayio.Group()
group.append(grid)
display.show(group)
bitmap[1,1] = 1
```...
Merge #3861 fixes to main.
@slender iron ok, one more PR to get the BLE regressions into main. I had to do this by hand due to translation conflicts. The code part is identical. https://github.com/adafruit/circuitpython/pull/3874 Thanks!
I understood what is happening here: This is the full country element, not just the .cc portion!
D (0x44) E (0x45) " " (0x20 - interpreted as "whitespace" although this stands for "Any Environment" in Wi-Fi context)

@slender iron #3830 (pin alarming) looks like it needs make translate
kk, will do in an hour. on the wrong computer atm
lol, this country.cc is the second issue I'll have to open with espressif. Even when using the esp-idf directly, it has a length of six instead of two.
what's the esp32s2 magic to get the ESP_EARLY_LOGW and similar to show up in the debug console?
@crimson ferry you need to compile with DEBUG=1 on the command line. I have not tried the EARLY versions, just the regular ones.
sorry for the dumb questions, I'm starting at zero... I don't find DEBUG in any of the config files at circuitpython/ports/esp32s2/
Re-approving in anticipation of a clean build.
@crimson ferry I've had the same confusion ๐ your make command needs to look like this: make BOARD=boardname DEBUG=1
oh, I was hoping to use GitHub to do the builds for me (to defer that learning curve)
@slender iron are you ok with mp_obj_new_str(cstr, strlen(2)); and a reference to the ESP-IDF issue ID ?
no, actually not strlen(cstr) as the country.cc object of ESP-IDF function has a bug
strlen(2) isn't valid
Oh, I meant to type: mp_obj_new_str(cstr, 2);
ya, that's ok
I'll get famous within espressif ๐
@crimson ferry if you're on Win10, I can recommend the WSL Ubuntu 20.04 LTS - this is what I use ๐
(Windows Subsystem for Linux = WSL)
@slender iron I'm on macOS (11). Using Github to build may be a moot point... I assumed Actions would fork over too, like we grab artifacts from your repo to test. But no joy.
OK, thanks, I'll start there
np
All suggested changes implemented. I also fixed the trailing line/whitespace that caused the CI to be unhappy.

encoder.position does not change (first tick is not recorded) when reversing direction.
I have found encoder.position to accurately report while consistently incrementing or decrementing (clockwise or counterclockwise), but it does not report the first tick when changing direction.
Similarly, if the user toggles back and forth between two adjacent (tick) positions, no change is ever reported by encoder.position.
Hardware setup: this [guide](https://learn.adafruit.com/rotary-encoder/...
I've seen what looks like read() not returning on a UART creating with timeout 4 seconds on standard TX/RX on a Feather nRF52840 Express. The code gets stuck here:
Traceback (most recent call last):
File "code.py", line 267, in
File "code.py", line 265, in
File "lib/pimoroni_pms5003/__init__.py", line 156, in read
KeyboardInterrupt:
Code done running. Waiting for reload.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any ke...
Could you also test on 5.3.1 if possible? That would help narrow it down. Thanks!
I've done a little bit of REPL testing and it's possible this is actually just bogus frame lengths, e.g. something like a read(largenumber) could be creating the appearance of getting stuck.
I'm going to make the code more robust for abnormal frame lengths and then I'll study the behaviour afterwards to see if this still occurs. If it does I'll give 5.3.1 a go too, thanks.
@slender iron I should have merged your pin alarm PR first. But I merged the ble fixes to main, and that caused another make-translate conflict. Sorry. I can revert the ble fixes temporarily, or you could do make translate again on the pin alarm PR.
np
I have it hooked up to an EVT board, and it's looking like it's not properly clearing interrupts. In particular, whenever I break into the debugger it's calling CALLBACK_CRITICAL_END; in background_callback.c:57.
The most likely reasons for the test CI job to fail are translation check failures and documentation build failures. Let's move those earlier so that the job will fail more quickly. The translation check can come first.
It's leaking stack somehow. Every time an interrupt hits, the stack pointer is moved up by 160 bytes.
Is there circuitpython support for the feather S2 built in wifi?
yes
Thanks, just found it.
There were two issues at play:
- Interrupts were getting re-enabled prior to the handler returning. This happened both in
port_get_raw_ticks()and insupervisor_tick(). - Some code was placed in the critical path, resulting in timeouts from the USB stack. Notably, a
divideormodulooperation was added somewhere along the line
Is anyone here an expert at Github? I'm trying to create a PR (for the issue mentioned above), but it just keeps telling me "Unicorn!".
This is the page I'm trying to go to: https://github.com/adafruit/circuitpython/compare/master...xobs:fomu-fixes-6.0.0?expand=1
Github appears to be broken, and can't create a pull request:

Please apply https://github.com/xobs/micropython/commit/f3e54414e5771a2463a8a93b4dcbb395584d2fe3 and https://github.com/xobs/micropython/commit/2f95cc95a494395658eefed6130b9a8732117482 to fix this issue
use main instead of master
Thanks for pointing that out. I have to manually modify the URL, since the Github UI shows me that unicorn whenever I try to create a PR.
These two patches fix Circuitpython 6.0.0 when running on Fomu.
did you clone the repo to your account? might still have the clone set to master and need to manually modify
It really wants to merge to micropython/master, to the point where I discovered that Github's UI lags, and I accidentally opened two PRs to micropython even though the UI said circuitpython.
My fork has fomu set as the default branch.
I had this thought earlier... CI tests can be moved on the basis of :-
- Speed of completion.
- Frequency of occurrence.
On this basis we can have translation, usb vid/pid tests earlier and tests like docs build can be moved further ahead... unless the CircuitPython CI uses parameters generated from previous checks which I don't think it does.
Now using touch interrupt for pretend-to-sleep.
@tulip sleet @slender iron I released an update to the Adafruit_CircuitPython_RFM9x Library. Will the next release of CP (6.0.x or 6.1.x) routinely be updated to incorporate the new release for the feather_m0_rfm9x build or do should I created an PR to update it?
I made an alias for that in my .bashrc which helped me to correct the remaining whitespaces/trailing. Works like a charm, thanks again ๐
@solar whale It is not automatic that they get updated; it tends to get done in batches. Do you feel it is a regression for 6.0.x from, say, 5.3.1, or that it is a kind of showstopper bug? Then happy to include it. You could submit a PR against 6.0.x (you have to change the branch dropdown when you submit the PR.
The space character is actually correct to refer to the "Any Environment" (0x20) opposed to just "Indoor" or "Outdoor". As per feedback by espressif and also after reviewing different documents, this appears to be correct. As strlen() reads until a \0 character, I suggest we stick to the 2 to read just the country code. I've updated the comment accordingly and no longer refer to a bug. It is mainly my misinterpretation/lack of knowledge here.
@tulip sleet It is nothing major, just some enhancements to incorporate some errata from the radio datasheet and an update to the RSSI calculation. No real functional impact and no API changes.
If I submit a PR agains 6.0.x, then will that also get incorporated into main.
not automatically, and given that it's minor, i'd rather just have it in main, and whoever wants it can get the beta. We are only fixing regressions or showstopper bugs in 6.0.x right now. But we should probably make a habit of updating the libraries shortly before every announced release. I have it semi-automated in terms of fetching the latest tagged commit.
That would be good. I'll go ahead in put in a PR for main.
Or just open an issue for 6.x.x, because we want to update all of the libraries
OK -- will do!
There is a new Release of the Adafruit_CircuitPython_RFM9x library that is "frozen" into the feather_m0_rfm9x build.
The link in the frozen folder should be updated.
I did verify that is still fits for en_US and zh_Latn_pinyin ... still several k to spare.
I'll close this up since I don't see a middle ground between specifying the gcc version and not specifying it.
Hey, wrt circuitpy implementation of neopixels, I can't find anything on the documentation about querying them to find out what color they are- can they do this, or do I just have to keep track of it elsewhere?
@halcyon latch I think you can access them by index on the pixels object:
pixels = neopixel.NeoPixel(board.NEOPIXEL, 1)
pixels[0] = (10, 0, 0)
print(pixels[0])
Oh! That makes life a lot easier, thank you!
@tulip sleet I just created a build from main for the feather_mo_rfm9x and it did not build in busdevice -- It built OK yesterday -- did something change?
we turned it off for now because it does not work properly with bitbangio or other busio-"duck-typed" alternatives. https://github.com/adafruit/circuitpython/issues/3856
sorry wrong issue, edited
hmm -- thats too bad...
we know how to fix it but it is a regression for the moment
I'm hoping to fix busdevice over the holidays. I think I know what to do and understand how the other types work now too
FYI -- pip3 search is disabled ... https://status.python.org
Ordered myself an Adafruit Feather STM32F405 Express, a J-Link Debugger and some Nordic stuff via Digikey as Christmas present ๐
v nice!
Rabbit holes everywhere .. I need to be careful ๐ haha
Fixes wrong DAC output levels at high data rate
closes adafruit#3796
Is it ever planned to use Websocket as a Circutpython lib?
I use uwebsockets on micropython and have been successfull in using it on Circuitpython with a few modifications (that I should probably post somewhere) https://github.com/danni/uwebsockets
can you send me the modify version?
so I have this, it worked with my obs websockets code on the FeatherS2, but it's super hacky, based on an older version of uwebsockets, and it doesn't implement SSL (though that should be easily added back in)
We got the present setting when I tried copying Arduino register settings to CircuitPython: 61698eb5d8d04da3a85dbbb42edc86858d42036b
The mismatch between the associated GCLK and the register setting was noted in that commit.
Before that, it appears we used GCLK5 at 2MHz and used DAC_DACCTRL_CCTRL_CC1M which was "correct" (1M is for 1.2MHz < GCLK_DAC โค 6MHz)
I don't know whether I made an error selecting the combination of CC100K and 12MHz, or whether that is truly what Arduino does--...
I only use it through obswebsockets too