@dhalbert I'm sorry I'm not familiar with the Feather nor Metro and I don't understand your comment. Are you saying the random flashes are providing me with some sort of status information?
#circuitpython-dev
1 messages ยท Page 384 of 1
Yes, the status RGB LED indicates various states and errors. In 6.x and earlier, it flashed more often: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#circuitpython-rgb-status-light-2978455-21. In 7.0.0, we are simplifying it and reducing the frequency of flashing, to save power and annoyance. The new flashing scheme hasn't been written up yet in detail.
This partly implements #4868. The main purpose of this PR is to update the usb_hid API in preparation for 7.0.0.
- Require that the report ID the user wants is in the report descriptor. It will not be changed and will not be assigned dynamically.
- Due to the above, the default devices now use these report IDs: keyboard: 1, mouse: 2, consumer control: 3.
- Remove the
Device()constructor argument that is the report ID index. - Chnage the
Deviceconstructor to
Change the `.last_re...
A Development Board base on esp32-s2
A Development Board base on esp32-s2
i am a user use this dev board . not AI-Thinker ใ iam Third party ใ
I dont think there is anything inherent to displayio that will prevent that from breaking.
Nice catch thank you. Ill work on a fix for that and add another region near the edge in the test script to ensure it works.
I am not sure, but that is a good idea to try to handle it as gracefully as we can. Ill poke around some of the other core functions and see if there is anything in them that we could use in this one to try to guard against wrong arg tyles
Yep I do think its worth adding a check to ensure the location is in bounds in the bitmap. Ill try to work that in.
Thanks for taking a look at this, and all of the suggestions
Sorry, missed notification. Created PR https://github.com/adafruit/circuitpython-org/pull/740
@tulip sleet am I understanding correctly that keypad doesn't have a mechanism to report the current (or last known) status of a key ? (like a .value)
That is correct, but you can derive it from the events. It is stored internally, and originally I made it accessible, but then removed it after discussions with Scott, some of which are in the PR
debug uart messages seem to indicate the watchdog is biting...
I (48) boot: ESP-IDF v4.3-dev-1197-g8bc19ba89 2nd stage bootloader
I (48) boot: compile time 12:53:14
I (48) boot: chip revision: 0
I (52) qio_mode: Enabling default flash chip QIO
I (57) boot.esp32s2: SPI Speed : 80MHz
I (62) boot.esp32s2: SPI Mode : QIO
I (66) boot.esp32s2: SPI Flash Size : 4MB
W (71) boot.esp32s2: PRO CPU has been reset by WDT.
W (77) boot.esp32s2: WDT reset info: PRO CPU PC=0x4004c8b6
...
In the ESP32-S2 case, is the WATCHDOG ResetReason an indication of a bug in the IDF, or can it also arise from other areas of CircuitPython?
Sorry, this is still not quite in alphabetical order. Put it before the artisense
Change name as necessary.
It's this, https://docs.ai-thinker.com/en/12k_development_board_esp32-s2, is that right? Sometimes it seems to be called "ESP-12K-KIT" or "ESP-12K NodeMCU". Could you pick what seems to be the best name and change the directory name to that (e.g. ai_thinker_esp_12k_nodemcu), and also change the strings here and in mpconfigboard.mk?
Another link: https://www.tinytronics.nl/shop/en/development-boards/microcontroller-boards/with-wi-fi/ai-thinker-nodemcu-32-s2-esp-12k
I just don't want ...
iam designing a light barrier for speed measuring -
to be immune against environment-light i use a VISHAY TSSP96038 IR Receiver.
my ItsyBitsy M4 generates a 38kHz stream to pulse the sending IR-LED - that is working fine with
# 50% duty cycle at 38kHz.
pwm = pwmio.PWMOut(
board.D7,
frequency=38000,
duty_cycle=2 ** 15,
)
for speed & respons-tests i want to setup a test case where i pause this stream for some us.
as fare as i can tell currently ...
I was previously thinking that idle_state=True would mean the line is high when it's not pulsing (useful for driving active-low circuits, and noting that some of these microcontrollers can sink more current than they can source).
This request is another meaning of inverting PulseOut that hadn't occurred to me.
[adafruit/circuitpython] Pull request review submitted: #5152 Fix crash on raise of reload exception
Aha, thanks! Did not test, but I'm sure you did.
Only one more thing. I missed this before, sorry. MICROPY_HW_MCU_NAME should be the name of the chip, not the module.
#define MICROPY_HW_MCU_NAME "ESP32S2"
Just one more change I missed before,sorry.
I was excited to find Lady Ada's 'fix' back in May, and I'm trying to implement this too! I still can't use the SD card on my Teensy 4.1. I used Lady Ada's code, copied some files to the SD card on my PC, and it works, it does print the directory of the SD card.
BUT - I get the same: OSError: [Errno 5] Input/output error
when it gets to this code:
Use the filesystem as normal! Our files are under /sd
with open("/sd/test.txt", "w") as f:
f.write("Hello World : \n")
f.clo...
Thanks for your patience!
Could you now submit a PR to https://github.com/adafruit/circuitpython-org, to add this board to the downloads section in circuitpython.org? Details of what to submit are here:
https://github.com/adafruit/circuitpython-org#readme. Thank you.
@onyx hinge I just did a build for esp32s2 and noticed that help('modules') shows qrio twice. Is this "issue-worhty" ?```
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0-alpha.6-57-g498755af0 on 2021-08-15; Saola 1 w/Wrover with ESP32S2
help('modules')
main collections micropython ssl
_bleio countio msgpack storage
_pixelbuf digitalio neopixel_write struct
adafruit_bus_device displayio onewireio supervisor
adafruit_pixelbuf dualbank os synthio
alarm errno ps2io sys
analogio espidf pulseio terminalio
array fontio pwmio time
array framebufferio qrio touchio
audiobusio frequencyio qrio traceback
audiocore gc rainbowio ulab
audiomixer getpass random usb_cdc
binascii imagecapture re usb_hid
bitbangio io rgbmatrix usb_midi
bitmaptools ipaddress rotaryio vectorio
board json rtc watchdog
builtins keypad sdcardio wifi
busio math sharpdisplay
canio microcontroller socketpool
Plus any modules on the filesystem
hmm - so is array
Yeah I have an idea what's going on so tag me
@jepler Tagging at your request.
I just did a build for esp32s2 and noticed that help('modules') shows qrio and array twice.
It does not seem to cause any problems, but I assume it is not desired.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0-alpha.6-57-g498755af0 on 2021-08-15; Saola 1 w/Wrover with ESP32S2
>>> help('modules')
__main__ collect...
CircuitPython version
CircuitPython 7.0.0-alpha.6-dirty on 2021-08-14 (built from 82a952b6aa93eb1fcbf60c52584ac5c122fb3a56); Adafruit QT Py
Code/REPL
class Foo:
_instance = None
def __new__(cls):
if not cls._instance:
cls._instance = object.__new__(cls)
return cls._instance
f = Foo()
Behavior
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
T...
Turns out the SparkFun cable is fine, I hadn't realised it needed a much firmer push to go in. My i2c reliability has increased since then.
I've put all the functionality now in the code (for i2c) so you can put it to sleep and set/use the fan cleaning mode.
@mew-cx I believe the data sheet's statement of PM4 and PM10 output values are calculated based on distribution profile of all measured particles. can be translated as those values are guessed based on PM1 & PM2.5 values. The te...
So, do I understand correctly, that if I want to add a BrailleDevice HID descriptor, I better do that in boot.py?
You have to do usb_hid.enable(sequence of devices) in boot.py. You can't add it after USB has been enumerated. THis is explained in the Guide: https://learn.adafruit.com/customizing-usb-devices-in-circuitpython/
There, thanks for the patience. I have bumped the number of chars up, and it now appears to be valid according to https://adafruit.github.io/web-bdftopcf/ anyway. Ready for re-review.
I havenโt run pre-commit in a while, I didnโt realize I was missing some new tools for it lol
Adafruit CircuitPython 6.3.0 on 2021-06-01; Adafruit Feather nRF52840 Express with nRF52840
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Reminder: tps units are different between integer and floating-point modes
Sleeping for 20 seconds
BEGIN TEST sps30_test version 1.2
Creating SPS30_I2C defaults
Firmware version: 2.2
Six reads in integer mode
PM1 PM2.5 PM4 PM10
4 12 18 21...
Should adding a new board cause a chance to locale/circuitpython.pot ?
I dunno why, but "circuitpython.pot" made me imagine Blinka coming out of a pot with petals on its head like a flower
i don't remember it every changing that so it i'm not sure that's right
Here is the PR to add the Oak Development Technologies PixelWing ESP32-S2.
There will be a PR for the PID from pid.codes here: https://github.com/pidcodes/pidcodes.github.com/pull/669
I ran and passed pre-commit locally and it passed.
created a draft so i can figure this out
Generally I don't think so but if you ran make translate and it picked up a translation that hasn't been merged to main branch yet it could show up. Pretty sure I've seen that
mind looking to see if that's the case?
i just ran pre-commit on it so... i have no idea why it would have changed
i've got to clean up the pr too
the files sorrry ๐
i'll take a look not sure if i'll be able to say for certain
it looks like it got rearranged some how
Before you add the board, get your branch or main up to date w/r/t circtuipython/main
If a new message has been added since your branch, you might be out of date, and if you also changed the translations for some reason, there will be a merge conflict
i did it off a clean fork from a few days ago
and the "able to merge" message was green
but i'll rebase github main, rebase that into my branch to see if that removes that file
adding a board does not affect the translations
i didn't run anything on translations
fetchings and merging github main, fetching that and rebasing locally, and then rebasing my branch off main shows nothing new to commit
maybe just save your changes out of the repo, delete the branch, reclone and make a new branch
fixed it
i removed it, and then pasted off of adafruit main into it
so now it only shows changes to my files and build.yml
Hey @tannewt I opened a PR on pid.codes for a PID for this board. I linked it above.
I was just looking at this (too late i know) and am wondering where the USB VID and PID come from. I can't trace back 0x612B anywhere. Perhaps I'm not looking in the right spots. I'm looking at the pdf https://www.usb.org/sites/default/files/vendor_ids072121_0.pdf which should be the complete list. Is there a newer one somewhere? Thanks.
that should be the newest one
It looks like the issue is, indeed, MICROPY_CPYTHON_COMPAT. It is being set unconditionally in py/circuitpy_mpconfig.h to the value of CIRCUITPY_FULL_BUILD. So, setting MICROPY_CPYTHON_COMPAT = 1 in your .mk file won't do anything. I tested by setting it to 1 in py/circuitpy_mpconfig.h and your script runs OK.
Is it possible in shared-bindings or elsewhere in core code to ensure the type of an argument? If a function is expecting to receive a Bitmap is it possible for it to validate that the object passed is actually a Bitmap?
Fantastic find, Dave! I honestly hadn't even checked the header, only looking at the .mk. It looks like the header still uses the MICROPY_CPYTHON_COMPAT symbol for at least a string compare bit in there, I wonder if the use of CIRCUITPY_FULL_BUILD for MICROPY_CPYTHON_COMPAT was an accident? I'm replying from mobile but I'll dig through blames when I make it back to my PC.
This definitely should work around my small issue in the mean time though!
The setting is to save space in small builds.
It seems that this lack of bounds checking was at least one of the culprits behind the MemoryErrors. After adding the bounds validation to ensure it won't check points that are outside of the bitmap I am able to fill a bitmap the entire size of the Pyportal screen 320x240 (albeit somewhat slowly), without a MemoryError being raised.
Without the bounds check it seems like it became an infinite loop continually adding more and more points that were outside the bitmap.
I am still curious ...
@lone axle yes! ```c
mp_obj_t mp_arg_validate_type(mp_obj_t obj, const mp_obj_type_t *type, qstr arg_name) {
if (!mp_obj_is_type(obj, type)) {
mp_raise_TypeError_varg(translate("%q must of type %q"), arg_name, type->name);
}
return obj;
}
Sure, that makes plenty of sense @dhalbert, but is there a reason MICROPY_CPYTHON_COMPAT shouldn't be opt-in even when CIRCUITPY_FULL_BUILD is 0? Like @DavePutz pointed out, it's tied directly to CIRCUITPY_FULL_BUILD as it stands. now.
It looks like in d0a210654767677d6d26f1d4d40c378e03e9ca8e on April 22, 2020,, it was changed from allowing it to be set regardless ...
perfect, thank you!
@nitz Yes, it should be ?=, to allow optionally setting it, not just =. I think it was set unconditionally several years ago and we should have changed it. Perhaps we should re-purpose this issue to fix that.
it seems like Bitmap color value indexes are enforced up to a larger power of 2 than the actual value_count argument passed in the constructor.
I think I would expect this to raise an error:
bitmap_test = displayio.Bitmap(2, 2, 5)
bitmap_test[0,0] = 15
But it does actually execute with no error. Only once you attempt to set the pixel to 16 does it end up raising a ValueError
Is this behavior known / expected? or is this issue worthy? or at least worth some mention in the docstrings?
commit 029150a enforces the initial x,y values passed to the function to ensure they are within the bounds of the bitmap.
There seems to be more than meets they eye going on with the color values. There is actually some bounds checking occurring already, but it seems to be based on powers of 2 specifically and not exactly the value_count that was passed when initializing the Bitmap. So it will raise an error if you try to use a color index that is "large enough" over the value_count ...
Fix for issue #5155 to allow setting MICROPY_CPYTHON_COMPAT separately from CIRCUITPY_FULL_BUILD. It will still default to CIRCUITPY_FULL_BUILD if not set elsewhere.
I think this function that Jeff showed me how to use is what we can use to ensure the argument is the right type:
mp_obj_t mp_arg_validate_type(mp_obj_t obj, const mp_obj_type_t *type, qstr arg_name) {
if (!mp_obj_is_type(obj, type)) {
mp_raise_TypeError_varg(translate("%q must of type %q"), arg_name, type->name);
}
return obj;
}
I will give this a try tomorrow.
MICROPY_CPYTHON_COMPAT was used before to toggle the aptly named CPyhthon compatability, but was being controlled by CIRCUITPY_FULL_BUILD instead. This change allows ports/boards to set MICROPY_CPYTHON_COMPAT = 1 in their .mk to enable the CPython compatabilty code.
Oh whoops, looks like I was slow on the draw, as I opened #5158. Though, I think you'll need to add a bit to the .mk file like I did if we wanted it to be settable via a board's mpconfigboard.mk? Could always let it get done in the mpconfigboard.h, but it felt like it belonged with the rest of the make variables that get passed ...
No plans. I don't think its a simple addition because there isn't a soft device for it afaik. Instead, nordic has moved to zephyr. Please file an issue at least so we can track it. I don't believe we have one for it yet
I believe this happens because qrio and array both happen to use MP_REGISTER_MODULE in addition to being listed "in some other location": array directly in objmodule.c and qrio via MICROPY_PORT_BUILTIN_MODULES.
I made qrio this way so that I could build it into the Unix port with a minimum of fuss. I actually think it may be the preferable way, but @tannewt I'd love your input about that.
Alright 6bd8a1d adds a check to ensure the type of the Bitmap argument.
This code:
not_bitmap = {"hello": 123}
bitmaptools.boundary_fill(not_bitmap,5, 65, 2, 0)
Will now raise TypeError:
TypeError: dest_bitmap must of type Bitmap
Wait a bit on this -- I am testing a change to the keyboard report descriptor to fix #5076.
Sorry for the delay, I am getting back to this now.
I just noticed date_added was missing and added it.
I just noticed date_added was missing and added it.
Wonderful, thanks! I think that's missing from the guide, do you want to add that field to the How to add a New Board to the circuitpython.org website guide?
?serverinfo
Ah thanks, I hadn't noticed that. I'll update the guide.
Guide is updated. Thanks again for pointing that out.
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.6 on 2021-08-12; Adafruit FunHouse with ESP32S2 (problem also occurs in version 6.3.0)
Code/REPL
Adafruit CircuitPython 7.0.0-alpha.6 on 2021-08-12; Adafruit FunHouse with ESP32S2
>>> import board
>>> i2c = board.I2C()
>>> import adafruit_dps310
>>> dps = adafruit_dps310.DPS310(i2c)
Traceback (most recent call last):
File "", line 1, in
File "adafruit_dps310.py", line 225, in __init__
Val...
Tiny2040 does not have explicitly labelled UART, SPI or I2C pins, so had no pins defined, but had the objects defined for them. This would cause a NotImplementedException as raised in https://github.com/adafruit/circuitpython/issues/5148#issuecomment-898701100. Rather than introduce default pins we have instead opted to remove these objects.
As highlighted by @tannewt in https://github.com/adafruit/circuitpython/pull/5099#pullrequestreview-727859125, most of the Pimoroni board definitions had erroneous #define MICROPY_ and #define IGNORE_PIN_ lines that serve no purpose in CircuitPython, other than causing confusion for anyone looking into the code. These have now been removed.
Curious. Any clue why the test would have failed?
looks like the docs build is failing for some reason unrelated to the PR ๐
https://github.com/adafruit/circuitpython/actions/workflows/build.yml
Wait a bit on this -- I am testing a change to the keyboard report descriptor to fix #5076.
This problem may not be what I thought it was, so fine to review as is.
Related to this, when looking at other board files I noticed that these four have incorrect / unused defines too. It may be worth raising them with their respective creators.
ports/esp32s2/boards/microdev_micro_s2/mpconfigboard.h
31:#define MICROPY_HW_LED (&pin_GPIO21)
32:#define MICROPY_HW_BUTTON (&pin_GPIO0)
ports/esp32s2/boards/adafruit_funhouse/mpconfigboard.h
32:#define MICROPY_HW_APA_MOSI (&pin_GPIO14)
33:#define MICROPY_HW_APA_SCK (&pin_GPIO15)
ports/nrf/boards/particle...
OK, I have another UF2 for you to test:
pico-kbd-0-255.uf2.zip
I tested this with karabiner-elements-EventViewer (nice program, by the way), and now I see the KC_INTx codes showing up, which did not happen with alpha.6. The version above has a keyboard descriptor that should allow 0-255 (it was adapter from a US commercial keyboard).
Incidentally, I was never able to actually see a ๏ฟฅ produced, but I ...
<@&356864093652516868> hope to see you in about an hour for the weekly meeting! Add your notes to the doc, and write in if we need to read your notes for you. I'll be the host today.
https://docs.google.com/document/d/1m31PDWUWCA7AbFN6D0ht7K4TNlqe9_PwM_3qDV3Ng4o/edit?usp=sharing โ in case you need the meeting document link
Google Docs
CircuitPython Weekly for August 16th, 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 participa...
Go ahead and open an issue about this, so it won't get lost.
Happily lurking, y'all have a most excellent meeting.
lurking
lurking but just had a work call, I should be back for 1:30 for in the weeds topic I put hopefully
https://github.com/mrangen/M4-Breadstick
This design is an adaptation of Adafruit's Itsy-Bitsy M4 Express development board. It's currently running CircuitPython with Arduino to come; naturally the SWD header can be used with Microchip Studio.
Problem:
I/O pins being crowded together requires jumper wires to first connect pins to empty prototy...
๐๏ธ bang bang bang....you're not recording, are you?
๐๏ธ โ
@solar whale Arbitrary thing that Jeff ran into with the QR scanning.... if the QR code is at all curved, e.g. on a sheet of printer paper that you're holding in your hand not perfectly flat, it has all kinds of trouble with the scanning. So... FYI. Make sure your QR codes are flat.
picks up, plays with macropad
Thanks -- they also have to be big enough! I've had issues with small ones.
Good info on the QR curvature. That's actually affecting something I'm doing at work now so good to know.
Oh good! Glad to help.
Another excellent meeting in the bag ๐
Is there a link to the qr code demo?
How much space is left on the chip after the demo is running on it? It might be possible to do a transformation on the qr code boundaries to adjust for curves on paper
That reminds me of the pyramid complexes outside Mexico City, strangely enough ๐
Sorry -- not sure -- @onyx hinge might know.
Later
@ember iris the library does a correction for perspective but doesn't try to do any non-affine correction (whether for a curved piece of paper or something like barrel distortion of the sensor image), as far as I understood it. I don't plan to write that kind of image processing for it, it's beyond my paygrade.
on the esp32s2 there is plenty enough RAM for another copy of the image bitmap, however
I might poke around on it to see if I can get it working on curved papers. I probably wont get it going anytime soon, but I'm thinking about it now and will have to give it a shot
awesome! you might want to contribute it to the library we incorporated, quirc.
Sweet! I'm still working when I can on the sgp40 sensor, but an extra project ought to help me refocus when I get too bogged down
I'm not sure what you are asking me.
I hadn't considered making onewire removable in 7.0.0. I'm open to it on a board-by-board basis but we'd need to make it work. :-)
Could you post a video? It shouldn't be random. If the code completes without error it'll be a single green blink every 5 seconds or so. If an exception ends the code, it'll blink red twice every 5 seconds. In safe mode it is three yellow blinks.
@tannewt how do you feel about using the MP_REGISTER_MODULE style to list shared-bindings python modules, going forward?
Is this right?
// Initialize the reload traceback as empty to begin with. It will be filled in later when the exception is raised.
MP_STATE_VM(mp_reload_traceback) = mp_const_empty_traceback_obj;
MicroPython 7.0.0-alpha.5-106-g8e201d519-dirty on 2021-08-06; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> v = (1<<128)
>>> u = v + 1 - v
>>> u == 1
True
>>> u is 1
False
``` it's also true in circuitpython that you can get two integers that are `==` but not `is`. Just had to satisfy myself of that.
@onyx hinge you are assuming I know more about MP_REGISTER_MODULE than I do. if you think it's better than I'm ok switching to it
@slender iron OK, fair enough ๐
Here is the notes document for Mondayโs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/10fzYN9LFHmhD-v47O-HZw6WN8us9PmUtQTcjUbbHxEU/edit?usp=sharing
Google Docs
CircuitPython Weekly for Here is the notes document for Mondayโs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโ...
I'd rather keep this to .h files because it doesn't impact what files are included in the build. So, I'd prefer this over #5158
I discovered last week that you can convert the PWR USB connector of the Kaluga to the CircuitPython USB connector! It's awesome. You just have to bridge those two pairs of pads, to connect the D+/D- through to the right ESP32-S2 pins
@onyx hinge hmm -- cool --- I will give that a try -- so that make s it connect to D19/D20??
right
very nice -- Thanks.
They're not designed as solder jumpers so I used fine wire. Smaller soldering than I like to do on a regular basis.
What sensors specifically do you have issue with? How long are the wires you are using to connect them?
I'll likely do the same.
I've looked at the schematic but never appreciated what it was implying!!
What does it matter if it looks terrible, if it works and few will see it?
@cunning crypt a healthy attitude, thanks
Weird failure. Definitely unrelated to your change. I'll take a look and poke at it.
looks adorable to me...
Thanks Scott ๐
This makes a good point about trademark if you haven't gotten yours already: http://www.ladyada.net/library/openhardware/license.html
Yeah, I need to invest in that for my various boards
@onyx hinge Can you send me the compatible MP3 file, or some compatible files if you have multiples?
@onyx hinge Also, is this pretty much the same thing as how it would work for MacroPad? I'm unclear on it because you're saying you don't want to recreate it every time, but if you're calling that in the loop, wouldn't it get recreated on every time through the loop? https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground/blob/e0fecb6c73f11c31cfc2a9c0e9ce9805b8fb1cf1/adafruit_circuitplayground/bluefruit.py#L137
yeah I guess that code does re-create it
I'm unsure how to write it so it only creates the thing on instantiation and allows for reuse in the loop.
compatible mp3 files .. well, I mostly used copyrighted music so that's not great to share. iirc you can save mp3 files from audacity with the bitrate of your choice, so maybe try that.
I mean for testing. I'll sort something out for the guide.
maybe don't worry about the memory use problem for adding it to macropad. if it's OK that's simplest, if not we can fix it without changing the API
Ok
What are the compatible bitrates, then? If I need to make my own?
I DM'd you some
Cheers.
While trying to video the tests, I ran into issues of consistent results. My first test was
from adafruit_macropad import MacroPad
macropad = MacroPad()
The p[0] flashed GREEN every 5 seconds, just like you implied. This is the first time I'd seen that.
The next test was
from adafruit_macropad import MacroPad
import time
macropad = MacroPad()
for i in range(10):
time.sleep(0.25)
and it double-flashed RED every 5 seconds.
When I added a
...
That is easy, unless Iโm missing anything:
diff --git a/shared-bindings/bitbangio/__init__.c b/shared-bindings/bitbangio/__init__.c
index a8d9f5e61..acf7f05e4 100644
--- a/shared-bindings/bitbangio/__init__.c
+++ b/shared-bindings/bitbangio/__init__.c
@@ -72,7 +72,9 @@
STATIC const mp_rom_map_elem_t bitbangio_module_globals_table[] = {
{ MP_ROM_QSTR(MP_QSTR___name__), MP_ROM_QSTR(MP_QSTR_bitbangio) },
{ MP_ROM_QSTR(MP_QSTR_I2C), MP_ROM_PTR(&bitbangio_i2c_type) },...
@onyx hinge Ok, so, to clarify then, the way I did it in the CircuitPlayground library will work for MacroPad then?
@idle owl yes, if the CP version is working
Ok I'll give it a try.
@onyx hinge Ok, so, maybe it's how I did it, or maybe it's the file, but when I play a wav file, it fails to the else: raise ValueError("File must be wav or mp3"), and when I play a seriously shortened version of the MP3 you sent (shortened via audacity), it plays it and then hangs, the LED on the key stays on and nothing works until I reset or reload via REPL.
So I broke all file playback apparently.
I realised it didn't need to be separate like the CircuitPlayground version, which is separate because both boards don't support MP3 playback.
So it's all in one def.
I think I'll pick this up tomorrow.
I feel like it's something silly, and I'm probably simply missing it.
that doesn't sound good. If you can't tease out a reason for that happening, we can look together.
it could always be a core bug, you never know
I'll ping you tomorrow after I look at it with fresh eyes, if I can't sort it out. Thanks.
When I read fresh eyes, I immediately thought "Oh, what store do you get those from?"
More seriously though, I agree. Sometimes we just get 'stuck' on something, get frustrated, and then come back to it and go "Huh, well. That's not that bad."
I can repro, using the following code.py:
from adafruit_macropad import MacroPad
import time
macropad = MacroPad()
for i in range(10):
time.sleep(0.25)
macropad.pixels[i] = 0xffffff
I got the same inconsistent red blinks. Then changed it to this and saved:
import board
import neopixel
import time
pix = neopixel.NeoPixel(board.NEOPIXEL, 12)
pix.fill((255, 255, 255))
time.sleep(5)
An got this instead of all white.
 entries. I'm not sure what the policy is regarding these kinds of changes, but figured I'd throw it out there for consideration.
Found when working on stubs for vscode-circuitpython, this needed a special casing (or rather, lower-casing) to handle as nicely as other boards.
Will do. After digging through the nRFX drivers in the nRF52 port, it looks like a "bare metal" port might be possible if you added a RPMSG library for the HCI comms to the network core. Zephyr/NCS would be the way to go though, so looks like this will be dependent on a Zephyr port.
Will we be able to make this a smooth transition from 6 to 7? I think most of the these APIs are below the HID library that we can update.
Collect the in report buffers too.
Why not just default this to -1 instead of None?
Thanks, that just looks like a typo we should have caught in review.
@kind river You may want to look into the devices/ble_hci folder as a way to do the host side from within CP. Then we can load whatever we need for the controller on the second core
Will we be able to make this a smooth transition from 6 to 7? I think most of the these APIs are below the HID library that we can update.
The constructor usb_hid.Device() didn't exist before 7, so that's not an issue. I will have to change the Learn Guide.
The .last_received_report already existed, so I am adding get_last_received_report(report_id), and then will drop .last_received_report in 8.
The problem occurs with the PCT2075, the SGP40, and the BHT1750. Each fail with either 2 inch or 4 inch cables. I have reverted to CircuitPython 6.3.0 due to other issues with 7.0.0 alpha and the issue is present in 6.3 as well.
Good catch! Thanks for finding this and fixing it! :)
Yeah, the further I dig the more it seems like a bare metal + rpmsg hci port might actually be easier than porting to zephyr.
I do not see these problems, both with the tip of main and with alpha.5. I also updated the macropad library to the absolute latest and it's ok. If you haven't updated the library, try that.
I tried doing just red, green, and blue, and they look OK also.
Try also putting a delay of a second or so at the beginning of the program. I have a weak hypothesis...
Whoops, yes, thanks. I had originally removed the IN buffers, but realized I still needed them.
Hi filesystem-knowing circuitpython-devs, would it even be conceivable to do a read-write sub-mount of the CIRCUITPY filesystem? This sub-mount is read-write to code.py and read-only to the USB host while keeping the rest of "/" writable by the USB host? e.g. storage.remount("/foo", readonly=False) would let CircuitPython write, but allow code.py changes. This would enable two-way "communication" through the filesystem
I did think about doing that, but I want the user-facing API to be None, for clarity: None means no report id supplied. If the user does supply the parameter (instead of defaulting), it should still work the same way.
38f4281 addresses the review comments, and also:
- The default KEYBOARD report descriptor had a signed/unsigned error, and also could have allowed more keycodes. So I revised it, using the very vanilla descriptor from a very plain extremely common commercial keyboard, modifying it only have 5 LED's instead of 3, and added a report ID. This might fix #5076, but even if not, it's a more correct report descriptor.
- Removed some byte-counting in the descriptor comments that is no longer nece...
I'm sorry. It's long. I ran multiple tests with inconsistent results. Here's what a saw:
Summary:
- Normal green blinks
- Normal double-red blinks
- Random / single-red flash or 5 second solid
- Ditto
@devout jolt that would require a second partition and file system. I've pushed back against that because I never manage to have enough space in each partition
I figured it was something like that. And makes sense
many boards have 8MB now (from ESPs to Adafruits 2040 boards), maybe we could look into some option on those ?
Typical random behavior with
from adafruit_macropad import MacroPad
import time
time.sleep(3)
macropad = MacroPad()
for i in range(10):
macropad.pixels[i] = 0xff0000
time.sleep(0.25)
I'm skeptical you'll find a good default option. probably more likely want to create a way to opt into it
maybe as an advanced option to erase_filesystem() or something
What is your host operating system, and what editor are you using? Do you have any utility programs installed that are backup programs, disk utilities, etc.?
If you install a program such as above as code.py, and then plug the macropad into an AC adapter (so no host computer), do you see the same random flashing? If you press the reset button, does the behavior repeat exactly?
I have it on latest, I even flash-nuke'd, put head from S3, and reinstalled the libraries from circup.
With just w8HAQRHkTx7r's code.py I get at minimum the red flash (after the code runs successfully).
Plugging the board into a power outlet with the same code.py I get the same result.
I noticed that the code running with the macropad library seems to have the correct colors though, so I looked at what else it initializes and I added that to my second file (the one without the macropad l...
This might be a PIO issue: neopixels uses PIO, and rotary encoder also uses PIO.
Remind me if Iโm wrong (I might be) there is a character length to the company and board name that is printed to boot.txt and repl when you hit enter?
do you mean a limit ?
Well, on the boot.txt for my Bread 2040 board it only displays my company name not the board name
So it says the CP version followed by โOak Development Technologies with rp2040โ
the string is #define MICROPY_FULL_VERSION_INFO ("Adafruit CircuitPython " MICROPY_GIT_TAG " on " MICROPY_BUILD_DATE "; " MICROPY_HW_BOARD_NAME " with " MICROPY_HW_MCU_NAME)
hmm I don't know ๐คท
i probably messed up the config when i did it earlier
yeah, i think i did it wrong the first time
I'm on the latest MacOS. I don't have any backups running or other utilities to manage disks.
The problem happens on a raw AC outlet. I use Mu Editor.
I'll try a Reset later and an alternate way of changing code.py.
I cannot comment on the the performance questions, but the code to stop it from going outside the bitmap looks good to me. Glad that stopped the memory error.
Range checks look good. The color values are outside my immediate knowledge.
The extra check should prevent an infinite loop situation.
My only other comment is that I don't like the parameter name background_value. We are filling an existing color which may or may not be the background.
Is there a better name. TBH I don't know.
Maybe target_value, but does target represent what we're changing from or what we're changing to.
Maybe selection_value, that makes me think of selecting something in Photoshop.
Left field thought, remove background_value ...
if (value == background_value) {
// There is nothing to do
return mp_const_none;
}
If the user passes in the same value for value and background_value you will get an infinite loop and a MemoryError. This extra check prevents that. Tested on a PyPortal.
Thanks to @ZodiusInfuser for cataloging in #5161 some other boards that had incorrect status LED pin names.
Fixes:
- Correct Status APA102 names for Funhouse
- Correct LED status name for microS2
- Use the RGB LED instead of the single-color LED for status on Particle Argon and Boron
I am adding the hid_boot_interface example here if anyone is interested to test https://github.com/hathach/tinyusb/pull/1025 . I don't have any legacy bios PC to test with though. Therefore it may have an issue or two. For implementation it uses 1 interface for keyboard, and 1 for mouse. Per HID specs, device is default to report mode, Bios PC will send control request SET_PROTOCOL to change it to boot mode which cause this callback to invoked https://github.com/hathach/tinyusb/pull/1025/fi...
@tannewt: Asking you to review because of the original discussion.
I tried to be methodical and took good notes in this series of tests. I created 4 .py files in Mu and saved them with the following names:
/Volumes/CIRCUITPY $ cat twoline.py
print("twoline")
from adafruit_macropad import MacroPad
macropad = MacroPad()
/Volumes/CIRCUITPY $ cat importtime.py
print("importtime")
from adafruit_macropad import MacroPad
import time
macropad = MacroPad()
/Volumes/CIRCUITPY $ cat sleeploop.py
print("sleeploop")
from adafruit_macropad import ...
@Neradoc could you try a microcontroller.reset() instead of the reload, to see if it's a hw setup issue? Thanks.
@onyx hinge Ok, I'm calling you in. It's still doing the same thing as yesterday. wav file plays once, and fails to the ValueError, MP3 file plays once and then hangs (key LED stays lit, nothing else responds, nothing shows up in serial console), can continue with a serial console reload.
I tried moving some things around in the code, but it didn't fix it. Didn't think it would but it was worth a try.
@idle owl OK, can you send me the code you're using?
Yes.
Do you want my CIRCUITPY zipped too?
I'll do that.
There's cruft, but eh.
umm sure
@onyx hinge
Includes latest lib.
which is where the MP3 code is, obvs.
Code is for MacroPad.
yup, the device I've got here is a macropad
I'm starting with my very simple code and adding a print "done playing" when it's done playing
because I think I did not test that, I would always just work by making the code reload when I wanted to go again
after the while audio.playing: pass?
import audiopwmio
import audiomp3
import board
import digitalio
shutdown = digitalio.DigitalInOut(board.SPEAKER_SHUTDOWN)
shutdown.switch_to_output(True)
speaker = audiopwmio.PWMAudioOut(board.SPEAKER)
decoder = audiomp3.MP3Decoder(open("/alot-64.mp3", "rb"))
speaker.play(decoder)
speaker.stop()
speaker.play(decoder)
while speaker.playing:
pass
print("done playing")
``` here's my test code, it's not using libraries or anything.
but now I have to listen to this whole song, why did I pick such a long "sample" ๐
There's a short clip of it in the zip
I used audacity and cut most of it out. The clip is entirely arbitrary.
Mine never gets to the print.
I wonder if it didn't really cut out the rest of the song.
the file size sure says it did cut it properly.
I see the same thing in my local test program, it doesn't reach 'done playing', but continues in the while loop.
it doesn't seem to affect wav files, and it does affect the full-duration alot-16.mp3. I'll debug it, but you can toss in an issue in the core in the meantime.
@onyx hinge there is now a flag in the RP2040 audio_dma.c code: dma->playing_in_progress. The DMA filling code detects that playing is done by getting a GET_BUFFER_DONE status from audiosample_get_buffer AND the buffer length should be set to zero.
I think it did not used to check the buffer length
so the MP3 code should make sure to set the buffer length to zero
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.6 on 2021-08-12; Adafruit Macropad RP2040 with rp2040
Code/REPL
import audiopwmio
import audiomp3
import board
import digitalio
shutdown = digitalio.DigitalInOut(board.SPEAKER_SHUTDOWN)
shutdown.switch_to_output(True)
speaker = audiopwmio.PWMAudioOut(board.SPEAKER)
decoder = audiomp3.MP3Decoder(open("/alot-64.mp3", "rb"))
speaker.play(decoder)
speaker.stop()
speaker.play(decoder)
while ...
@tulip sleet OK I'll check what the code does .. I think it doesn't set the buffer length to zero
It actually asks for a buffer twice. The first time it should return the actual buffer length and report DONE. The second time there will be nothing to read and it should report DONE and set the length to zero.
@onyx hinge ^
this is a bit tricky, but it's because I get a final interrupt when the last buffer has played, and only then do I know that it's done. Maybe I should have a last_buffer_being_played flag.
i should check whether mixer does this too.
mixer is never really done playing, I don't think
eek
OK, by inserting some sets of *buffer_size to 0 it does now set .playing to false after awhile. I will have to read back over your explanation to know whether what I'm doing is causing the last mp3 frame to be dropped or not.
don't set buffer_size to 0 on the last buffer; make it the true size (which it should be already). It's just if you're called and you see there is nothing to play, make sure it's set to zero.
I don't think I know which buffer is the last buffer
would you know whethere there is nothing left to decode?
../../shared-module/audiomp3/MP3Decoder.c:370: MORE_DATA buffer_length=2304
../../shared-module/audiomp3/MP3Decoder.c:370: MORE_DATA buffer_length=2304
../../shared-module/audiomp3/MP3Decoder.c:349: DONE buffer_length=0
../../shared-module/audiomp3/MP3Decoder.c:349: DONE buffer_length=0
``` here are the successive return values of the get buffer function as instrumented, after I bug-fixed
the third one probalby shouldn't be zero
but you should expect to see DONE returned twice
Both of those are the same condition, there was no "sync word" left in the mp3 file, indicating the start of the next chunk of mp3 data
ah, ok
I think it will not cut off, then, but you can test that aurally
unless the decoding is more than one buffer's worth
../../shared-module/audiomp3/MP3Decoder.c:364: DONE buffer_length=2304
../../shared-module/audiomp3/MP3Decoder.c:349: DONE buffer_length=0
../../shared-module/audiomp3/MP3Decoder.c:349: DONE buffer_length=0
``` is this better? It may cause a bit more disk access.
is there really no more data after the 2304? If so then there's not an issue
and the first way should be ok?
OK
I was just worried it was saying DONE before all the data was actually read
there's always an integer number of complete 2304-byte frames in an mp3 file
the decoded data is always 2304 bytes?
strange number
So's 525 or 1080 but nobody talks about it
During encoding, 576 time-domain samples are taken and are transformed to 576 frequency-domain samples.[clarification needed] If there is a transient, 192 samples are taken instead of 576. This is done to limit the temporal spread of quantization noise accompanying the transient (see psychoacoustics). Frequency resolution is limited by the small long block window size, which decreases coding efficiency.[66] Time resolution can be too low for highly transient signals and may cause smearing of percussive sounds.[66]
so maybe there could be 4*192 sometimes? I don't recall having seen it
I'm happy someone gets jokes about obsolete technology
audiomixer_mixer_get_buffer() always returns GET_BUFFER_MORE_DATA; hmm, but get_playing will tell if any voice has finished playing. Maybe audiomixer_mixer_get_buffer() should check for that and say it's done.
@idle owl see here's why it's great that someone besides me tried to use mp3 playback. because my testing was embarassingly incomplete. Thanks so much for doing that, and I'm sorry that in the meantime you felt like you must be doing something wrong.
No worries. It's that much more satisfying finding out it's not me after thinking it was me.
did you write mixer?
@tulip sleet when I implemented the mp3 soundboard for neotrellis, I liked that the audiomixer kept playing forever. All I had to do was concern myself with which track was available to play the next sample when it was pressed, but I didn't have to decide whether to restart playing the audiomixer itself..
no, I helped get it over the finish line but sommersoft worked on it in the middle, and somebody else started it
if you call stop explicitly, it will work, and get_playing does do a stop as a side effect
a mixer with no channels playing outputs "no-sound" forever and that's fine
so maybe that's ok, as a use case, though we should probably document it
there may be hiss you'd prefer to avoid especially with pwm, I guess..
the stop will shut down the PWM and stop the hiss. I think we need to add the speaker/amp enable pin to the next rev of the API
like Limor said, we need to see how other people do ti
an alternative design would be that the mixer would default stop if no voices were playing; if started with no voices, it would play 1 buffer of silence. So if you 'play' the mixer with looping=True it would work like now, but if you want it to stop when nothing's playing (so you can shut down the amplifier or whatever) and manage it yourself you'd just omit looping=True
bool common_hal_audiopwmio_pwmaudioout_get_playing(audiopwmio_pwmaudioout_obj_t *self) {
bool playing = audio_dma_get_playing(&self->dma);
if (!playing && self->pacing_timer < NUM_DMA_TIMERS) {
common_hal_audiopwmio_pwmaudioout_stop(self);
}
I won't change mixer now, but I think most programs will work ok, due to the side effect when checking
that may have the debug prints in it, hold on..
well, if it spews to the display and makes everything sound BAD just displayio.release_displays()
Prints included, yes.
But it stops at the end of playing, and I can still use things!
Now I need help figuring out why the wav playback fails to the else: ValueError() every time it's done. ๐
this one should be without debug prints
@idle owl let's see the full code for the play function, maybe something will leap out at me
- if file_name.lower().endswith(".mp3"):
+ else if file_name.lower().endswith(".mp3"):
you have if/if/else
Oh that matters?
ok
Testing
Thank you!!!
I swear I've done it before with if/it/else and it was fine
do you wanna think about why it matters for a second?
oh I am bad at python
๐ You are very much not.
873 self._speaker_enable.value = True
874 if file_name.lower().endswith(".wav"):
875 with audiopwmio.PWMAudioOut(board.SPEAKER) as audio: # pylint: disable=not-callable
876 wavefile = audiocore.WaveFile(open(file_name, "rb"))
877 audio.play(wavefile)
878 while audio.playing:
879 pass
880 if file_name.lower().endswith(".mp3"):
881 else if file_name.lower().endswith(".mp3"):
882 with audiopwmio.PWMAudioOut(board.SPEAKER) as audio: # pylint: disable=not-callable
The key is to understand where CircuitPython will go next after the while loop at line 878/879 is done...
878 while audio.playing:
879 pass
880 print("what if there is a print statement here?")
881 if file_name.lower().endswith(".mp3"):
``` you might also want to think about what happens if the next line is something other than `if`
hmm.
878 while audio.playing:
879 pass
880 return
881 if file_name.lower().endswith(".mp3"):
``` or what effect adding this could have
Thanks @dhalbert, one suggestion regarding the changes.
Reason for the removal:
NeoPixelis used for status so no need for led.MICROPY_HW_BUTTONdefinition is not used anywhere.
This PyCharm is complaining about already.
Python is pretty much all I use, and I still do else if far too often...
oh I didn't fix the "else if" yet in those samples as pasted, or is it sad about something besides that?
I blame my editor; it doesn't show "else if" in bright error-red
It'll yell about bad syntax I think
It's sad about the print at the same level as the if/elif between the if and the elif.
Same here, it just shows it as fine and goes on it's merry way
Not your extra else if.
oh, oh, my examples were still bad then
I meant to go back to the if/if/else version, and think about what if/print/if would do
oh
def describe_number(x):
print(f"x is {x}")
if x < 100:
print("x is pretty small")
if x < 10:
print("x is really small!")
else:
print("x is big!")
print()
describe_number(5)
describe_number(50)
describe_number(500)
``` another fresh example that I actually tried before pasting in, your problem is like the reason that this prints the wrong things for 50..
though it's still not a great example, because just changing an if to an elif is still wrong.
so all these words later, did anything help make the problem / solution click for you?
Not entirely, if I'm being honest. But it's ok.
fair
I guess I should add an MP3 example to use in the guide.
@slender iron @tulip sleet looking at the way mp3s and wavefiles work, and recalling how we changed ondiskbitmap to take the filename instead of the open file .. I wonder if we should do it for mp3 and wave before beta.
that is an interesting idea. I was wondering what would happen if I closed the open() .
on the other hand, in python I think many things take file-like objects for duck-typing purposes
so I'm not sure I would do this now without further cogitation
taking something that obeys a protocol can be more convenient. e.g. "has .value (like a DigitalInOut instead of passing a pin). I considered that for keypad, so I might pass in TouchIns, but it's not so easy to validate a duck-typed arg, esp in C
Oh, I just forgot that, thanks!
Tested successfully! Thanks for the quick fix!
It works correctly after a reset, with the button or microcontroller.reset, until rotaryio.IncrementalEncoder is deinited. I've done a few tests, it seems the issue appears after the rotaryio.IncrementalEncoder is deinited, but only if the neopixels were used before. Being connected to a computer or not has no incidence on any of that.
This displays all green as expected:
pix = neopixel.NeoPixel(board.NEOPIXEL, 12)
encoder = rotaryio.IncrementalEncoder(board.ROTA, board.ROTB...
@tulip sleet that's true, we also have talked about wanting to stream mp3s from wifi someday, and this would make that harder
ESP32-S2 now properly goes into safe mode. This must have been fixed with one of @microDev1's ESP32-S2 mode fix PR's.
After pressing reset:
Adafruit CircuitPython 7.0.0-alpha.6-73-g064e08657 on 2021-08-17; Adafruit Metro ESP32S2 with ESP32S2
>>>
soft reboot
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
USB devices need more endpoints than are available.
Approving changes to microS2, other changes look good but a second opinion would be nice.
fyi I'll be around later. going to pick up the car now before the beagle arrives
@onyx hinge Let me know if you have a few minutes to chat about an issue I am having with the webcam on the Saola -- it may be easier to explain over voice. No rush.
The problem involves AIO not displaying updated images. I was wondering if you have seen similar behavior -- It works fine on the Kaluga though but when I use the saolo, it often see the new image arrive, but AIO seems to ignore it. It is very intermittent.
I retested the shorter test program on a Metro M4 and Trinket M0 on the tip of main, and it seems to work OK. There have been some recent fixes that I think might have fixed this. Please reopen if you can reproduce. Thanks.
@gilded cradle Any chance you could help me out with an Arduino issue?
I think it might be at the library level and I don't know it well enough to be certain. I don't know your Arduino skill level though.
Sure
Ok, so the MCP9601 is a new breakout. It's basically a MCP9600 except for the device ID.
I'm trying to get the simpletest code to run on it, and it's failing immediately saying it can't find the sensor.
The I2C address is right
Ok, just a moment...
Here's the lib: https://github.com/adafruit/Adafruit_MCP9600 and the code fails here even if I change line 8 to Adafruit_MCP9601: https://github.com/adafruit/Adafruit_MCP9600/blob/f9b5dae333882b9770742922f9c712f89d747afe/examples/mcp9600_test/mcp9600_test.ino#L20
I was just checking if I had one. I don't.
Yeah they're super new and went out of stock quickly.
I thought mine was broken, and was concerned because I couldn't get another one. But it works in CircuitPython.
Am I not understanding how I need to update the code to work with the 9601?
Because I definitely don't understand subclassing in Arduino.
Have you done an i2c scan to verify your device matches the expected one?
I don't know how to do that in Arduino. That was my thought too, but I don't have that code.
You can do it in CP
Device id should be the same regardless
Ok cool, that's what arduino has too
There's a weird thing with the CP I2C scan though
it only shows the address once after being plugged in
oh?
then shows nothing.
That's odd
I tried to figure this out the other day, and never did. The code runs just fine.
But the I2C scan only shows an address on the first run.
After physically plugging it in.
oh, so just an issue with scanning
Ok, who knows. If the code works, that's promising.
I simply have no idea why the Arduino code isn't working. ๐
Wait, you said default i2c is 0x67?
Huh, this says 0x40: https://github.com/adafruit/Adafruit_MCP9600/blob/f9b5dae333882b9770742922f9c712f89d747afe/Adafruit_MCP9600.cpp#L32
I found a bug in circup when installing the Pimoroni LTR559 library. Should I create an issue first, then a PR, or just the PR?
Either way works! If you already have a fix, PR is just fine.
Device ID and I2C address are separate
Separate registers.
Oh, ok. Nevermind. Let me poke around some more.
Thank you
thanks.
Are both MCP9600 and MCP9601 same I2C?
Ok, let me look again
The Arduino lib defaults to the same address anyway
Ok, the i2c scanning and it not finding the device may be related.
Or wait
still checking
Yes. I2C default address is the same
Also I tried unplugged it and plugging it back in and it still didn't find it.
which made the I2C scan find it in CircuitPython.
From what I can tell looking at the code, it sounds like you did it right. Maybe ladyada has some ideas?
OK, I wanted to make sure I hadn't missed something obvious before bugging her.
Thanks for looking into it with me!
No worries. You're welcome.
This no longer crashes, but supplying a buffer >1025 raises the exception RuntimeError: Internal audio buffer too small.
(1025 only works I think because these are 16-bit samples, so 1024+1 works because the extra byte is ignored, but 1025 does not work).
I'm going to close this and open a new issue about that, since it's not fatal.
By the way, I tried this with all the PWM pins, and with them commented out, and did not heard a difference.
Initialize the reload traceback as empty to begin with. It will be filled in later when the exception is raised.
Not sure what you are asking here exactly but the above statement is correct.
CircuitPython version
7.0.0-alpha.6 or later
Code/REPL
import time
import board
import digitalio
from audiopwmio import PWMAudioOut as AudioOut
from audiocore import WaveFile
AUDIO_PIN_L = board.GP18
audio_out = AudioOut(AUDIO_PIN_L)
file1 = open("audio_scanner-left-16k.wav", "rb")
#1024 (and 1025) is OK, or omitting the buffer.
buffer = bytearray(1026)
sample = WaveFile(file1, buffer)
while True:
print("PLAY")
audio_out.play(sample...
@tulip sleet @onyx hinge Do either of you know who setup the Reuse licensing stuff on the libraries? I can't use the license I need to on some files, and I'm not sure what I'm even looking for to see if I can add it or something.
sorry, no, I haven't been seeing anything like that
Do you hear the crackles just at the beginning and the end? If you remove the other PWM pins does it still stop after a while?
@idle owl I didn't put it in place, but I can try to help you use it. what's up?
I need CC BY-SA 4.0 for some files, and apparently it's not allowed.
* Bad licenses: CC BY-SA 4.0
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses: CC BY-SA 4.0
* Unused licenses:
* Used licenses: CC-BY-4.0, MIT, Unlicense
* Read errors: 0
* Files with copyright information: 35 / 35
* Files with license information: 35 / 35
Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(```
Hmm wait
maybe it's the format now that I read it again.
Let me try to add some more dashes.
That didn't work. Still says "missing".
this is the canonical list apparently
It's listed.
"CC-BY-SA-4.0" ?
also there's a difference between bad and missing, it's a different step to fix a missing license
* Deprecated licenses:
* Licenses without file extension:
* Missing licenses: CC-BY-SA-4.0
* Unused licenses:
* Used licenses: CC-BY-4.0, MIT, Unlicense
* Read errors: 0
* Files with copyright information: 35 / 35
* Files with license information: 35 / 35```
Right. Hmm.
yay you got closer to the solution
now you can "reuse download --all" the new license file
& add with git add
yes with pip
hm
I found the individual file after digging.
And added that.
It passes now. Thank you so much @onyx hinge !
hooray!
on it
I want to suggest the code I put as a clearer version of what you are doing. I was hoping you'd let me know if the comment was correct. This PR doesn't have much explanation of what the original issue was and how you are fixing it.
@idle owl works great, but I had some minor feedback
What is your host computer OS? I could not reproduce this on Ubuntu 20.04 with later-than-alpha.6, but it might be due to a delayed callback from TinyUSB.
In any case, I added code to PR #5151 to avoid a write when there is no buffer, which would prevent this.
I haven't looked into it at all so I'd defer to you.
Shall I make a PR with that (even though I donโt have an immediate use for it after all)?
Sure! Always good to have the option.
I was replying so quickly it replied to the wrong comment. I addressed the feedback! Thanks for taking a look!
Latest commit is safer about trying to write to report buffers, and addresses an issue noticed in #5020. I could not reproduce #5020 but this code is a good idea anyway.
anyone with a funhouse want to look at https://github.com/adafruit/circuitpython/issues/5159?
I was going to try that with some other ESP32-S2 board too. I have a lot of issue assignments so I didn't pick it up immediately ๐
kk ๐
still spinning my wheels on this other esp32s2 watchdog-biting bug ๐
It almost seems like a hardware issue in a way. I might see if I can log a similar behavior with my ESP32-s2 with a few I2C devices hooked up.
@w8HAQRHkTx7r thanks for the video and your patience. We'll get this fixed soon.
Tomorrow I'll switch issues for sure if I don't have a breakthrough within the hour today
Looks good to me! Thanks for the tweaks.
I was hoping that would happen this morning for me, but Jeff had to figure out my problem ๐
I won't be able to return the favor, sadly.
I value all the testing, reviews and guides you do
Thanks -- I'll keep investigating....
@onyx hinge OK, I think I'm to the point where I need some pointers for this MP3 guide. If you'd rather I wait until tomorrow for the bits that need your knowledge, that's absolutely fine. I can fill in other bits until then.
@idle owl let's wait if that's OK
Yep! I'll ping you tomorrow and we can coordinate.
Looks good to me. Will let Jeff do a final review.
@analog bridge if you're around, can you tell me about why you chose to modify parse_compile_execute to implement atexit? The reasons for the choice are not obvious to me.
if you don't jump in with an answer I'll leave the question in the review request.
did you consider using nlr_push to allow catching exceptions that originate in the exit handlers? It looks like you had your reasons, but it would be helpful to record them.
New to CircuitPython here. I was wondering if it's possible to use other python libraries like pandas or matplotlib to do data analysis with data collected from sensors that have CircuitPython installed on it?
let's continue this conversation in #help-with-circuitpython . This is more a development channel.
Hi,
@amit794 and I have been working on quick refresh support (by using a different waveform) on the IL0373 as part of our work on the ARAMCON 2 Badge.
Our code can be found at (friendly warning - this is not production grade):
CircuitPython core changes - https://github.com/aramcon-badge/circuitpython/tree/feature/refresh-modes
IL0373 driver - https://github.com/aramcon-badge/aramcon-firmware/blob/master/lib/display.py.
We would like to merge our changes upstream (of course with a r...
Hey @slender iron I tested to see if I got the same I2C errors on my ESP32-S2 pixel wing that was reported with the funhouse and I donโt have any issues with more than one I2C device. Itโs possible itโs isolated to that board specifically.
Iโm using the longer I2C Stemma connectors too
Looks like very plausible code. Didn't test.
I did want to see if this was an issue specific to Funhouse vs a broader issue with ESP32-S2. I tried this with the ESP32-S2 PixelWing I just had added and tested with 7.0 Alpha with two i2c boards. One the MPU-6050 and the other the 1.3" OLED display.
I wasn't able to replicate the issues with my ESP32-S2 board so it's possible it could be isolated to Funhouse.
CircuitPython version
Adafruit CircuitPython 7.0.0-alpha.6-85-g5b0009cbc on 2021-08-17; Adafruit FunHouse with ESP32S2
Code/REPL
print("hello world")
Behavior
Install latest CircuitPython 7 from S3.
On power up:
- All purple LEDs turn on briefly (TinyUSB?),
- Then yellow 1st LED flashes and 2nd LED turns full-on white
- Status 1st LED turns off, but 2nd LED stays full-on white
See attached video in Additional Information
Descripti...
https://github.com/adafruit/Glider-for-iOS/pull/10 is needed on the Glider side.
Fix for FATFS incoming.
This also tweaks the repr for unicode strings to only escape a few
utf-8 code points. This makes emoji show in os.listdir() for
example.
Also, enable exfat support on full builds.
Fixes #5146
I have a FunHouse and tried with a PCT2075, BH1750, SGP30 (all concurrent) with CircuitPython 6.3.0. I was able to instantiate an object for all the sensors and the FunHouse object without issue. I repeated the test under 7.0.0-alpha.6 without issue. I don't have an SGP40 to test.
I even tried pulling A0 on the PCT2075 high to make its i2c address 0x77 and couldn't reproduce the "No I2C device at address: 77" error. (It didn't work, but didn't generate the same error)
@lcongdon Let's see if this is a possible hardware problem. Thanks.
- Are you using the Adafruit sensor boards, or some other boards?
- Which STEMMA cables are you using? Are you using Adafruit ones? Could you give the part numbers your ordered?
- Are you using the small black STEMMA/QT socket? Are you using cables directly to the boards, or are you going to header pins?
- Could you measure the voltage at the terminals on a sensor board, checking Vin, SCL, SDA, and ground?
The build failed for one board on one translation, running out of space. Any thoughts on what to do here?
Fixes #5125.
Fixes #4190.
May fix some other issues.
Thanks! I checked that this was a clean fast-forward update of the tinyusb submodule. No testing performed.
@LibertyBeta Could you test this after it builds? You can click on a completed "Details" link in the builds and find the "Artficats" dropdown. Thanks.
@blissful pollen Disable something else on that board, such as ulab or audiopwmio -- look at the non-flash version to see what we've already had to disable.
Thanks will do! I didn't want to disable something that was needed for that board
You have my permission, for what that's worth.
@LibertyBeta Could you test this after it builds? You can click on a completed "Details" link in the builds and find the "Artficats" dropdown. Thanks.
Will do. Should hook into the supervisor.usb_connected right?
@tulip sleet here is zephyr currently proposed pinctrl api: https://github.com/zephyrproject-rtos/zephyr/pull/37572
(nrf, rp2040, and cxd56)
.. as well as a misleading comment that said that read always output zeros.
Closes: #3447
I didn't get any traction on this bug, so giving it back for someone else to try.
I see the same, with #5172 (just in case it was a tinyusb bug that was subsequently fixed):
Aug 18 10:30:31 localhost kernel: [2395904.328570] usb 3-1.3: new full-speed USB device number 110 using xhci_hcd
Aug 18 10:30:31 localhost kernel: [2395904.447250] usb 3-1.3: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
Aug 18 10:30:31 localhost kernel: [2395904.447255] usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 18 10:30:31 localhost kernel...
I tested the Funhouse and added 2 breakouts with stemmaqt connectors, the apds9960 and the vl6180. The i2c and the Funhouse house worked perfectly. I tried it with both adafruit-circuitpython-adafruit_funhouse-en_US-7.0.0-alpha.6.uf2 and the latest file adafruit-circuitpython-adafruit_funhouse-en_US-20210817-5b0009c.uf2. I was using 100m stemma cables between the Funhouse and both breakouts. Also the on board aht20 was funning during all of the test. All okay for me.
I didn't find any effective use case for recording them, do let me know of what you have in mind.
Will do. Should hook into the
supervisor.usb_connectedright?
I think it should, without further effort, because that's not port-specific.
trying to isolate a few intermittent esp32s2 lock-ups (code stops, serial dead, but CIRCUITPY sometimes still active)... does microcontroller.ResetReason.WATCHDOGarise from core code (idf) watchdog, watchdog python code, or both?
I just learned about the watchdog module today and added it to a couple of units, but was definitely seeing that reset reason before with no watchdog code
Looks good to me. Will let Jeff do a final review.
@lone axle I noticed the displayio_annotation module is named circuitpython-displayio-annotation on pypi, as opposed to adafruit modules that put the -circuitpython- in the middle, making circup unable to install it from a requirements file containing pypi names.
it should be both
does the core have its own watchdog timer, or is it catching the idf WDT, or both?
the core doesn't have a watchdog... the idf might have it internally.
What do y'all have in code.py? I bisected the problem I was seeing to the merge of #3191 (between beta.2 and rc.0) but it went away after moving my code.py out of the way. code.py contained some code to use canbus, but there was no working bus.
The code I had was:
import struct
import board
import canio
import digitalio
# If the CAN transceiver has a standby pin, bring it out of standby mode
if hasattr(board, 'CAN_STANDBY'):
standby = digitalio.DigitalIn...
Is this related to the โdropping circuitpy in save or adding library to lib folderโ ?
thanks. I do get that reason sometimes, but lock-ups other times, so just trying to sort the venn diagram of what it catches
.. and I can go all the way back up to 7.0.0-alpha.6 with no code.py and all is well.
@ornate breach I'm not sure... when I see lock-ups they are typically on unattended devices
I was experiencing yesterday where code would randomly just stop running on my PixelWing
And also dealing with the issue of dropping circuitpy drive if I save code.py or add anything to the lib folder
Running 7 beta 6
It was a build from two days ago
I sent that board off to someone who was interested in trying it out. Iโm building another this evening and Iโll do a clean build
I was disabling auto-reload between alpha6 and this PR 3 days ago https://github.com/adafruit/circuitpython/pull/5152
The randomly stopping of code was intermittent
It would run for 30 seconds to up to 10 minutes and it would just stop running
Had to hit reset to restart
I'm guessing get_previous_traceback() was None
Yeah, from what I could tell
It would nuke CIRCUITPY when it stopped as well
Iโll look over the behavior again this evening when I build up another PixelWing
nice catch thank you. When I have some time I'll dig into it a bit and see if we can tweak circup to be able to work with that naming scheme as well. If I understand correctly the only way to fix without a change to circup would be add some word to the beginning of the pypi name, but I'm not sure what we would add circuitpython-circuitpython-[library name] feels a bit too redundant.
So the point is that they don't have to be consecutive, they just have to be the right instance?
I think that's what you're striving for. LGTM.
or maybe that wouldn't be a fix anyway actually. I haven't looked in the code yet. Possibly the "adafruit" is hardcoded.
I have been working on switching circup to using the json file to find dependencies (and version numbers), that would allow a reverse search with the real pypi name
While I don't have enough information to determine if this is what affected the original reporter, I had an stm32f405 feather that readily reproduced the problem. I eventually discovered that the problem affected me only when I had a program that used canio and was spending all its time waiting in common_hal_canio_listener_receive for a packet that never arrived. This was due to missing background task & interrupt key checking in the blocking loop in common_hal_canio_listener_receive.
...
but that still requires a lot of work (at least rebase since I first looked into it a few months ago, and fix a bunch of tests)
oh but the pypi name in the json file is incorrect right now: setup.py says circuitpython-displayio-annotation but the json file says "pypi_name": "circuitpython-org-displayio-annotation",
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Attempted heap allocation when VM not running.
Please file an issue with the contents of your CIRCUITPY drive at
https://github.com/adafruit/circuitpython/issues
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 7.0.0-alpha.4 on 2021-07-08; Adafruit Feather RP2040 with rp2040
Please provide more details ("Please file an issue with the contents of your CIRCUITPY drive"), and if this is reproducible, try alpha.6 or "Absolute Newest".
Not sure what files to attach as there are files that I am not sharing. I have a copy of the CIRCUITPY drive I can attach required files to.
I have to go, will look at this later
Can confirm that this reports correct status for supervisor.runtime.usb_connected.
Do you know if there would be an expectation for what would be the PyPi name to work (if included in a requirements file) even if the library itself is not released on PyPi due to not being compatible with Blinka currently? I know some of the widget libraries will be in that boat.
Looks perfectly straightforward. No testing done.
Changes look good but I am not sure if this is related to #5004. Also, was esp32s2 left out on purpose?
currently, either make the pypi name the same as the module name or stick a -circuitpython- somewhere in the middle.
The rules are tailored to the format used by Adafruit modules: company-circuitpython-driver-or-helper becomes company_driver_or_helper, anything that doesn't contain circuitpython is unchanged.
Please make a draft PR for the changes to the core. That makes it easier to see what you are proposing for the core.
I think we'd be open to merging it in but would want to know the details first.
This behavior is not present in 7.0.0-alpha6. (No status LEDs appear after TinyUSB purple LEDs)
I think the board define was just fixed so the pins are right now.
Is FunHouse the only board with multiple APA102 LEDs? Should there be a corresponding
MICROPY_HW_DOTSTAR_COUNT?
Yeah, that would be good. I didn't know we had a board with multiple dotstars instead of neopixels.
One question. Thanks for picking this up!
Why doesn't this work? It'd be good to avoid the memset if we can. (It should just DMA the same values over and over.)
So the point is that they don't have to be consecutive, they just have to be the right instance?
I think that's what you're striving for. LGTM.
Correct. I should have linked to the forum post that reported the issue: https://forums.adafruit.com/viewtopic.php?f=60&t=182369
No, it sounds like a fine idea, assuming it's compatible with the FAT support on all the OS's.
I think it's just the fatfs api. the fatfs on disk is two bytes per character
In the FAT filesystems with LFN extention, also + , ; = [ ], white space and extended characters U+000080 to U+10FFFF are legal for the object name
I'll need to squeeze some builds then
what do we think about figure out how to link the -Os stdlib?
i looked at this a bit; I think it didn't look too bad, but I didn't look in detail at how to specify the lib path. I don't think we want to build it ourselves; we could take it from the arch build, and then we need to put it on S3 or something like that
I'd get the matching version down to the bug level n.n.x, make x match, if that's easy. And I think we don't use it if its version doesn't match the current compiler version
Your own circumstance is unusual, since you're not using the ARM download. So if it's easy you could test with this, else i could test
Pointing traceback to const leads to a crash as mp_obj_exception_add_traceback expects a modifiable value.
The crash happens at the following line when trying to re-assign a const struct field:
https://github.com/adafruit/circuitpython/blob/0569c202efbc393dcfc4b95d2472024a6c309b08/py/objexcept.c#L573
Pointing traceback to MP_STATE_VM(mp_reload_traceback) instead allows a future modification.
Hope this clears things up. :)
kk, I can look into this @tulip sleet. diving into usb atm
i can look too, if you are busy. Let me know if you start to work on it. I am looking at samd audio atm
Is there a concise description somewhere of the priorities within the core, for interrupts, watchdog, serial, usb, etc.?
kk, won't get to it today but maybe tomorrow
what do you mean by priorities?
I assume code isn't purely sequential, that there are interrupts and context switches, events, etc. Maybe that's wrong.
you are correct
Since this required a conversation, could you add some comments to the code explicating a bit? Thanks.
interrupts can interrupt things
and on esp32s2 there is freertos as well
tinyusb runs in its own task separately from cp
something is not being caught by watchdog, that's my current question, but I also seem to recall discussion some time ago about relative priorities of serial, control-C, etc
could have pre-dated TinyUSB, or was more of a question of precedence of TinyUSB vs. the rest
watchdogs typically reset the whole cpu
do our interrupts have priorities amongst themselves?
yes, interrupts can have priorities. I know more about arm priorities than xtensa ones
thanks, that gives me a little context, I'll poke around more in the code
Ideally I'd like my code to run forever (I do have some 6.x devices in remote places that I never need to touch), but absent that, I'd like ways to catch anything that may happen, reload (or reset if necessary), and supply debug info to the next iteration
ya, it's a tall order because it is whack-a-mole
The best way I found for long running is using the watchdog timer. You could have a global try/catch block and write that info somewhere and let it timeout for the watchdog to restart things
thanks, I haven't resorted to a global try/except yet, but watchdog isn't catching my current lock-up situation, not sure what else to do... get_previous_traceback() is None, so that's no help
strange though i have seen rare cases of it, but even if it drops to the REPL it should trigger the watchdog I believe
I am back, I rebooted the Feather RP2040 and the problem went away. Not sure what happened, if it reoccurs I will try the alpha 6 or Absolute Newest.
@tulip sleet Do we have an ETA for the next release of CircuitPython? This guide will kind of rely on that MP3 playback fix. I still need some hardware to do the second part of it, so it's partially on hold anyway, but I wanted to know what the plan was if there is any.
i can do one at any time. What is the target for the guide? I was thinking of waiting until Scott debugged the i.MX USB issue (USB is not working at all on those boards), but I don't think he's found the cause of it. But he's working on it right now.
Let me ask Limor whether she intends to make it live without the page I don't have hardware for, or if she wants to wait. Because she's got me waiting on ordering until another thing goes into the shop, so it might even be next week if she wants that page in to make it live. If not, then the Overview and MacroPad pages will be done probably tomorrow. So let me find out what her plan is for this. I don't think it's really a rush job, people aren't clamoring for it, it's simply something we should document.
agreed - especially for networking-based tasks
@onyx hinge Let me know if there's a good time to talk MP3 limitations today.
kattni
me
Ok, so the blurb in the Essentials guide now applies to SAMD51 and nRF, yes?
yes
for pico I'd say stick with rates 64kbit/s and under
for all of them, doing things like updating the display or having intense flash activity like reading and writing files can make them give distorted sounds or noise
I am sure you experienced this with pico
macropad?
That's the hardware I'm waiting to order.
Oh yeah played on MacroPad
All I did was play when a key was pressed though
I was incorrectly equating the pico name with rp2040, my apologies
Ah fair enough
this guide includes Pico so it made sense to me
@onyx hinge What about sample rates for RP2040?
i would expect similar issues, but one could test; there's nothing magical about the RP2040 that would prevent those issues. I heard glitches when writing files, for instance
Also, are mono and stereo both fine for RP2040?
alot-32.mp3: MPEG ADTS, layer III, v2, 32 kbps, 16 kHz, JntStereo
alot-64.mp3: MPEG ADTS, layer III, v2, 64 kbps, 24 kHz, JntStereo
``` those files I shared with you are 8 / 16 / 24kHz sample rate and stereo
Ok
I am not sure if it downmixes or plays just one channel though
so, like, if you're listening to the white album on your macropad you may be disappointed
ikr
there's no channel mixing in the RP2040 audio code
without explicitly using the mixer
yeah so I bet you just hear the left channel
the mixer can't do left/right channel mixing, I don't think
ok, I didn't even know that
You mention the SAMD51 DAC output, but not the nRF. Is there info on the nRF DAC output that's worth including?
Or is that irrelevant on nRF boards
i was testing some (non-MP3) stereo files yesterday and it played just one channel, but it did work.
Also, we have SAMD51 (21 notwithstanding), nRF, RP2040...... What else? ESP32-S2. Does that support MP3? And if so, with what limitations?
Regardless, exceptions or any other means, by having the interrupts handled in a normal stack there is necessarily 10's, or more likely 100's of microseconds of latency at best. This is okay and just means that CircuitPython Python code might not be the right tool for 1us latency responses - which realistically shouldn't come as a shock to most users. I mean, you gotta remember garbage collections happen and that'll cost you 10's of millis at least!
Pretty sure that interrupt context swi...
Appears FunHouse does not have mp3 module.
https://circuitpython.readthedocs.io/en/latest/shared-bindings/audiomp3/ yeah it seems to be limited to ARM-family microcontrollers
which is everything but esp32 and fomu
Ok
@onyx hinge ```For SAMD51 boards:
CircuitPython supports any MP3 file you like. Mono and stereo files from 32kbit/s to 128kbit/s work, with sample rates from 16kHz to 44.1kHz. The DAC output on the SAMD51 is 12-bit so there's not much point in using higher bitrates. Be aware, doing things like updating a display, or having intense flash activity like reading and writing files can result in distorted sounds or noise during playback.
For nRF boards:
CircuitPython supports any MP3 file you like. Mono and stereo files from 32kbit/s to 128kbit/s work, with sample rates from 16kHz to 44.1kHz. The DAC output on the SAMD51 is 12-bit so there's not much point in using higher bitrates. Be aware, doing things like updating a display, or having intense flash activity like reading and writing files can result in distorted sounds or noise during playback.
For RP2040 boards:
CircuitPython supports certain MP3 files. For RP2040, mono and stereo are both supported, and you should stick with files less than 64kbit/s, with sample rates from 8kHz to 24kHz. Be aware, doing things like updating a display, or having intense flash activity like reading and writing files can result in distorted sounds or noise during playback.```
Anything need fixing or worth including?
"The DAC output on the SAMD51 is 12-bit" doesn't belong in the nRF section
Oh I thought I deleted it.
nRF is a PWM output with approximately 8 bits
Oh wait I was asking earlier what I should put there for nRF
So I didn't delete it because I wasn't sure if it should be replaced.
aha
nrf also has I2S
"The nRF has a PWM output with approximately 8 bits, so there's not much point in using high bitrates."
I think all 3 of those have i2s available, it's true
Got the update, thanks.
but the builtin speakers use PWM or DAC
@dhalbert, your question prompted a close inspection of the I2C socket on the FunHouse and there is a bent pin. Thanks for looking into this.
hmm.
if using i2s you still need to stay within the rates the board can handle but you get a much better DAC
And I2S works with MP3?
If it's supported across the board, then it can be hardcoded into the template.
yes, i2s works with mp3
@dhalbert, your question prompted a close inspection of the I2C socket on the FunHouse and there is a bent pin. Thanks for looking into this.
Glad it was easy to spot. Thanks for checking. Sometime's it just mechanical!
"These microcontrollers also support I2S, which allows use of a higher quality external DAC. The sample rates and bit rates are still limited to those shown above, but the audio quality can be substantially better."
Thank you
@onyx hinge Is there something to say about the output on the RP2040? Similar to the "nrf has a PWM that's 8 bits etc etc" line in the other two sections.
hum, I don't know that off the top of my head
Ok
if dan doesn't know, scott will
the rp2040 uses 10 bits for the PWM. I'm not sure the nrf uses 8 bits
Thank you
the nrf is "it's complicated, but around 8 bits"
the RP2040 can use a really high carrier freq, so we can get 10
Nice. I left "approximately" in the nRF section.
TFW I manage to remember the exact phrase Jeff used right after posting a code snippet I needed so I found it in searching on the first try
Oi, everything is taking forever. I might need to reboot. Bleh.
Speaking of Jeff's code... why is this like this, @onyx hinge ? py speaker.play(decoder) speaker.stop() speaker.play(decoder)
On it
Seems to work the same. Code reloaded in the middle of playing and some loud sharp sounds startled me quite thoroughly, but I don't think it was related to removing the first two lines.
So the SPEAKER_SHUTDOWN bit is only necessary on boards with a built-in speaker, and that pin, correct? The pseudo-code starter example for this is going to be gnarly.
Since this template is supposed to work with whatever board.
@skerr92, @dgriswo and @KingerNorth thanks also for checking. I incorrectly assumed a software problem. Working for me now as well.
atmel-samd/boards/circuitplayground_express/pins.c: { MP_ROM_QSTR(MP_QSTR_SPEAKER_ENABLE), MP_ROM_PTR(&pin_PA30) }, we also have SPEAKER_ENABLE and ```c
atmel-samd/boards/cp32-m4/pins.c: { MP_OBJ_NEW_QSTR(MP_QSTR_SPEAKER_P), MP_ROM_PTR(&pin_PA02) },
atmel-samd/boards/cp32-m4/pins.c: { MP_OBJ_NEW_QSTR(MP_QSTR_SPEAKER_N), MP_ROM_PTR(&pin_PA05) },
Express is irrelevant, it's not supported, I thought.
Yeah speaker_enable is on CPB though
So, one section for MacroPad, one section for CPB, and one section for generic RP2040/nRF that requires external speaker, and one section for generic SAMD51 that requires an external speaker...
CLUE is nRF with built in speaker.
blergh.
No shutdown or enable pin.
How many microseconds does python gc take on your AVR though? Thatโs the real point there, not interrupt context switch timing (both of which are different from circuitpython loop lifecycle state- please feel free to read the tick loop code if youโre curious, and gather your own data on gc timing if you doubt mine).
Circuitpython is not the right tool for microsecond timing critical projects, and theyโd be out of scope for Circuitpython as well as this async use case issue! Youโre not goin...
@idle owl macropad is the only one where it's called SPEAKER_SHUTDOWN; all the other call it SPEAKER_ENABLE
I was wondering if we should add the other name. I think some may be inverted, some not, but I haven't checked.
Well there's no Python on AVR as far as I know.
I am just saying ppl used to AVRs through arduino unos and subsequent
boards might not have an issue with that timing
On Wed, Aug 18, 2021 at 3:25 PM Kenny @.***> wrote:
How many microseconds does python gc take on your AVR though? Thatโs the
real point there, not interrupt context switch timing (both of which are
different from circuitpython loop lifecycle state- please feel free to read
the tick loop code if youโre curious, an...
Yeah I think that is the case.
shutdown.switch_to_output(True)
```on macropad I had to set the pin to True even though it was called SHUTDOWN so I don't know about the polarity generally
another one of these inverted shutdowns o_O
macropad is really SPEAKER_SHUTDOWN_INVERT (active low to shutdown); so it even more should be called SPEAKER_ENABLE
ugh.
um.
Do we break things and fix it?
MacroPad library might be the only thing it breaks.
we can add SPEAKER_ENABLE as an alias
Won't that be confusing to have both?
and use that preferentially from now on. When 7 comes out we can change the guides
Since they're kind of the opposite...
when 8 comes out we drop SPEAKER_SHUTODWN
we can discuss that
it was added here: https://github.com/adafruit/circuitpython/pull/4864
macropad isn't in a released version so can we just break it?
(but 7.alpha is on everyone's device in the field)
I want that to be the case, but I also see Dan's point in doing it incrementally.
we can ask at 6pm, or just open a PR and ping limor
It's a bit gross, but I came up with a working recipe for re-synching with an mp3 file after a seek to an arbitrary position. https://github.com/adafruit/Adafruit_MP3/compare/master...jepler:mp3-seek?expand=1
This potentially does a bunch more reading inside the audio background callback, so it may or may cause audio to glitch.
However, it did work properly for my test mp3 file when starting from a bunch of arbitrary middle positions, like
for o in `seq 1 2001 50000 `; do tail -c...
Oops. ๐ git pull adafruit pain fatal: couldn't find remote ref pain
At least it didnโt find pain, might be concerning if it did ๐๐
Right?
we could also alias the SPEAKER_ENABLE pins as SPEAKER_ENABLED_INVERTED if they enable the speaker when pulled low. I don't know if that 's true or not for any of them
@tulip sleet Should I put a comment in pins.c about adding SPEAKER_ENABLE or just explain in the PR?
I would add a comment since it's confusing to read: SPEAKER_SHUTDOWN is deprecated and will be removed later
Ok that's what I thought, which is why I asked.
Now for the stupid question.... how do I do a comment in C? // or something?
my rule of thumb is that if something is going to scratch their head about something, add a comment
I agree entirely
yah //
nice.
Woah.
I've never seen this before. ```Translations.............................................................Failed
- hook id: translations
- files were modified by this hook
find extmod lib main.c ports/atmel-samd ports/cxd56 ports/esp32s2 ports/mimxrt10xx ports/nrf ports/raspberrypi ports/stm py shared-bindings shared-module supervisor -type d ( -path "ports//build-" -o -path "ports//build" -o -path ports/atmel-samd/asf4 -o -path ports/cxd56/spresense-exported-sdk -o -path ports/esp32s2/esp-idf -o -path ports/mimxrt10xx/sdk -o -path ports/raspberrypi/sdk -o -path ports/stm/st_driver -o -path lib/tinyusb -o -path lib/lwip -o -path extmod/ulab/circuitpython -o -path extmod/ulab/micropython ) -prune -o -type f ( -iname ".c" -o -iname ".h" ) -print | (LC_ALL=C sort) | xgettext -f- -L C -s --add-location=file --keyword=translate --keyword=MP_ERROR_TEXT -o circuitpython.pot.tmp -p locale
python3 tools/check_translations.py locale/circuitpython.pot.tmp locale/circuitpython.pot; status=$?; rm -f locale/circuitpython.pot.tmp; exit $status
Traceback (most recent call last):
File "/Volumes/circuitpython.git/circuitpython/tools/check_translations.py", line 10, in <module>
import polib
ModuleNotFoundError: No module named 'polib'
make: *** [check-translate] Error 1
find extmod lib main.c ports/atmel-samd ports/cxd56 ports/esp32s2 ports/mimxrt10xx ports/nrf ports/raspberrypi ports/stm py shared-bindings shared-module supervisor -type d ( -path "ports//build-" -o -path "ports//build" -o -path ports/atmel-samd/asf4 -o -path ports/cxd56/spresense-exported-sdk -o -path ports/esp32s2/esp-idf -o -path ports/mimxrt10xx/sdk -o -path ports/raspberrypi/sdk -o -path ports/stm/st_driver -o -path lib/tinyusb -o -path lib/lwip -o -path extmod/ulab/circuitpython -o -path extmod/ulab/micropython ) -prune -o -type f ( -iname ".c" -o -iname ".h" ) -print | (LC_ALL=C sort) | xgettext -f- -L C -s --add-location=file --keyword=translate --keyword=MP_ERROR_TEXT -o - | sed -e '/"POT-Creation-Date: /d' > locale/circuitpython.pot```
Er, begins with Translations......Failed, but apparently although it's highlighted, it did not copy.
What step did I miss somewhere along the line?
brew install gettext; break link gettext --force
Thank you
I just realised I wasn't in my venv.
That might be the problem.
That was it.
Passed this time.
Hmm. It modified this though: modified: locale/circuitpython.pot
As in that's showing up in my git status now.
Am I supposed to add that to my PR, or is that similar to submodule update failures that show up as unstaged files?
it should not change that. Why don't you git restore that and run a clean build again
I did pulls and all that before doing this....
I'll back out to main, pull again, and make a new branch.
It's only one line of code and a comment I updated. I can paste it back into the file.
one of us should check the other SPEAKER_ENABLE boards
to see about SPEAKER_ENABLE_INVERTED
From github.com:adafruit/circuitpython
* branch main -> FETCH_HEAD
Already up to date.```
Is there something like git submodule update etc that you're supposed to run to get translation stuff updated?
make translate at the top level, but you should not need to do that. Are you doing this on your fork?
I have that aliased, so I don't remember the whole command.
I have my fork setup as a remote, I pushed to it from updated main before making my branch.
is your fork origin?
No, it's kattni and Adafruit's is adafruit.
git fetch adafruit; git checkout kattni/main; git merge --ff-only adafruit/main
(I don't usually bother with -ff-only, but it should only be doing a fast-forward
so just do a build again, it should not change circuitpython.pot
also do the gitsubupdate
I didn't even build. I only commited.
because tinyusb was just updated
Ok, I'll do it again, but I did it earlier.
Yeah nothing happened running it.
Bunch happened earlier.
Ok it worked this time, nothing else modified.
This whole thing can be so finicky and bonkers sometimes. ๐
agree with that
@tulip sleet Is this a valid description for the PR?
The current pin label SPEAKER_SHUTDOWN is confusing because the pin enables the speaker, it does not shut it off. So in code, when using the pin, you currently set SPEAKER_SHUTDOWN to True to enable the speaker, and this is not intuitive.
Or say it's confusing.
I like that better.
Or am I misunderstanding how it works. Is why I'm asking.
it does enable/shutdown the speaker, and it's true it's inverted if its name is SHUTDOWN. It should be SHUTDOWN_INVERTED or ENABLE. But mainly it isn't consistent with the speaker control pin on other boards. If they are not consistent wrt inverted or not, we need to fix those too. I will take a look at the other boards in a bit
Hmm, I'll hold off on this PR then.
they should all have the prefix of SPEAKER_ENABLE.... That means if it's True, the speaker is enabled. If it happens to be the other way around (low to enable), then the name should ideally be SPEAKER_ENABLE_INVERTED.
Ok, I like that.
Maybe I misunderstand what it did. It repeats the output as many times as needed for the input? And the total is the max of the two? or the input size?
Closing via #5151. Please reopen if this shows up again.
No, I really do believe this is the fix for #5004. I'll check esp32-s2 and of course get the build fixed.
@tulip sleet Ok, I can take a look at the other boards tomorrow to figure out what should be what, and include it in the same PR to make everything consistent.
if you want I will do that, not a big deal
I will probably ask for verification from you that I'm on the right track though.
we can both do it; i'll get you a list
OK, sounds good. I think it's good for me to go over it since I don't want to lose schematic and core PR skills. Which I do when I have no reason to deal with either for long periods of time. ๐
@tulip sleet Here's what I got for SPEAKER_ENABLE: ports/atmel-samd/boards/circuitplayground_express/pins.c ports/atmel-samd/boards/circuitplayground_express_crickit/pins.c ports/atmel-samd/boards/circuitplayground_express_displayio/pins.c ports/atmel-samd/boards/hallowing_m4_express/pins.c ports/atmel-samd/boards/monster_m4sk/pins.c ports/atmel-samd/boards/pybadge/pins.c ports/atmel-samd/boards/pygamer/pins.c ports/atmel-samd/boards/pyportal/pins.c ports/atmel-samd/boards/pyportal_titano/pins.c ports/esp32s2/boards/adafruit_magtag_2.9_grayscale/pins.c ports/nrf/boards/circuitplayground_bluefruit/pins.c ports/nrf/boards/hiibot_bluefi/pins.c ports/raspberrypi/boards/adafruit_macropad_rp2040/pins.c
So basically we want to verify that none of them are inverted pins? Where they have to be set to False to turn on in the end?
exacto
๐ฝ๏ธ
We have leftover grass fed ribeye. Huge slab of steak from a fancy restaurant. We had a really nice dinner last night.
sounds delish
@slender iron great progress on the highspeed USB, but why did it used to work?? until the dynamic USB came in, not sure I understand that; there are larger buffers specified in the compilation but maybe not for events
traces with working version might be interesting
@tulip sleet I did get one working trace from before. it did have one failed enumeration before going onwards
I still haven't figured it out. It's weird that it's getting into a state where the OUT packets are naked for two seconds
interesting, so it sounds like it was marginal previously; I don't know why there might be timing differences but there could be
One thing I notice on Linux is that when a board enumerates (any board), Linux USB seems to grind to a halt temporarily. I.e.g I am typing the equivalent of tio in a terminal after a reboot and the echoing is delayed. That seems very odd to me, as if the Linux driver is locking itself while enumerating
ya, maybe. one idea I had was to ensure we always queue the background correctly
will keep looking tomorrow
time to start dinner while I watch aae
good luck!
@idle owl at your leisure, perhaps of interest, there are other similar power control pins:
SHUTDOWNs:
ports/atmel-samd/boards/openbook_m4/pins.c: { MP_OBJ_NEW_QSTR(MP_QSTR_MIC_SHUTDOWN), MP_ROM_PTR(&pin_PB31) },
ports/raspberrypi/boards/adafruit_macropad_rp2040/pins.c: { MP_ROM_QSTR(MP_QSTR_SPEAKER_SHUTDOWN), MP_ROM_PTR(&pin_GPIO14) },
Non-Speaker ENABLEs:
ports/atmel-samd/boards/dynossat_edu_eps/pins.c: { MP_ROM_QSTR(MP_QSTR_SAT_PWR_ENABLE), MP_ROM_PTR(&pin_PA10) },
ports/atmel-samd/boards/robohatmm1_m4/pins.c: { MP_ROM_QSTR(MP_QSTR_POWER_ENABLE), MP_ROM_PTR(&pin_PA27) },
ports/atmel-samd/boards/feather_m4_can/pins.c: { MP_ROM_QSTR(MP_QSTR_BOOST_ENABLE), MP_ROM_PTR(&pin_PB13) },
ports/mimxrt10xx/boards/imxrt1060_evk/pins.c: { MP_ROM_QSTR(MP_QSTR_LCD_ENABLE), MP_ROM_PTR(&pin_GPIO_B0_01) },
ports/nrf/boards/teknikio_bluebird/pins.c: { MP_ROM_QSTR(MP_QSTR_LIGHT_ENABLE), MP_ROM_PTR(&pin_P0_30) },
ports/nrf/boards/TG-Watch/pins.c: { MP_ROM_QSTR(MP_QSTR_HAPTIC_ENABLE), MP_ROM_PTR(&pin_P1_06) },
ports/nrf/boards/particle_boron/pins.c: { MP_ROM_QSTR(MP_QSTR_UBLOX_POWER_ENABLE), MP_ROM_PTR(&pin_P0_25) },
ports/nrf/boards/microbit_v2/pins.c: { MP_ROM_QSTR(MP_QSTR_MICROPHONE_ENABLE), MP_ROM_PTR(&pin_P0_20) },
Other aux power controls, e.g.:
ports/esp32s2/boards/unexpectedmaker_feathers2/pins.c { MP_ROM_QSTR(MP_QSTR_LDO2), MP_ROM_PTR(&pin_GPIO21) }, // Second LDO Enable control
There are numerous NEOPIXEL_POWER and other *POWER* names (polarity not necessarily correct on any of these), and other non-standard names we'll probably have to find serendipitously.
Of note is that some aux power pins control more than one peripheral.
I agree about the naming of the parameter. What do you think about more specific ones fill_color_value and replaced_color_value
I like the idea of targeting the color at the location there, but I'd to provide the protection of also passing in a target color (whatever it gets called) if the user wants it. I'll try to make it so that parameter is optional, and if not passed it will target whatever color is at the location.
Good catch on the infinite loop. Thank you!
Also, I am not sure if this is related to #5004.
The reason why I came to that conclusion is because the issue author listed code.py as empty.
I don't mind closing the issue now as it can always be re-opened later if the issue persists.
Sure, I am working on a test for traceback module and I'll add this with it.
Thanks @dhalbert, this is fixed now.
This can't be done on the esp32s2. The support is for esp32 and esp32s3.
Check for SOC_SDMMC_HOST_SUPPORTED in esp-idf/components/soc/esp32XX/include/soc/soc_caps.h.
Looks like stm32f411ce_blackpill_with_flash ja build failed, it takes quite a lot of space compared to other languages.
got the two new Stemma QT RTC modules and rediscovered @onyx hinge's timeless post on telling the difference https://emergent.unpythonic.net/01594912346 ๐
@crimson ferry ah the best kind of help .. I can give it even while sound asleep.
issue author listed
code.pyas empty.
I overlooked this detail. perhaps there are two problems, ten.
Ah, I've learned to check if the URL says esp32s2 but apparently that's not enough to distinguish whether the functionality is actually available.
Thanks, anecdata! Appreciate you looking into this. We'll keep it in mind moving forward, for now, I think the plan is to do the SPEAKER pins properly. I do agree the NEOPIXEL_POWER pins should likely also be looked at because they're relatively ubiquitous, and I'd rather have a non-confusing standard for something folks are constantly using, but we'd have to be careful with that since people would already be using it.
@tulip sleet Ok, caught up on messages and dealing with Discord admin stuff. Going to start in on the SPEAKER_ENABLE situation.
Over in #5123 we disabled ulab on that board due to other code additions not fitting. Consider merging or rebasing master, so that you have that change in this PR.
Thanks yet again to @onyx hinge for the git ls-files command. Finding that list of pins was super quick.
I did some rewriting on the libraries page:
- Added link to readthedocs for all libraries.
- Reworked the .mpy explanation and other text.
- Added link to Libraries page in Welcome guide in two places
- Mentioned CircUp.
- Mentioned and linked to the Community Bundle. This could be expanded later.
- Redid headings a bit
I also revamped the top links a bit, renaming "API to "Documentation" "Help" to "Forums", and labelling the Discord and RSS links more explicitly.
The mobile header ...
@dhalbert This is an excellent update. I'll ping Justin directly to take a look, and then get it merged. Thank you!
@tulip sleet so, I'm not sure what I'm looking for in the schematic to tell me whether it's inverted. Circuit Playground Express and Bluefruit are not inverted because the CircuitPlayground library sets it to False to turn it off, and True to turn it on, so they're both consistent with SPEAKER_ENABLE. I'm looking at the CPX schematic. Basically, I'm saying, other than getting out each of the boards and testing them with code, or finding an example that already uses the speaker, I'm not sure how to figure this out.
@gilded cradle Do you have a Pi4 set up somewhere not in a case? Or I guess one not setup and an extra SD card sitting around? I put mine in a case before putting the SD card in, and it feels like the card is sticking out more than it should, and I have no frame of reference to know, so I was hoping someone could get a pic from the bottom of a Pi4 with an SD card in it.
The PAM8301 amp has a /SD pin, ("ShutDown"). the / prefix usually means that it's active low (ideally there would be an overbar over the SD, but the / substitute for that
you can see it's pulled up normally, due to R10, so it's normally on.
Oh I didn't even make the connection between those two bits
so if a board uses the PAM8301, then it's the same
the pullup, you mean?
Yeah
yeah, you have to match up the names. That's kind of an artifact of these CAD schematics. Connecting lines are often implied by names
Right, I understand that, but I straight up missed it here.
Didn't think to look for a disconnected pullup
heh
i was confused by that when I first started looking at them. I expected everything to be connected
Yeah, did you want a pic of what it looks like with an SD card?
Yes please.
I think it's probably fine, but I can't compare it to the slot because the slot is covered
it does stick well past the edge of the board when inserted
Yeah, that's the right amount
Ok then maybe it's fine
does it boot? or are you trying to diagnose why it doesn't start?
Hard to see the edge of the board in this case too
No I hadn't gotten that far. It seemed more sticking out than other Pis
so I asked first
People often complain about breaking the card in half cause it sticks out
Oh I assumed it was because I was an oaf ๐
I've ripped the socket partially off the board myself
Wow.
I ended up epoxying it back on