#circuitpython-dev
1 messages ยท Page 355 of 1
so the IDF API is not very consistent
is that true?
but UART does not have this problem, is that correct?
I would look at the IDF impl to see what's different about driver_delete for UART vs I2C, if one works but the other doesn't
Not sure what you mean by "works", works as in it doesn't shut down wifi?
They work fine for actually resetting the bus
That information from before is for a magtag project
Doesn't produce the same bugs we are seeing with I2C and wifi interactions
Right, ok, sorry wanted to make sure we were synced
TBH UART could cause the same issues and that simply was never tested
it would be interesting to test that, then
I'll give it a shot and see
@serene harness You have some kind of issue with line 63, also could you ask in #help-with-circuitpython. There are a few more helpers over there. This is more for circuitpython dev issues. Thanks.
Oh, I apologize. Thought that I was in that forum.
np! don't upload as a .odt. It's hard to figure out the line numbers. Just upload the code.py
@idle owl For data logging to CIRCUITPY, are there any recommendations for how to log? I've been doing this over weekend and I realised yesterday that if I keep doing this I might wear out my flash a bit prematurely: https://forums.adafruit.com/viewtopic.php?f=65&t=175527
@simple pulsar Oooh that's a good question. I'm not sure.
@slender iron apologies for repeating myself, but better to mention it in public. You were looking for a lost thread on double-tap-for-bootloader in rp2040. is this it? I wonder if this is the discussion of double-tap bootloader for rp2040 that scott was looking for: https://github.com/raspberrypi/pico-sdk/issues/87#issuecomment-773929609 -> https://github.com/raspberrypi/pico-examples/tree/master/system/double_tap_usb_boot
answered you in the forum. short answer is that 10 second cycles is pretty fast.
@tulip sleet thanks, useful to know
@tulip sleet So on the Pico, only the three pins can do analogue? 26-28?
looking ...
@idle owl, yes, the pins are fixed. GPIO29 is actually a real chip pin, but on the Pico, it is connected to a voltage divider to measure the 3.3V supply, and is not broken out to the edge.
ADC0, 1, 2,3 are GPIO26-29.
Right, fourth channel is temp.
@onyx hinge I was trying to remember where I thought I saw a schematic for doing the double tap in circuitry
Thanks Dan!
um...
channel #4 is temp ๐
The book seems to indicate there are only 4 channels
3 channels to GPIO, and a fourth connected to temp
it's wrong then
Hah ok
they are not counting the GPIO29 voltage monitor?
book is talkign about the board, not the chip
Oh right
So am I though
ok
It's super not clear though if that's the case. They talk about the chip in the same paragraph. Bleh. Whatever.
they were probably confused themselves
@tulip sleet on a debug optimized build, I still don't see anything weird going on during the Wifi/I2C conflict hang. It's just looping in run_code_py, and should be running background tasks, but it isn't maintaining the USB or keyboard detection. Makes me think that there's something going haywire in the I2C interrupt system, messing with USB interrupt priority
hmm! maybe time for some debug uart printouts
I just received a FeatherS2. Iโm trying to play with toggling the LED via a webpage. Has anyone gotten it to serve a page in AP mode? (I donโt want to connect to an existing network, but create its own point)
@scenic echo I recommend asking on the unexpectedmaker discord first
@slender iron they sent me here ๐
haha, ok. I don't know of any examples for that
@tulip sleet I remembered another weird thing I wanted to ask about. When testing the original issue, where the whole chip resets when you tried to use I2C after a soft reboot, it would only happen if I used board.I2C(), not a busio.I2C instance. Poking around, I figured the only difference between these two is that a board.I2C might have the object preserved for longer in a soft reboot? Or something?
Honestly I'm running out of ideas of things to try.
oh, and UART doesn't cause a wifi conflict. The underlying reset code is totally inconsistent between them though, so it'll be hard to narrow down what actual change might be causing this.
check where the board.I2c instance is stored, whether it's in the heap or separate. If it's separate, maybe it is being garbage-collected by accident. If it's not in root pointers or not handled in a _gc routine, then it's not being walked during gc and any objects it points to will be gc'd and possibly smashed
The underlying reset code is totally inconsistent between them though
that is telling, maybe
I think the board.I2C instance is just STATIC mp_obj_t i2c_singleton = NULL; in shared-module
when it's set, is it set to be a heap object? See how it's implemented on some other port, like atmel-samd
If anyone has a moment to review: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/1457
Added section at the end that covers removing/renaming boot.py from the REPL to allow for data logging without a ground wire.
@tulip sleet no, it's statically allocated
// Statically allocate the I2C object so it can live past the end of the heap and into the next VM.
// That way it can be used by built-in I2CDisplay displays and be accessible through board.I2C().
STATIC busio_i2c_obj_t i2c_obj;
but if its struct has internal pointers that might be heap allocated, then that's an issue
Oh, hmm, I see your point
so the second time around it will use the existing one. but maybe it got messed with during vm restart
i would again check if the port-specific code differs from, say atmel-samd
@idle owl where is guide page for this?
None of the above is port specific, it's all shared-module
@tulip sleet Not published yet. I can link you in Slack if you want.
yah
It's in the Pico guide
tnx
Linked
But I'm wondering here, if the IDF tries to allocate something in the heap, does that get cleared? Or does it have its own heap?
@tulip sleet If you have suggestions, we can chat here, I try to avoid putting the internal links in public channels.
aprvd
Ah thanks!
I'm going to try what Bruce suggested and update the IDF to something more recent, see if that helps
Some notes from testing today:
- The current I2C problems (crashing or failure after soft reboot) do appear to have been caused by #3803, as reverting it (by re-adding the
i2c_driver_deleteto reset/deinit and having I2C initialize new drivers on reboot) solves those issues. However, as predicted by @skieast, it causes the Wifi/I2C conflict hang in #3743 to appear again. - It is not clear what causes this conflict hang. Circuitpython is still looping properly in
run_code_py(so it isn...
Good afternoon all you wonderful folks -- happily lurking/text only. Updated the notes doc with those details. Will be updating myself with a hot cup of tea. ๐ต
<@&356864093652516868> CircuitPython Weekly is in ~15 minutes. Please add your notes to the notes doc. If you're listening in or lurking, please add your name to the lists under Hug Reports and Status Updates alphabetically with (lurking) after it so we know to skip over you. Thanks much!
wow, forgot all about that
How's the progress on this coming along? I'd like to update in order to try and make more progress on the ongoing I2C problems. To clone someone else's branch, you can follow the instructions here, it's not too bad, but you do need to make sure your PR is marked to accept contributions.
@jepler quick ping for your review again, this should be good to go.
Mostly lurking, but should be able to hop in for my "in the weeds" topic if need be. However, I'm fairly certain I'm not a CircuitPythonista. Probably more CircuitPythonistish ๐
@fossil gorge Welcome to the role!
I just added you ๐
We both did ๐
great minds think alike ๐
lol, thanks. It's all downhill from here folks!
Mostly coz it's snowy and iced over in Dallas
Thankfully it wasn't bad in NJ....early projections were 1/3rd inch of ice. We barely got any.
What happend to the pinned messages?
@solar whale They're showing up for me.
I have other issues with the 4.3 beta idf. When I get home later I will try to see if itโs i2c related or some other incompatibility. @analog bridge did a branch of the IDF that compiles but has issues. I fixed some but it still crashes often. Unrelated to i2c probably.
I think it's a Discord glitch.
they're back ๐
Magical!
@supple gale thanks for the update - I've spent more time digging at the I2C bug but I don't think I've turned up anything useful, unfortunately.
When we lose power -- it's squirrels....
I think I'm going to put it down until we get the 4.3 update changes together, and start afresh from there. No point in solving a super-involved bug if the next version update breaks it again.
lurking
Had squirrels take out my internet before
Had that happen at work before. Fun times..., after they sent us home for the afternoon
Iโm out now. As I posted on discord the branch from microdev compiles but had some issues. I can get i2c scan to work but otherwise it is very unstable. Will try some code later to see if crashing is general.
I've had squirrels in my home....put cashews....in the shoes under my bed. That was a great thanksgiving vacation, coming back to that.
What -- no squirrel emoji!
๐ฟ๏ธ
That's not a squirrel!
"Where's Eddie? He usually eats these things"
- C.W. Griswold
๐ฅ
@tannewt Thanks for the review.
flash_range_program() accepts 256 aligned write... flash_range_erase() can only erase in 4k alignment which I think is the cause of a bug I am facing... writing at the same address twice is not working. The stored value turns to 0 when a second write attempt is made.
Buffering in the whole sector... then erasing it and writing might fix the bug but this is highly in-efficient and buffering in the whole sector is also causing a crash.
We're soon changing how lurkers work a little bit, stay tuned. (not today)
anyone else having trouble accessing the Google Doc?
@solar whale it's fine for me, was just editing it
@solar whale No... it's all issues for you today!
just came back to life -- must have been a squirrel ๐
[they think I'm a real human!]
I'm not a cat!
Lurking
Not my favorite designation. I'm just listening.
Meeting times are also available in iCal format using the following link: https://raw.githubusercontent.com/adafruit/adafruit-circuitpython-weekly-meeting/master/meeting.ical for use with standard calendar applications or in your browser: https://open-web-calendar.herokuapp.com/calendar.html?url=https://raw.githubusercontent.com/adafruit/adafruit-circuitpython-weekly-meeting/master/meeting.ical
Built myself a drum machine with a @Raspberry_Pi Pico and @pimoroni's RGB Keypad. So much fun! ๐๐ฅ๐ https://t.co/XjSBtJquxx
132
@Raspberry_Pi pico with @pimoroni Rgb Keypad with @adafruit @CircuitPython thanks to @sandyjmacdonald for the code and iPad Pro and Pico from @microcenter #toomuchFun https://t.co/Fw8hYEjdEO
RGB MIDI controller example for Pimoroni RGB Keypad for Raspberry Pi Pico - code.py
Receiving (rather than sending) MIDI on the forthcoming RP2040-powered Tiny2040 from @pimoroni. MIDI notes over USB make the LED light red, but you could hook up a whole chain of NeoPixels and have them blink in time to your music, or have solenoids hit a real drum, you name it! https://t.co/eRpmdG5XF9
Building a 3.3V friendly #MIDI IN circuit for the @Raspberry_Pi #RaspberryPiPico and the @adafruit Circuit Playground Express #CPX and a simple MIDI monitor in (Circuit|Micro)Python https://t.co/fKPdzc9sNj via @wordpressdotcom
https://github.com/adafruit/circuitpython-weekly-newsletter/tree/gh-pages/_drafts -- submit a pull request. You may also tag @anne_engineer on Twitter, or email anneb AT adafruit.com.
port_init works... since this is a small change I might include it with my UART work or maybe you can fit it in somewhere. :)
Haha I didn't read it off because the name was so long ๐
Lurking
it took me days to memorize lywsd03mmc well enough to type it without copy/paste
looks like a cheat code
Tuned in just in time for a listen.
TIL that even with PTT, you need to unmute Discord. The more you know...
just stopping by to say hi ๐ to all <@&356864093652516868>
I had no problem getting the gamepad examples setup but those examples have the same problem I was talking about. No way to implement analog trigger buttons. Only the analog sticks and 16 buttons. It appears to just not be implemented in circuitpython at all and I can't parse the micropython well enough to see how to add it. @steep finch mentioned they have a fork exposing those buttons, but I couldn't find it. @steep finch do you have a link? I should asked earlier.
Sorry. Lurking
yeah you did, I didn't get it in the doc
@low sentinel are you lurking?
Yeah! Just realized this was happening with the role ping.
๐
in case anyone else wonders about those pieces of software: http://astyle.sourceforge.net/ https://clang.llvm.org/docs/ClangFormat.html
oh there's another one -- http://uncrustify.sourceforge.net/
Issues and PRs - a good place to contribute and enhance, and scratch some of that "code it from scratch" itch
belated hug report to dan for doing that sdcard work
2nd usb channel is amazing
^^ uncrustify is what MicroPython finally settled on
I use that with a car dashboard with particle photon. I can log and drive the display with a serial test harness over usb. Just luxury ๐
@bleak spear https://github.com/alexbartlow/circuitpython/tree/hotas This is my fork that gives the default gamepad 6 axes, 6 hat switches, and 32 buttons
@bleak spear I'm going to rebase it after the pico gets UART support
I seem to recall that the sphinx generator also creates man pages, PDF, and some other file formats. Are those not published or available anywhere?
Alternatively (but bandwidth and time consuming), clone the repos, and build the docs?
@fossil gorge at a page like https://circuitpython.readthedocs.io/en/6.1.x/README.html click the triangle in the lower left, there's "Downloads - PDF"
so now I know that there are 248 pages in the circuitpython (6.1) manual. wow.
Thanks @onyx hinge - heads up for @thorny jay about it!
My suspicion is that there's some rtos thing like a mutex or a task that is getting confused. just a theory, I couldn't prove it.
@bleak spear https://github.com/alexbartlow/pico-hotas I have a build for the pico here that has some sample gamepad code just to kick the tires
My plan was more to backup my internet provider that is "cable/TV" with a second internet provider by a ADSL/Telephone. Maybe this is overkill for one outage a year, but I don't want to live an internet cut of 3 days again... 4G/LTE is a good enough backup but maybe not for voice/video and a full family at home.
Never let the boss test...
Great to hear about everyone's work and projects!
Have a great week all ๐ , have to duck out.
๐
that sounds like a lot of work
@idle owl will there potentially be a new twitter handle to tag?
@idle owl cpnews@adafruit.com and for Twitter, you put @CircuitPython in the tweet?
Widgets: Button, Progress bar, Sliding switch, Needle dial gauge, Scrolling value selector, Widget label, Widget indicator (label plus arrow)
I second it being in pre-commit
+1 from me for moving it into pre-commit as well. I still sometimes forget to run one or the other.
As new user I will love a pre-commit
Have a great week yโall!
the rp2040 datasheet states that I2C peripheral mode is supported
Thanks I will see the M4 implementation
Is the concern about the time to sort, or the dirty rectangle that results from it?
It's GPLv3 so you may not want to add it...
Compatible with MIT but will be "contaminated".
So "macro" kind of feature?
was just going to mention .wrap_target
Ok, great. I'll see how I can use it for testing.
More about regression checking.
Thanks.
I will start with accumulating example and expected result.
@narrow dirge was testing with the comma with or without a space on the left and the right...
too big to fail test
For David and for everyone else, yes I think tag (at)CircuitPython or (#)circuitpython on Twitter with your newsletter projects and ideas. I haven't gotten confirmation from Anne on that, but I'm pretty sure that will work.
Anna was picking up project like that.
At a time I was doing "one project a week", but I failed a bit, or not interesting enough to be spread in newsletter.
Thank you!
Thanks everybody!
Thanks!
Thanks y'all!
Thanks
Bye
Another successful meeting in the bag ๐
You know it's cold when C and F are the same...
I was considering checking all the meeting notes and pick what I did over a year... and what I had plan and did not.
Cookiecutter issue opened. Feel free to assign the issue to me
+45F right now in NJ
That is correct, yes
Thanks! ๐
@idle owl in the "how to contribute" do you have separate instruction (and cookiecutter things) for Adafruit library and Community library?
@thorny jay I haven't actually checked. Foamyguy updated the guide, I'm not sure exactly how he did it.
It's the same basic instructions. The first prompt asks you which you want to do.
Yeah, there was that list of change to do to use it for non Adafruit library.
It's automated, great.
The defaults are all good now I believe. If you choose community bundle it should have sane defaults for many of the fields. If you end up running it and notice there are specific prompts that could use better or additional wording in the guide feel free to ping me.
Dropping off. Later!
Thank you again!
@tulip sleet Disconnected you from the chat so nobody jumped in and started talking.
tnx - i was loading the dishwasher
@tulip sleet Any thoughts on this one? https://forums.adafruit.com/viewtopic.php?f=60&t=175459
@idle owl sleep(0.00001) is 10 microseconds. time.sleep() is not good for that. It might not sleep at all or be highly inaccurate. Try microcontroller.delay_us(10) instead, but that might not be great either.
something like pulsein would be a lot better
I shrank a number of builds and will try a re-run.
@dhalbert It doesn't look the pipeline ran again. Anything I need to do?
hmmm here's another puzzler -- PioPixl8 needs consecutive pins. There's not actually a way to check that is there?
from python
you could get the microcontroller.pin equivalents and deconstruct the pin names ...
but no easy way
I think a did a re-run but it failed. I don't see a "Re-run" button anymore, maybe because it's too old. Could you merge from upstram and push a new commit?
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/10c1pc8x_d5PM5QPUSj9Ex0OfgyFvTiLZV9Cuno_UQDI/edit?usp=sharing
CircuitPython Weekly for February 22nd, 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 particip...
I am running circuitpython 6.2.0-beta.2 on a Feather S2 (ESP32S2). For the libraries adafruit-circuitpython-bundle-6.x-mpy-20210214
I have tried using the guide from adafruit under https://learn.adafruit.com/mqtt-in-circuitpython/circuitpython-wifi-usage as well as the examples included with the lib.
The code is returning an error:
Connecting to Adafruit IO...
Traceback (most recent call last):
File "code.py", line 77, in
File "adafruit_minimqtt/adafruit_minimqtt.py", li...
@onyx hinge @slender iron FYI I updated the CP Weekly template with the new suggestions for submitting newsletter ideas. It now reads You may also tag a tweet with #circuitpython on Twitter, or email cpnews@adafruit.com. Letting you know so you're aware for when you next run the meeting, in case you have that part memorised and don't read it from the doc.
wheee! "piopxel8" now works with the LED animations library. I'm running a different animation on each of the 8 independent strands right now.. (only 2 are wired up but I imagine the rest in their glory)
nice!
it seems reasonably fast with 240 pixels but I don't necessarily have a point of comparison. @slender iron do you think that (A) I should implement piopixl8 as a core module or (B) expose this extremely specific bit_transpose routine to Python? I don't want to go down the wrong route with a pull request.
Brilliant!
(can't you do 16 that way too?)
@slender iron the transposition routine is specific to working in 8-bit (8-strip) units. as for working on other ports, I guess there was a long ago failed attempt to do something similar to this on samd with spi dma but it didn't pan out (maybe not even in CP; limor mentioned paintyourdragon worked on it)
(so not 2, 3, 4, ..., 7 strips either -- only 8)
@onyx hinge Unrelated, check the #books-and-tutorials channel - potential feedback on the canio guide. I asked them to submit feedback through Learn, but I know it's difficult to get through all of it.
only 8 if you are outputting via shift register
you could do an odd number with a single PIO state machine doing similar
the "bit transposition" code is very specific to working with a unit of 8 strips, in order to be efficient.
it has to take the first bit for each strip and pack it into 1 byte, etc
right, I get what you are doing
I'd probably lean towards B, a bit manipulation library
time for me to eat lunch
To do 16, aside from needing a different transposition code, you'd need to double the speed of the pio peripheral to ....83.2MHz?
Do all Adafruit CircuitPython compatible microcontrollers have super specific PWM "slices" like the Pico does? As in are there usually conflicting pins where if you used a certain two pins it could be conflicting PWM? I'm not sure how to ask this question.
@idle owl short answer is often they do.
and, like unhappy families, they are each different in their arbitrary-seeming requirements
We have that script that tells you which pins have PWM, but not if they're conflicting.
you can go read a datasheet? which we like to do for fun, yes we do
Oh.
Fair enough.
And is it true that if you have two things on conflicting PWM pins, and you send an instruction to one of them, it affects the other one too?
But to be less flip, no, I don't think we've tried to docuement in a "regular people"-compatible way, the specifics of this; because it can be complicated.
Also fair enough.
Generally speaking, the core should raise an exception if you ask for something the hardware can't do. There could always be bugs, of course.
This book seems to indicate that it won't error, it'll simply send the same instruction to both pins.
is that describing mp or cp?
Presumably meaning an LED each on two conflicting pins, and you PWM one pin, it will affect both.
MP.
presumably
I thought it might be a hardware thing though
I wasn't attributing that concept to MP.
If they have an example of that circumstance, you should adapt it to CP and try it. I think we would want it to throw an exception.
I don't think they have an example. It was an explanation in the copy.
for instance, if pins 99 and 53 both use PWM unit "sqrt(2)", then they have to agree on the frequency when they are created
Says basically you'll know if you use conflicting PWM because it will affect both pins, and if that happens, check the pinout and try again.
I could try it, the pinout is in the book. I know two conflicting pins.
0/1/16/17 are all tangled together for instance
Right.
Quick hardware question, the ground rail on a breadboard is simply connected pins right? So I could use it to route an LED via a resistor? Or is there something special about the power and ground rails on breadboards other than connectivity?
>>> q = pwmio.PWMOut(board.GP1, frequency=800)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: All timers for this pin are in use
>>> q = pwmio.PWMOut(board.GP1, frequency=400)
>>>```
Kind of dumb question I guess. But still, question stands.
Ah ok. Timer in use.
so in CP if you ask for different frequencies, but the pins have to SHARE a frequency, it says "no"
Good news! Alright
yes that's what it's there for, all pins connected on a rail
That is way easier to explain than to say "read the datasheet!"
Because GP0 and GP1 are on the same "PWM slice" 0 but different "PWM channels" 0A and 0B. If you use GP0 as PWM, you can't use GP16 as PWM even if they share frequency=, because they are the same "PWM channel" 0A. But yes, short story, CP tells you about this kind of limitation with an exception
Ok. I think that's good enough for the purposes of this guide. The book gets into that level of detail, but I would have to explain a lot of other things in that level of detail as well... I'm not prepared to do that I think.
@idle owl thanks for the other mention .. I fixed the typo
Right on - can you ping the poster to let them know?
oh sure
Thanks!
@onyx hinge But I'm reading this right that every pin can do PWM? but not at the same time obvs.
Wait. Put simply for the Pico, you can do PWM on one side of the board or the other, but not both at the same time if you want to be guaranteed to avoid conflicts. Not sure that's worth including in the guide though.
@idle owl yes "All 30 GPIO pins on RP2040 can be used for PWM" though with CP you won't be able to do more than 16 simultaneously
Right on. Thank you.
(with MP or C++, you could sort of go past 16 but it's not clear whether that's useful)
(because some pairs of them would be exactly identical)
(hmm yah)
(actually ... no, wait, I don't want to go further into the weeds than we have)
๐ Appreciated.
(using a feature of the RP2040 chip that CP doesn't make available, I think you can cause the PWM output on pins 0 and 16 to be exact opposites which is useful to someone, somewhere. don't write that in the guide)
Ok, in some brief testing with idf v43-beta1 it seems like the i2c is better. also when i import wifi it doesnt crash. I was having lots of issues probably related to intermittent usb cable connections, a hazard of working on a laptop on my couch.
Onward to actual code.
OK drop everything & update idf now
For RP2040/Pico, it sounds like it can do 16pwm on GP0-GP15? I can't get this to work: https://github.com/adafruit/circuitpython/pull/4167#issuecomment-779491927 Should i log that as an issue?
See
https://learn.adafruit.com/circuitpython-essentials/circuitpython-audio-out
to get started.
Fixes #4037
Why is there an underscore in the name?
I thought it might be appropriate to distinguish them from the Micropython battery of tests that are run automatically by
run-tests. The rest of the tests in that folder are very uniform in style and purpose, and these are different enough that I thought it'd be worth prefixing them.
If anything we could do circuitpy-manual to mimic what we do in py.
Note, I added manual with my audiopwm changes that were merged in already.
I'm not really liking all the full path includes. I changed them to most;ly match how the IDF does its includes. I think this might make it easier for future IDF releases.
Why not? I like the full path because that makes them easier to find. I dislike having super long include directory lists and include filenames that look like they come from the same place but don't.
On the Discord it was suggested you could fork my fork, but I know you can't do that really without removing other ...
It's the peripheral itself that can't do a zero length write. To do it ourselves we'd need to bitbang it.
@kevinjwalters Please file new issues that refer to a PR. Discussion on a merged PR is hard to track.
(For those following along, the library finding issue was due to this PR not being in beta.2. It was merged after and is available in "absolute newest" builds.)
@idle owl hey. i'm about to start something that'll essentially be a data logger. been seeing your recent traffic on that, but haven't really followed it. just curious if anything has changed?
PWMOut was not made available in pulseio because the rest of pulseio hasn't been implemented on the RP2040. All new code should use it from pwmio anyway (pulseio.PWMOut is deprecated.)
I wrote up a clearer boot.py file, and I added a comment to the basic data logging code.py that explains that errorno: 25 is filesystem full because it was dreadfully unclear. Other than that, not really. Want links?
yes please. i'll take a look.
https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/Getting_Started_With_Raspberry_Pi_Pico/data_logger_boot.py and https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/Getting_Started_With_Raspberry_Pi_Pico/data_logger.py
@tidal kiln As far as I know?
@slender iron why do you keep both native_layer and original_layer in the group children?
okie doke. cool. thanks for the links. yah....looks pretty much like i remember.
@tidal kiln But you can do it like I linked where it requires a pin to be grounded or a button to be pressed (depending on what board you're using) at startup for it to data log. Or not. Up to you.
Yeah, it's pretty much the same.
This is my first time reporting a bug. When can I expect a fix?
Unknown. This isn't a priority for Adafruit-funded folks at the moment. There are many other things we're working on now.
I want to change the frequency in a function, both GP18 and GP19 to same frequency. How can I do that ?
The CircuitPython API doesn't allow for two PWM outputs to share a variable frequency. Instead, variable frequency requires separate underlying hardware. On the RP2040 that means separate PWM slices.
Yeah. Otherwise, you can get out of a writeable state using the REPL and os.rename or os.remove on boot.py.
But a button makes it a little easier if it's a reasonable addition to your project.
What breakout are you using? Does it include pull ups?
by the way I'm using that in boot.py (and a button on a breadboard) to have safe mode on the pico, I needed it to test a bug that makes the board hang
https://gist.github.com/Neradoc/8056725be1c209475fd09ffc37c9fad4
Oh interesting. I guess I should have known you could reboot into safe mode using software, but I've never seen it done.
I'm also very concerned about the support burden of native modules that work for ARM but not xtensa or risc-v for example. I'd encourage folks to write native modules in the core instead. We're happy to have them.
wondering if i could use nvm to maybe do this from user space....set a flag there, reset, read that in boot.py.....hmmmm
We discussed this in this week's meeting: https://youtu.be/I4uqbDT59Us?t=4446
My suggestion was to move Group to using a proper list for holding its items.
This only works on even pins, the rest are left low judging by LEDs on a Cytron Maker Pi Pico I've been using:
Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; Raspberry Pi Pico with rp2040
>>> import pwmio
>>> import board
>>> pins = (board.GP0, board.GP1, board.GP2, board.GP3,
... board.GP4, board.GP5, board.GP6, board.GP7,
... board.GP8, board.GP9, board.GP10, board.GP11,
... board.GP12, board.GP13, board.GP14, board.GP15)
>>> pwms = [pwmio.PWMOut(p, frequency=2000, duty_c...
you can!
here's boot.py:
import storage
from microcontroller import nvm
storage.remount("/", nvm[0])
and then in user code, can do something like:
>>> nvm[0] = False # or True
>>> microcontroller.reset()
Fancy!
note that currently on the S2 nvm[0] will raise an exception if it was not set before
like if you just did print nvm[0] without do anything else first?
oof. thanks. good to know. luckily i'm using nrf52 for this particular project.
it's implemented with a key-value storage in the background but there is no way to probe the key it seems, so the only way is to try/except, which is less than ideal
@idle owl anyway to check current fs state? other than trying to open and catching exception?
Not that I'm aware of, but that doesn't mean that's not the case.
I would have thought ENABLE_JTAG would be sufficient. When i compile with DEBUG i lose the I2C pins on the board I am using.
I may be completely misunderstanding the reasoning.
Thanks
I (also) hope there's no lurking reason not to remove DEBUG from that logic https://github.com/adafruit/circuitpython/pull/4131#issuecomment-778834022
@tulip sleet @solar whale just fwiw/fyi - still getting USB hard locks after upgrading to ubuntu 20.04 laser eyeball tiger cat
I get them occasionally. Totally unpredictable.
it seems to always be related to a soft reset
but as to when and why...???? yah totally random
laser eyeball tiger cat ๐
Once we have a way, we can replace secrets.py use with it. os.environ is the common way for sharing secrets in CPython. For example, GitHub Actions secrets are provided as environment variables.
well tbf i dont know the crypto implications - i am not sure how we seed the pico's RNG. i will leave open but yah maybe can you submit a PR to change RSA lib to use random. instead of os.urandom if it throws an exception?
random will use the time you first call it to seed the pseudo-random number generation if urandom isn't provided. It should NOT be used for cryptography. This true in CPython as well: https://docs.python.org/3/library/random.html Anything that doesn't do cryptogr...
If a child is a subclass we internally want to use the native superclass but need the original (subclass) to return when folks access it.
+1
I'm looking to connect a serial LCD and GPS for telemetry and speed in a vehicle.
I totally agree we could do this better. I think our best option is to take in the filename instead of a file object. That would imply that OnDiskBitmap manages when the file is open.
There aren't great places to throw an error when a used file is closed because display updates happen in the background. In this example, we could have TileGrid raise an exception but you could always put it in the with statement as well and then expect it to continue to work.
So, I think taking in the f...
I think the simple route is your only route. The complex route risks not actually updating a portion of the screen because dirty areas only come from TileGrids IIRC. TileGrids need to know when they are hidden so they can provide the area where they were rendered last (but not where they are now.) hidden_by_parent is separate from hidden because the public hidden attribute is for the TileGrid only.
@tidal kiln I've found holding down the button on the CLUE works well for enabled write access in boot.py
It's more useful than I thought because it means the data logging code doesn't start writing when I plug it into desktop to retrieve data. I append so it would be safe (in term of not losing data) but it's still more convenient for my case to have the writing be very explicitly enabled.
thanks. yah, i might end up going that route also.
@slender iron You were still planning to change PIO pin initialization correct? I (think) I figured out how to get the 8 pins for ParallelBus going, though to run an init program more then 1 instructions have to move the pio_sm_set_enabled to after the init instructions get ran. But if it's all going to change i'll just sit on this until then.
this is something i'm wanting to be sort of plug-n-go and auto-magic. at least for my initial thinking.
@blissful pollen ya, I'm planning on it
gonna just add a ton of initial_*_values as kwargs
with sensible defaults
okay i'll sit on ParallelBus until after that, if that makes sense?
no problem, just wanted to make sure (and had meetings all CP meeting earlier today)
np, always feel free to ping me to coordinate
I'm hoping to go heads down on it tomorrow
finishing up email now and then I'm making dinner tonight
Buffering in the whole sector... then erasing it and writing might fix the bug but this is highly in-efficient and buffering in the whole sector is also causing a crash.
Yes, it is inefficient. It's also the only way to do it. Programming flash only sets 0s. It cannot change a 0 to a 1. Erases reset everything back to 1. So, you always need to erase and then program in the smallest erase block size.
Also, be aware that the SDK checks may only be active during a debug build. So if it's...
change to save storage seems fine to me. though, rgbmatrix and sharpdisplay both become less useful without framebufferio so consider disabling them as well in a future commit.
This sounds very cool Jeff... can't wait to see the demo !
It doesn't "look" like much yet. ```code.py output:
?0100010-001000010-000100000-
-00100011-001000001-000000100-010100010-001000010-000100000-
(21, 45, 21, 13, 0, -200, 0)
-00100100-001000001-000000100-010100010-001000010-000100000-
(21, 45, 21, 14, 0, -200, 0)
The symbols 0, 1, - and ? appear, about 1 per second. When 60 of them in a row "make sense" it prints the time: 2-digit year, day-of-year, hour and minute GMT, and some other information (about leap seconds and daylight saving time). The time is the minute that _just ended_.
the receiver is very noise-sensitive so I have to test & debug it from a battery-powered laptop. I think 60Hz noise from the mains may be particularly able to interfere with the 60kHz radio signal.
What are you using to receive it?
Looking for an interesting display concept, but I also need to figure out the power issues
https://www.sparkfun.com/products/retired/10060 [no longer available]
Oh neat. I've received it on an RTLSDR. I wonder if ferrite beads on the cable would help but the antenna wire is pretty short
Thanks for making this issue!
I believe board is the right way to approach this problem. It's meant to hold board-specific initialization in a cross-board way. Generally, there should be a standard name for an object that has an expected API. Currently most attributes are pins but we also have I2C, SPI, UART and DISPLAY already.
Let's take these one-by-one:
Buttons
This looks like we need a way define standard Gamepad objects with a standard pressed mask OR we need an async way...
@slender iron but calculating the native type doesn't seem to be that expensive?
My friend who has built several WWVB clocks just says to add filtering on the power input to the reciver until it works
Makes sense. Radio always hurts my head when all the interference can come into play.
seems like a modern alternative is https://www.universal-solder.ca/product/canaduino-60khz-atomic-clock-receiver-module-wwvb-msf-jjy60/
Right now I don't forsee any port-specific code, so does it need anything in common-hal for each port?
Nope! You can just put it in shared-module then.
How do I tell the build system to include the new files when I build a given port?
Take a look in py/circuitpy-* files. There is a regular pattern to new modules there.
Ok great! Thanks @dhalbert
@slender iron any name suggestions for this new function & its module for re-ordering the bits for piopixl8? I called the function bit_transpose and put it in _pixelbuf for testing but I don't think we want it in pixelbuf permanently.
probably pre-mature optimization ๐
.. it's tempting to see if we can get to 16. can the PIO divisor go all the way to "1"?
(16 strands)
see ya
@slender iron ok, thanks, I will try with storing only the original type then and see how that works
@onyx hinge you should support less than 8 inputs and just pad the byte with 0s
some folks will want to use it with fewer than 8
@slender iron I can benchmark it but I think it will make the speed worse
people will still want to do it
I agree, but it'll hurt performance, or burn flash space
we've got a ton of flash space on the rp2040
adding 6 conditional branches to each byte handled
or adding 6 copies of the critical function
~200 bytes apiece, so +1 to 1.25kB?
@tannewt I see the basic idea of what you are talking about for adding a new directory for bitmap_tools in
shared-bindingsand then for each port inports\common-hal, but I don't understand the specifics to pull it all together.
adafruit_bus_device was similarly python code moved to the core so that may help you see what for something similar. Feel free to ping me on discord too as someone who just recently did this from a newbie point of view.
or making 6 extra buffers to get bytes from
I allocated 1MB for the CP flash space
for a reason ๐
I'll consider your feature request ๐
gotta give folks a path from 1 to 8
If youโve got the space split it in two ๐
I could do one optimized for 8, and one branchy for 2..7.
sure
it'll satisfy my peculiarities for optimization, but give flexibility, and only cost ~200 bytes
awwww but they were comfortable there
This fix seems to change refresh behavior:
import time
import board
import supervisor
import microcontroller
from adafruit_magtag.magtag import MagTag
def show():
for _ in range(0, 5):
print(" ", _, "\r", end="")
magtag.set_text(_)
time.sleep(magtag.graphics.display.time_to_refresh + 1)
magtag.graphics.display.refresh()
time.sleep(5) # time to get serial console connected
magtag = MagTag()
magtag.add_text(
text_position=...
Ah the plot thickens. It's probably best to leave it alone rather than changing parameters and breaking existing users' code. Thank you for the explanation.
We can find something else to remove instead. We were not able to understand why the ja build suddenly seemed so much larger.
there are no pullups visible on it, pull up resistors (2K - 10K) are required
@jepler @dhalbert I really wouldn't worry about it - the STM32F401xD line are very tiny chips that we only see used on the Espruino Pico. It'd be a poor pick for any form of display work anyway.
If anything we could do
circuitpy-manualto mimic what we do inpy.
That sounds good to me, since there's already a convention there. I'll change this PR to merge the two under that name.
@onyx hinge Did you do the PWMAudioOut for RP2040? I've noticed it's a bit quiet on the Cytron Make Pi Pico's speaker - similar volume to CLUE which has a much smaller speaker and is driven in similar way.
nope, it was scott
@skieast If it reverts the I2C reset changes, and crashes when it's reloaded, that sounds very much the same as what I was experiencing when I reverted #3803. What do you find to be different, compared to before?
I'll try compressing it (the sound sample) a lot to see if that improves things. There's a huge difference between PWMOut square wave and square wave played over PWMAudioOut.
I'm currently testing with the 4.3 branch of the idf. I2c works with changes to i2c.c. Still crashes when wifi is used and the app reloaded. However before just doing an import wifi would crash. Now it gets farther. I'm out now so will look some more later.
@skieast interesting. I never got a crash on the import of wifi, even on the existing branch of the IDF on Circuitpython main, and your experience is the same as my current Main branch testing. So it doesn't sound like the upgrade to 4.3 has changed much.
If anything we could do
circuitpy-manualto mimic what we do inpy.That sounds good to me, since there's already a convention there. I'll change this PR to merge the two under that name.
Ok, thanks!
It's possible that the device doesn't like how we probe the address. We usually do empty writes but the peripheral can't do that.
We can definitely evolve it in this direction. It just takes time. In 6.x or 7.x we can add support for string inputs but leave the taking a file object in. Then in 7 or 8 we can remove the backwards compatible support.
We usually assume that you want SWD or JTAG access. We usually will reset pins back to their debug state but allow you to use them if you want.
No errors are thrown right? What does the non-working signal look like?
I've not looked at signal, the relevant LEDs on the pins appear to be off so it's likely to just be held low.
I slowed it down so I can see what's going on, GP0 flashes as expected, GP1 doesn't flash and appear low for this:
Adafruit CircuitPython 6.2.0-beta.2-18-g2a467f137 on 2021-02-15; Raspberry Pi Pico with rp2040
>>> import pwmio
>>> import board
>>> p0 = pwmio.PWMOut(board.GP0, frequency=2, duty_cycle=32768)
>>> p1 = pwmio.PWMOut(board.GP1, frequency=2, duty_cycle=32768)
>>> p0.duty_cycle
32768
>>> p1.duty_cycle
32768
Thanks.
I'll take a look at the MicroPython later and get back to you.
@simple pulsar i'm trying the hold button approach on CLUE for enabling write access. but it seems to go into bootloader mode when a button is held during reset. have you seen that behavior?
I believe that holding both buttons puts it in dfu mode, but that's different
i'm doing just one. and either one does it.
Does CircuitPython do something special with duty_cycle using pwmio on Pico? I wrote some simple code that uses a potentiometer to fade an LED, but it is not behaving like this MicroPython book seems to indicate it should be. Turning the pot fades the LED from off to bright, over the full rotation of the potentiometer. The book seems to make it sound like it should reach max brightness at 1024/65353 in the potentiometer rotation range unless I do something else to the code.
@slender iron Is this the expected result of using a pot with PWM to fade an LED? Or is there something weird going on...
Here is my code ```python
import board
import analogio
import pwmio
potentiometer = analogio.AnalogIn(board.GP26)
led = pwmio.PWMOut(board.GP14, frequency=5000)
while True:
led.duty_cycle = potentiometer.value```
it should be over the full rotation
Ok, so CP is doing the duty_u16 MicroPython thing in the background?
I don't know what you are referring to
both duty_cycle and value are defined as 16 bit values in circuitpython
Ok then yes is the answer to my question. Thank you.
How do I determine a good frequency for PWM? There's an example using 5000 for fading an LED, but 1000 seems to work as well.
There must be a reason to it.
Ah ok
there can be secondary things as well, like electrical interference
or even auditory
i forget what the technical terms is for "the freq response of human eye", you'll see it come up in POV discussions. as i remember, it's pretty low
Fair enough
tv/movies for example are O(24-30)Hz
and if other sensors, like digital cameras, need to be considered, then that can up the threshold
you might want to avoid being too close or a multiple of a camera's frequency like 60fps, lest the picture flickers when filming
Thanks @tidal kiln
"why not just set it crazy high and forget about it?" <-- also a good question ๐
Well? ๐
too high and you'll lose resolution
I mean, I went with 1k to match the book example. But still worth knowing. ๐
ya, that'll be fine I think
The code and hardware works anyway.
its 125000000 / (2 ** 16) for the fast full resolution
hmm. Fair enough.
>>> 125000000 / (2 ** 16)
1907.3486328125
it's the 6 in the decimal that really matters ๐
but, yah, 1k better than 5k to get you the full res.
@tulip sleet I'm working with the Monsoon today and I just wanted to double check - I need to actually have two USB B cables in order to measure USB power draw? IE the monsoon itself can't provide power over USB. Is that right?
It seems like what the manual is implying but I'm not totally sure
I'm trying to remember what wasnt working when I did my PR back in december. At that point I think I was using the REPL,
import i2c
import wifi
i2c = board.I2C()
(then some sort of loop doing nothing)
Interrupt this code, then start entering it again. Would hang at the import wifi statement.
At least thats what I remember. No real difference.
So if I compile with DEBUG=1 and ENABLE_JTAG not defined I should be able to use the pins in question for something other than SWD/JTAG? If so this doesnt happen as I cannot define an I2C bus on two of the pins. Pin in use error I believe.
thanks
I think that's right. I actually didn't use it much or at all to measure USB current draw, because I wanted to see sleep current, and if I powered via USB, I would be measuring the regulator dropping 5V to 3.3V, etc.
so I used the binding posts
Oh, that's a good point. I didn't do that and was surprised it wasn't lower. I'll have to go back and re-measure my control.
there is a dialog box to set what voltage is coming out of the binding posts
no, I sent it into the battery connector on the MagTag, using 3.7V
since the idea is to measure consumption with a battery
Sure, makes sense.
I'll see if I can dig up a JST I can use instead of trying to cram duponts or something in there
be careful not to leave it connected if you power via USB temporarily, since you'll be backpowering the Monsoon from the Feather battery charging circuitry
Hopefully there's a protection diode, but I didn't check that.
The MagTag has no charging circuit, so it's not an issue
But Saola has no charger, is that right?
What does that mean, no charging circuit? On the magtag?
Saola doesn't, at least that I'm aware of. Nothing marked Vbat or that looks like an MCP
The Feathers all have a LiPo battery charger on board that charges an attached battery if they are powered via USB. When there's no USB power then the charger is off.
The MagTag does not have that circuitry
That is a basic feature of Feathers
It doesn't? So it won't charge a Lipo when plugged in?
I don't think so, but I'll check
I'm just surprised because I'm pretty sure I've charged my project devices on a Magtag
oh, you're right!
I have a switched JST cable I was using between the Monsoon (or the PPK) and the battery connector
but I would hope both the PPK and Monsoon have protection
handy, did you make that yourself or do you happen to have a purchase link?
The switch is weird, it is on when the button is up
that was confusing
I would suggest ordering several other battery-ish cables at the same time, like 261 , 3814, etc. https://www.adafruit.com/?q=jst+ph+2-pin&sort=BestMatch
I put some Dupont style connectors on the ends of some
I don't know if it's a separate issue but copying a file onto CIRCUITPY while a looping sound sample is playing makes it crackle for a few second and then stop.
Restarting interpreter with control-D doesn't seem to allow recovery for this. The output just stays low.
for anyone wanting a one liner to convert image files to CP bitmaps:
convert foo.png +dither -colors N foo.bmp
seems to work nicely.
set N as low as possible to cover desired number of colors
neat! I've never seen this convert command. I made a python script that uses PIL that does something similar, but there are so many other nice options built into this
it's imagemagick I believe
yep. although i think i'm still getting slightly better results going through gimp.
Hi all, just started with the raspberry pi pico, i am trying to do a series of asyncronous data collects and was trying to use asyncio in its micropython version. However i have since found libraries for the sensors im using in the circuit python github. Is there asyncio in circuitpython.
@vague latch There is not. There may, however, be ways to do what you're trying to do without specifically using asyncio.
thank you for your response. Do you have any examples on how this may be done instead.
Or is it in the pipelines to port asyncio to circuitpython
I would need to first know what you're trying to do.
It's on our radar, but it's not a priority for the core devs at this time.
I have a gps, bme280 (pressure, humidity..) and a bno055(IMU) i want to collect the data from each of these at a different sampling rate and parse them to the SD card
i was thinking asyncio would allow me to do a OS like event handler
Ah ok. I might not be the best person to help you as my knowledge gets a little fuzzy in this area. I feel like you should be able to set each one up, and have a loop within a loop that uses something like time.monotonic() to poll at different rates... But I'm not certain.
It might do that, yeah.
ok, ill have a look into that
I am fairly certain it's possible to do what you're suggesting in CircuitPython. But I don't think I can make any helpful suggestions.
ok, can you mix micropython and circuitpython at all in these systems
No. They're not really compatible.
The code will always look really similar, but it won't work together.
thanks for your help. ill look into time.monotonic or ill port the adafruit libraries to micropython
You're welcome. Sorry I couldn't help more!
@vague latch we do have the async and await keywords in CircuitPython from this PR: https://github.com/adafruit/circuitpython/pull/3540 there is a library called tasko written by the person that made that contribution: https://github.com/WarriorOfWire/tasko I'm not certain but I think it's goal is to be similar to asyncio is for CPython.
that looks interesting. thankyou @lone axle
Thank you!
Another quick question. I searched for the better part of yesterday and couldn't find the answer and would suggest someone write a blog post on it if they are so inclined. I need to add libraries onto the circuitpython based raspberry pi. My mu editor isnt working properly so i began copying across the code using the file storage but would like a way where i can use pip to install the libraries straight onto the board. Further i would like to get someones github library and add it to the device like i would with python. ie pip3 install git+https://github.com/....
clarification raspberry pi pico
@vague latch check out circup if you haven't seen it yet: https://github.com/adafruit/circup It's a CLI tool for installing circuitpython libraries on your devices. If you have experience with pip then the workflow of this will likely be familiar.
That looks good. however i cant see an indication as to whether anything other then adafruit based libraries can be added, this will help with the other libraries that i was manually copying across. Im just thinking in regards to the tasko library is there a simple way to get this onto the board directly from git. I don't see any real way of doing. It is not a huge hassle to git clone then copy to lib folder.
@vague latch Community Bundle support is on the to do list https://github.com/adafruit/circup/issues/82
hmm i just had a thought, i can cd into the circuitpython location and git clone directly into the lib folder
that will likely fill up your filesystem
You can pip install to a folder... let me lookup how that is done
yeah, i could then remove the .git files and other stuff but it is slower
@slender iron what is the current best solution to put these libraries that are sourced from github onto the pico
generally we expect you to download the bundle zip and copy libraries over
as you need them
circup is replacing that over time though
yeah ok that sounds good
assuming the package is published (not all are)
pip install <PACKAGE_NAME> --target /Volumes/CIRCUITPY/lib
or your OS specific version of /Volumes/CIRCUITPY/lib
I'm on a Mac.
Yes, I think you're right. If you're making your own library, start with the cookiecutter for library projects
https://github.com/adafruit/cookiecutter-adafruit-circuitpython/
But honestly 99.9% of the libraries are a single .py file... you can download onesie twosies
Ultimately, circup will do the magic
yeah, i am looking at using this for multiple identical picos so was looking at automating some of the installation
but i definitely see that the majority of cases a single copy works
Do the .py files need to be at the top level of the lib folder or can they be in their own folders.
in /lib
I would set up one master "image" one and then copy from that to a PC and then from there to all of the others. instead of direct install each lib on each device.
folder under /lib are for modules (libraries with many files)
Thanks for your help all
I'm not really liking all the full path includes. I changed them to most;ly match how the IDF does its includes. I think this might make it easier for future IDF releases.
Why not? I like the full path because that makes them easier to find. I dislike having super long include directory lists and include filenames that look like they come from the same place but don't.
I found this very confusing as well. I would suggest the time might be right for having a philosophy (I'm shyin...
Since the datasheet cast some doubt on the strength of the "rosc_hw->randombit", I use the SHA256 hash function to create a high quality random seed from random values of uncertain entropy, as well as to generate a sequence of random values from that seed using SHA256 as a cryptographically-secure random number generator.

In practice, it produces over 100kB/s of random data whi...
circup is perfect. It installs dependencies as well. Can i recommend adding this into the getting started tutorial on adafruit if it is not already there
I just added that, glad you like it. ๐
anyway to recover when both CP and PC see filesystem as readonly?
that sounds like it's corrupted
could be. i've been going back and forth a lot. just hoping for something before i storage.erase
I would say try safe mode but you probably should erase anyway for safety
I'll take this recommendation into consideration. Circup is still in active development so I want to make sure it's ready for us to document when we do.
Is the boot file set to readonly?
there currently is no boot file
Hi, I found a little typo on the Trinket M0 page. At the bottom, it says MO instead of M0. I hope I did this pull request right, I'm new to the more collaborative features of GitHub ;)
I can confirm that if you create a simple setup.py file which i checked through forking tasko. You can then do pip install git+https://github.com/qwertimer1/tasko.git --target /media/<user>/CIRCUITPY/lib and the library is saved into the lib folder with setuptools install working without an issue
Also confirmed it works by running import tasko in the repl
stroage.erase fixed it
@tidal kiln I was surprised you ended up there, do you think it was from disconnecting from USB without ejecting or some other action?
unknown. could be. i'm working on a data logging app. so there's lots of back and forth.
need to set write access to allow PC to push code update
then change to allow code to write
rinse, repeat
you could ampy put it should still work
I have been using it for a couple of weeks not and it is a life saver!
I posted a question in the forum and they directed me here:
I just updated my UF2 file to 6.2.0 Beta 2 and tried the Internet Test from the Learn Guide
https://learn.adafruit.com/adafruit-metro-esp32-s2/circuitpython-internet-test
I get the out of sockets error running the Internet test:
`Fetching and parsing json from https://api.github.com/repos/adafruit/circuitpython
Traceback (most recent call last):
File "code.py", line 55, in <module>
File "adafruit_requests.py", line 598, in...
anyone know how to completely wipe the storage for the pico. I tried the bootsel and re add circuitpython but all my files are still there. I have an 'OSError: [Errno 5] Input/output error' occuring, I am hoping i havent brcked the pico
storage.erase_filesystem()
https://circuitpython.readthedocs.io/en/6.1.x/shared-bindings/storage/index.html#storage.erase_filesystem
Never mind. I got pointed the the latest version that has not been release yet, but is in the pipeline. It worked._
@joelburton please check this out. You should be able to download a uf2 with this feature enabled here: https://github.com/adafruit/circuitpython/suites/2064177672/artifacts/41696731 -- if you get a chance to test with it, let us know the result.
It looks like this isn't working at the moment. https://github.com/adafruit/circuitpython/issues/4066
what I/O error are you getting?
OSError: [Errno 5] Input/output error
i cant open the code.py file
it wont let me write to the circuitpython folder
The repl still works
hrm. I don't see a uf2 of nuke
(it's very weird to me that erase_filesystem doesn't work)
but it didn't work for me today either
can we add erase filesystem and not reload circuit python
ah I was gonna ask: would a "erase flash UF2" be hard to make ?
i was trying to find the library in the git repo but am still looking for it
not sure what you mean by this
https://circuitpython.readthedocs.io/en/6.1.x/shared-bindings/storage/index.html#storage.erase_filesystem says erase and recreate the CIRCUITPY filesystem
right
i was thinking you could just erase but not recreate the filesystem
that's what it actually does. it just rewrites the FS data structures
ok
it's the same code that's run the first time when a filesystem isn't found
so it's weird that it doesn't work
`import machine
import utime
C4 = 262
D4 = 294
E4 = 330
tone = [C4,D4,E4]
audio_left = machine.PWM(machine.Pin(18))
audio_right = machine.PWM(machine.Pin(19))
for i in tone:
audio_left.freq(i)
audio_right.freq(i)
audio_left.duty_u16(19660)
audio_right.duty_u16(19600) #30%
utime.sleep(0.15)
audio_left.duty_u16(0)
audio_right.duty_u16(0)
`
I can use change both GP18 and GP19 frequency in MicroPython. I can't do in in CircuitPython ?
import machine
import utime
C4 = 262
D4 = 294
E4 = 330
tone = [C4,D4,E4]
audio_left = machine.PWM(machine.Pin(18))
audio_right = machine.PWM(machine.Pin(19))
for i in tone:
audio_left.freq(i)
audio_right.freq(i)
audio_left.duty_u16(19660)
audio_right.duty_u16(19600) #30%
utime.sleep(0.15)
audio_left.duty_u16(0)
audio_right.duty_u16(0)
I can change both frequecy for GP18 and GP19 in MicroPython. I can't do it in CircuitPython ?
Hello guys i am working on a macro keyboard project on my pico and I cant figur eout how to get the Decouncer module.
i did download adafruit-circuitpython-debouncer-6.x-mpy-1.3.9.zip and palced the mpy file in the lib/adafruit_deboucner folder but i cant load the module.
Here is my script:
`# Imports
import time
import board
import usb_hid
import digitalio
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keycode import Keycode
from adafruit_debouncer import Debouncer
...
found the nuke uf2 https://www.raspberrypi.org/forums/viewtopic.php?t=300903&p=1806928
this works
Try placing the mpy in lib directly. You only sometimes need the folder.
(Specifically you need a folder when a library has multiple mpy files in it. The bundle will have the folder too if you need it.)
I'm gonna bookmark that nuke uf2
yeah, very useful
A follow-up with the current status :-
- SPI & I2C might have bugs.
- Currently I am focusing on getting things up and running which were stuck due to
idf@v4.2. - I suggest creating a new branch for the IDF update. That way it would be easier for folks to collaborate on the update work.
Yes. Good idea. I think my fixes to i2c from your branch have that working. No testing on SPI yet. Like you I expect bugs. But there's the fun. I'm currently looking (again) at i2c and wifi crashing. Wifi is not trivial. Lol.
Implements a second CDC channel on boards where it is possible.
- New module
usb_cdc.usb_cdc.serials[0]is the REPL channel;usb_cdc.serials[1]is the new secondary channel. Both are pre-created instances ofusb_cdc.Serial. usb_cdc.Serialis more strictly likepyserialthan the current stream implementation. New pyserial-compatibility flags added to enable this, for use withusb_cdc:read()defaults to reading one character.readinto()does not take a second...
from my experience, the ttyACM/COM numbering (0, 1) will swap around and could cause a bit of confusion :smiley:
this could be related to https://github.com/hathach/tinyusb/pull/655 , may be worth doing tinyusb update. rp2040 port is still early.
? Using Segger J-Link Edu Mini adapter to debug ESP32-S2 Saola 1R dev kit?
Kind folks, I have followed the instructions for setting up to build the CircuitPython binary for the ESP32-S2 Rover module on the Saola 1R dev kit, using my MacBook Pro "Big Sur". Great. Got a live REPL, etc., Thanks. Now I'd like to use my Segger J-Link Edu Mini to debug changes I want to make to the code. Has anyone succeeded in doing this? How? Using OpenOCD or J-Link Commander to control the adapter?
Note: This article describes how to do it for the J-Link "Edu" adapter, but says it doesn't work for the "mini" -- https://dzone.com/articles/eclipse-jtag-debugging-the-esp32-with-a-segger-j-l
@microDev1 and @skieast if you want to try ... I added you as contributors to my fork.
Scott suggested you could add my fork as a remote git remote add askpatrickw https://github.com/askpatrickw/circuitpython.git and then merge into my branch which is connected to this PR. At least I think so... ;-)
Whatever is easiest though.. I'm not concerned about it coming from my repo or this PR.
? esp-idf version in CircuitPython repo?
While I'm asking questions, I note that the Espressif esp-idf code repo is included in the CircuitPython source repo. I presume this is to ensure some version control on which release of esp-idf is used. Anything else I'm missing here? Why not just check out a fixed tag from the general esp-idf repo, e..g., "Release 4.2"?
Hi @glossy pecan the current IDF is based on slightly patched v4.2 release... this will soon be updated to v4.3 directly from espressif.
I added a check to determine if a write procedure is a rewrite... if it is than an erase and sector write is done else page write.
Also, be aware that the SDK checks may only be active during a debug build. So if it's "working" with OPT, it may still break with DEBUG=1. Dave found an issue with my code this way.
ya... my usual workflow is doing debug builds while in development and a test with non-debug when performing commit.
@microDev1 and @skieast if you want to try ... I added you as contributors to my fork.
Scott suggested you could add my fork as a remotegit remote add askpatrickw https://github.com/askpatrickw/circuitpython.gitand then merge into my branch which is connected to this PR. At least I think so... ;-)Whatever is easiest though.. I'm not concerned about it coming from my repo or this PR.
Always like to learn new things. I will look at merging my i2c changes. Will have t...
I am trying to find a good use of my MagTag and thought of making a news headline viewer. Are there any rss feed parsing libraries that will work with circuitpython? This is the only one that I found -> https://github.com/kurtmckee/feedparser
I'm trying to connect the raspberry pi PICO to the Raspberry Pi 4 and send data via Serial from the PICO to the Pi4.
Every example I see for Circuitpython uses either I2C or UART (i.e. using the pins on the board for Serial communication).
Is serial communication solely via USB possible? I want to only connect the Pico to the Pi4 with the USB cable and no other wires.
Yup! it is possible... take a look at #4215.
Yup! it is possible... take a look at #4215.
Awesome, good to hear. Unfortunately looks like it's pretty new? I'm a pretty basic user so much easier for me to follow a guide and adapt it to what I want to do...
Maybe there will eventually be some guides I can utilize! Thanks for the info.
Does anyone have a Fingerprint sensor ( not the R503)? It would be nice if someone could test this PR https://github.com/adafruit/Adafruit_CircuitPython_Fingerprint/pull/28 with a different sensor - I have tested it with the R503. The new example can run on a Raspberry Pi, not on an MCU.
When the PR is merged the documentation will be available here.
If you want to get a head start at this... you can grab a uf2 from the artifacts page.
The functionality is similar to busio.UART so most of the existing examples will work with some modification like :-
import time
import usb_cdc
# import busio
uart = usb_cdc.serials[1]
# u...
Yup! it is possible... take a look at #4215.
Awesome, good to hear. Unfortunately looks like it's pretty new? I'm a pretty basic user so much easier for me to follow a guide and adapt it to what I want to do...
Maybe there will eventually be some guides I can utilize! Thanks for the info.
Yes, it is pretty new (last night :slightly_smiling_face: ). I will be writing a guide soon.
I have a silly question. If I disable the REPL CDC, on my build , will the index of the other CDC change in usb_cdc.serials? It would be nice to be able to test my code with repl enabled first, and then disable it without having to change the code.
from my experience, the ttyACM/COM numbering (0, 1) will swap around and could cause a bit of confusion
This has not happened to me (yet!): I tested on Linux, WIndows, and MacOS, and they were always assigned in sequential order.
I did have a problem in which I left pyserial running on ttyACM1, and then restarted the board. Then ttyACM0 and ttyACM2 were assigned. Then Linux got completely messed up and stopped assigning any new tty's, and I had to reboot. I attribute this to L...
I have a silly question. If I disable the REPL CDC, on my build , will the index of the other CDC change in
usb_cdc.serials? It would be nice to be able to test my code with repl enabled first, and then disable it without having to change the code.
Do you mean you would set CIRCUITPY_REPL_USB = 0? (That's the new way of disabling CDC.) I'm not sure what would happen -- I don't think I considered that case. The indices are fixed, and len(cdc_usb.serials) is always 2 right now. It mi...
I don't know of any XML parsing examples. We have plenty of JSON examples. Could you get a feed in JSON?
also maybe re-ask in #help-with-circuitpython
this is more the dev channel (fine to ask here, but there are more user eyes in the other channel)
from my experience, the ttyACM/COM numbering (0, 1) will swap around and could cause a bit of confusion
This has not happened to me (yet!): I tested on Linux, WIndows, and MacOS, and they were always assigned in sequential order.
I did have a problem in which I left
pyserialrunning onttyACM1, and then restarted the board. ThenttyACM0andttyACM2were assigned. Then Linux got completely messed up and stopped assigning any newtty's, and I had to reboot. I attribu...
yeah, It will be good on testing, and then decide to confuse us when we want to do something more stable. Just kidding, in case of issue e.g with ACM0 it will come back as ACM2 then we have ACM1 & ACM2. It can stay like that, and thing can be confusing on our support for which ACM for REPL. But it is really minor to those who want dual CDCs. Just make sure we have some note to user :)
It would be nice to be able to identify the CDC channels by the string ID's:
$ lsusb -D /dev/bus/u...
@tulip sleet could it be a dict with meaningful keys, 'repl' and '???' to avoid the problem with numbers vs com port numbers?
it could be - right now it's just an index into the CDC descriptors, basically. I was using integer indices because I could imagine adding a third one, etc. The key could be the identifier included in the USB descriptor. Feel free to add a comment to the PR.
could be .serials with integers now, and add .serials_by_name now or later
so nice to see a number of these bars nearly full!
we just got possibly the first weblate contributions in Italian, nice!
Thanks for the reply. I already put my question in there as well. I'll check to see if there are any news feeds that provide json.
This is how MP does it:
Looks like MicroPython [does a bitbang write transaction](https://github.com/micropython/micropython/blob/d4b45898f58aae66c706ca5f832f11727daef46b/ports/rp2/machine_i2c.c#L124-L42) when the write is 2 bytes or less. (Interesting that it's 2 bytes, not 1 byte).
Do you mean you would set CIRCUITPY_REPL_USB = 0? (That's the new way of disabling CDC.) I'm not sure what would happen -- I don't think I considered that case. The indices are fixed, and len(cdc_usb.serials) is always 2 right now. It might not even compile. So you want a serial connection but no REPL, is that right? I could probably make that work, maybe after this PR.
Yes, that's what I meant.
Is that because this will not otherwise work on SAMD21? You could disable MIDI and regai...
@slender iron if time.monotonic_ns() doesn't seem to be advancing while executing a pio program, is that its own bug or is it https://github.com/adafruit/circuitpython/issues/4067 ?
.. but maybe monotonic_ns is? or maybe my test was wrong?
....................................................................................................
Neopixel show() 2.93066s, 34.122FPS, 32757.084370pixels/second
....................................................................................................
PioPixl8 show() 0.429688s, 232.727FPS, 223418.116570pixels/second
``` it seems to be working now, huh.
also speedup ahoy
Here is a related issue for getting allowed by Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1169000 (Will review later.)
@onyx hinge it should work because it's based on the single 64 bit timer I think
I was surprised at this:
>>> n = neopixel.NeoPixel(board.GP0, 1, auto_write=False)
>>> n.deinit()
>>> n.show()
>>>
Expected behavior: n.show() raises an exception since the related object has been deinitialized
Actual behavior: n.show() does not raise an exception
I only tested on Pico, so this may be a port-specific problem. However, I didn't label it as such initially.
@slender iron I am working on the short I2C write issue on RP2040 by using bitbangio. Just about to test.
thanks!
Is there a link to that graph? It would be a good link to tweet ...
@idle wharf good point -- I dunno if we've tweeted about weblate lately. There are share links right on the weblate page... dunno if it shows that image in particular though
Look like a good landing page
https://circuitpython.org/contributing/weblate
We want to speed up writing neopixels by nearly 8x on RP2040 by placing multiple strands in parallel and driving them with PIO. This needs a very specific bit rearrangement calculation which is too slow to do in Python but can be done very efficiently in C.
Testing performed: with work-in-progress adafruit_piopixl8 library, drove 2 to 8 strands of 30 real LEDs each; also stress tested the library by driving 25600 imaginary LEDs at a rate of about 240,000 pixels/second (theoretical ma...
Can we change the setup of sphinx so that it doesn't see "problems" like these when building in a clone which has been used to build an esp32s2 FW:
/home/jepler/src/circuitpython/ports/esp32s2/.idf_tools/tools/cmake/3.16.4/share/cmake-3.16/Help/command/file.rst:159: WARNING: Could not lex literal_block as "cmake". Highlighting skipped.
(and many others)
Possibly we could do this by having a whitelist of locations to use, instead of looking everywhere.
@tulip sleet I know pyserial can get this information on mac, is pyserial platform-independent enough ?
import serial.tools.list_ports
for port in serial.tools.list_ports.comports():
print(port.device,port.interface)
/dev/cu.Bluetooth-Incoming-Port None
/dev/cu.usbmodem7CDFA100E6201 CircuitPython CDC data
pyserial exposes the port's string ID like this. That's on Mac but I think pyserial might provide that across platforms ?
import serial.tools.list_ports
for port in serial.tools.list_ports.comports():
print(port.device,port.interface)
/dev/cu.Bluetooth-Incoming-Port None
/dev/cu.usbmodem7CDFA100E6201 CircuitPython CDC data
I've been using a tool so I never have to look up serial ports for my boards, though it's mac/linux only because I had to use platform specific tools to identify which drive matches which board/serial port. https://github.com/Neradoc/discotool
(I need to add differentiating between serial ports now)
I whish to make it multiplatform and hopefully the methods used could be used to identify boards in Mu or other similar environments more reliably
@slender iron ok, rathole commencing: bitbangio I2C not working well on RP2040, so that needs to be fixed first. Are there known time-keeping issues?
ya, it's something I stubbed out but didn't exhaustively do
generally sleeps appear to be right to me
I wanted to get WFI working but had to punt on it
so common_hal_mcu_delay_us() is probably not doing great: that's the basic timekeeping in bitbangio I2C.
i will do some testing and open issue(s) as appropriate
haven't gotten there yet ; that's next. Just was trying a couple of simple sensors to make sure it worked, after TCS34725 still did not work,
if you have some time to fix an issue this would be good to fix: https://github.com/adafruit/Adafruit_CircuitPython_BLE_BroadcastNet/pull/16
looks like it's worth fixing but I have a higher prio BLE bug to fix as well. I thought I could knock off this I2C thing but it's not a one-hour fix. I will save what I have and come back to it.
No, I have classic CLUEs. I think I saw a note about ESP32S2 CLUE's using both buttons to go into bootloader mode.
While trying to use bitbangio.I2C to fix #4204 and potentially #4082, I tried using bitbangio.I2C for short I2C writes. However, it wasn't working, and further trials showed bitbangio.I2C was just not working well.
Examples:
>>> import adafruit_tcs34725, board, busio, bitbangio, adafruit_lis3dh, sht31d
>>> i2c = bitbangio.I2C(board.GP1, board.GP0)
>>> l = adafruit_lis3dh.LIS3DH_I2C(i2c)
Traceback (most recent call last):
File "", line 1, in
File "adafruit_lis3dh...
Hello. What are the units for the frequency arg for rp2pio.StateMachine ?
I don't think this will work. You always need to erase before programming unless you know the contents are already all 1s. Otherwise the old 0s will remain even if you try to write a 1.
I was saying how it usually works. It sounds like the ESP doesn't manage pin sharing for these like other ports do. So, it's something to fix.
(If you are compiling yourself then I'd just hack it.) Most folks won't hit this.
I think these are an artifact of the CPU or interrupts being blocked so the audio isn't filled in time.
Try providing a bytearray > 1k in size to WaveFile. It'll use the bytearray to buffer then. The larger it is, the more resilient to scheduling the playback will be. https://circuitpython.readthedocs.io/en/latest/shared-bindings/audiocore/index.html#audiocore.WaveFile
I've been experimenting with code derived from the demo code on https://github.com/adafruit/Adafruit_CircuitPython_PIOASM - what duty_cycle and frequency square wave is that supposed to create?
I've found that a frequency of 16 is faster than 1 but 64 is slower than 1. If I print sm.frequency it does show correct number. Is 1 supposed to execute at 1Hz? The units aren't documented at the moment in https://github.com/adafruit/circuitpython/blob/ae262cde55669c354fa2422097581b4ac4af...
@tidal kiln Have you got ESP32S2 CLUE? https://www.youtube.com/watch?v=h_kmnOEpAYk&t=25m48s
We had a lot of time for making, hacking, and tronix this weekend. Fueled up with some tasty Chinese food, we tore apart a Mi Home-compatible BLE sensor and E-Ink clock, added 7-color ACeP E-Ink support to our Arduino library, tried out some SD-card-on-a-chip samples, and even started working on an ESP32-S2 WiFi CLUE board (our last CLUE was des...
@simple pulsar not yet. i'm using the current nRF52840 one.
@jepler : works great for me; thanks for your help here, everyone! <3
I can change both frequecy for GP18 and GP19 in MicroPython. I can't do it in CircuitPython ?
No. frequency is dictated by the TOP value and clock divider which are shared for the two channels output from a PWM slice. CircuitPython prevents you from changing these values from a single output because it could lead to unexpectedly changing the frequency of the other channel. MicroPython doesn't check this for you. Therefore, in CircuitPython you need to use pins with separate slices for ea...
What I did. May look at the problem later. Thanks.
I've only had a quick look but I think the PIO PC wrapping functionality introduces no delay so the example code
squarewave = """
.program squarewave
set pins 1 [1] ; Drive pin high and then delay for one cycle
set pins 0 ; Drive pin low
"""
would produce a 66.7% duty cycle rather than 50% which is probably what was intended. This was probably based on code that had an explicit jmp, cf https://github.com/raspberrypi/pico-examples/blob/master/pio/squarewave/...
Correct, that will be 2/3 duty cycle and the frequency will be the state machine frequency / 3 because the program is 3 cycles long.
The slowest it can run depends on the PIO divisor which is 16 bit int + 8 bit fractional. So whatever 125 mhz / (2 ** 16 + 255 / 256) is.
Oh, yes. I think our API for frequency is integer-only now so the slowest will be 1hz.
yup... that is what the check does... it ensures that the range being written has all 1s.
How would people feel about a new "port_" prefix for functions that are implemented in the common-hal layer and used elsewhere in Circuitpython (like main, shared-bindings, and supervisor) but are not represented in the python API?
I've been feeling like it'd be nice to group them - Alarm has a lot of them, Microcontroller/Pin has a few, RTC probably has candidates too.
I wouldn't do port_ because that implies to me that it's unique to a port
but maybe that's wrong. port_init and port_reset don't do that
I'm thinking stuff like alarm_enter_deep_sleep, reset_all_pins, and claim_pin, which have unique port level implementations, but don't have python equivalents
Maybe hal_? Since it's not the part that's "common" with python?
But I think the unique to a port part is what I'm going for? Maybe I'm misunderstanding you.
@ionic elk something like internal_hal, maybe? I think the point of common_hal is that the same functions are provided by all ports: they're common across ports. I think common_hal routines would not HAVE to be called in service of implementing a python api. There is the old mp_hal name too
@ionic elk is this the i2c issue you are tracking on the stm32? https://forums.adafruit.com/viewtopic.php?f=60&t=175632
It's broken though, 64Hz shouldn't be slower blinking (i'm using LED) than 1Hz and 1Hz does not look like 1Hz.
Why does this start with _? How about calling it bitops or bufferops? That way we can put other similar math here.
I'd require the output buffer. I generally don't like APIs that allocate themselves because people use it without realizing the impact of it.
Please document this independently of neopixels. It's likely useful in other cases.
@tulip sleet if we define common_hal as items that should be accessible across all ports, then that would apply to many of the contents of alarm, like alarm_enter_deep_sleep and alarm_woken_from_sleep. Would you be open to changing those to a common_hal prefix?
@slender iron yes, that issue should be resolved by my I2C PR.
back on the prefix thing, I originally brought it up because I was noticing a lot of alarm functions in main that weren't common-hal prefixed, and it reminded me of a similar issue I worked on last year with the pin claiming functions spread across displayio that didn't have a common prefix or API
@slender iron just merged it, I'd forgotten to check on the CI passing.
ok, great!
Thank you for this! Nothing major. Just a couple questions.
//| def readinto(self, buf: WriteableBuffer) -> int:
Doesn't usually return the count of bytes filled in?
Shouldn't we read as we can? That will allow len here to be greater than the USB buffer sizes.
Shouldn't we just return the bytes currently available instead of waiting for all of them?
@slender iron can can you create a new branch for idf update so folks can easily collaborate
is it not working to use patrick or bruce's?
patrick did some initial work but I had already gotten further in my branch... bruce is working on i2c off of my branch...
spi has a lot of changes in v4.3 which need to be tested... I am currently focusing on getting things running which were stuck due to idf@v4.2
https://github.com/adafruit/circuitpython/compare/main...microDev1:update-idf
Renamed to "bitops", improved documentation, made output required, made width= positional.
๐ for this feature.
Serial comms for remote Vision Mixer and Camera control
if one is using the pyportal in BLE mode, the pp lib can't really be used, correct? that seems sort of wifi specific.
Good catch, that's just a typo.
There are three cases:
timeout< 0 corresponds totimeout = Noneon the Python side. A timeout ofNonein pyserial waits indefinitely for the requested number of bytes. (But I should fix this so that we don't wait for more bytes than the buffer will ever hold - that's a bug.)timeout== 0 returns whatever bytes are available, and returns immediately.timeout> 0 waits for up totimeoutseconds to try to get all the bytes requested. If the timeout expires, then return wh...
(But I should fix this so that we don't wait for more bytes than the buffer will ever hold - that's a bug.)
And I should fill the passed buffer partially and then wait for more. Same for the timeout > 0 case.
@gilded cradle hey. you'd probably know. pyportal question ^^ got lost in scroll.
If I'm not waiting at all, then once I read what's in the buffer, the rest won't be available immediately, but will need to be inserted in to the TinyUSB buffer.
@tidal kiln, I believe that's correct. I haven't used bluetooth mode, but likely functionality just needs to be added and a firmware version check would need to be added.
thanks!
๐
I have a git fu question: I've made changes to a bunch of files but haven't committed anything yet. I think I need to break out some of those file changes into a separate branch so it can go in before the others. What's the best way to do this? I'm thinking maybe git stash push -p all the stuff I don't want, then make new branch with the unstaged material, commit it, return to the original, merge the branch I just, then pop the stash so I can keep working. Is there a better way?
alternatively there's git add -i, leaving the unstaged changes in the files
Does anyone have an example of PIO code for RP2040 doing PULL operations? I'm struggling to get this to work and write to the rp2pio.StateMachine seems to lock up the code - cntrl-c can't interrupt it.
I have a question about https://github.com/adafruit/actions-ci-circuitpython-libs
I see this being pulled in when the build action runs for libraries and circup. But when I. look through it, it looks like (and I might be wrong) that all this is now covered by the cookiecutter and github actions in general.
If that's true, can we remove it from the cookiecutter (and thus libraries)? It would speed up the builds a bit.
@slender iron if you have an idea what to call the module for driving the neopixels with shift register & pio, let me know -- I know you didn't dig the piopxl8 name for reasons...
.. I'll read back later, just remembered we didn't get to it on the stream (like that was gonna happen)
@onyx hinge shiftymate <โ name for your module LOL
Or pixelmate
Or shiftypixel
I just tried pull with pdm but need to debug it. write will wait for a tx stall currently
I also saw un-ctrl-c'able during PIO operations when I had bad code -- didn't debug it. It had to do with trying to shift in or out in the program when there wasn't an in/out buffer provided @simple pulsar @slender iron
the code's supposed to permit ctrl-c
I'd concentrate on debugging (by print statement if necessary) the two different places in the core that StateMachine write (and soon readinto and write_readinto) try to wait for keyboard interrupts
RUN_BACKGROUND_TASKS;
if (mp_hal_is_interrupted()) {...```
The pull instruction does work, generally speaking. I have one in this shift-register neopixel program https://gist.github.com/jepler/a6968d731f78cf0f72e99f7b08e09956#file-adafruit_piopixl8-py-L41
@onyx hinge I'm trying to track down a ulab issue. Are you still up?
^^ it is this: https://github.com/v923z/micropython-ulab/issues/328
It appears this is a ulab issue. ble_adafruit_feather_bluefruit_sense.py uses ulab to make some vector arithmetic easy. The vector is then copied to a BLE characteristic. There's a bug when that happens. The bug seems to have been introduced when ulab was updated, between 6.1.0-beta.1 and 6.1.0-beta.2. https://github.com/v923z/micropython-ulab/issues/328
@tulip sleet Pinging you because of an earlier msg of yours. Have you (or anyone you know) gotten Segger J-Link EDU Mini adapter working with ESP32 or ESP32-S2?
Hello and thank you for maintaining this awesome library! I am currently working on a project where extreme power-efficiency is important. I bought the nRF52840 to see if it was fit for my project, and as I've always been a fan of Micropython, I was excited to see that you support this chip. My question is: how far along is the nRF52840 port of the alarm library, is it even being worked on? I see that it currently only supports ESP32-S2, but I could not find anyone working on the port to nRF52840.
The nRF52840 currently goes in to soft sleep on timeouts, but so far there is no interpretation of sd_power_system_off() - is that correctly understood?
@tulip sleet no but I can take a look today if you like. (also have a guide to work on)
thanks - I pinged you before I looked more closely. It's really a question for Zoltan. I just got on and haven't seen if he's replied yet.
NeoPIO?
@wise wigeon there has been no work on alarms for nRF yet, though it's on our radar. It does appear that you get very reduced power consumption on time.sleep() and similar. Your last sentence is correct, we don't call sd_power_system_off)_ explicitly yet.
I haven't tried any J-Link with ESP32 yet. @onyx hinge might have gotten it working with either a regular J-Link or a Mini. It is not directly supported by the Segger software: it is only a conduit for commands from openocd or similar.
Tested by connecting a gps Breakout to TX0/RX0 on Pins GP12/13 and running the gps_echotest.py script. worked normally.
oh wow, this is awesome. let me try it too :)
@glossy pecan When I have needed to use a debugger with ESP32-S2 I've used the Kaluga development board which has a built-in debugger that works with openocd and is well documented by Espressif how to start & use the debugger. In principle the j-link hardware works but you still have to use (esp-idf's version of) openocd. I just updated this guide page https://learn.adafruit.com/adafruit-metro-esp32-s2/debugging-with-openocd because it gave the wrong "gdb" program name to use (it didn't call for the "esp32s2" version). When you run the wrong gdb, it can sort-of work sometimes, and I suspect that was related to my problems...
I had been meaning to go back and check whether I'd made that error so thanks for causing me to actually do thta
ok GPS tested, 9600 baud and works as expected. will try some RX/TX loopback tests
@tulip sleet I suggested a (partial) fix for the buffer bug, it should allow any 1D arrays to be converted to buffers but not 2D arrays.
@onyx hinge thanks. Since there is no ndarray_get_buffer() in the 2.x code, does it work completely differently?
tested all common baud rates from 1200 to 115200 with
import time
import board
import busio
uart = busio.UART(board.TX, board.RX, baudrate=115200, timeout=0.1)
char = 0
while True:
uart.write(bytearray([char]))
char = (char + 1) % 256
data = uart.read(1)
print(data) # this is a bytearray type
Hey @tulip sleet what do you use for your Linux dev environment? Iโm going to be setting up a nice little Linux dev server after I move ๐
Hi - are you asking about hw or sw? I use Ubuntu 20.04. I use the cinnamon desktop.
desktop is a personal choice. I like the thin taskbar on cinnamon. I'm not that fond of unity. Never really tried kde for any length of time
taskbar. i have two monitors
Makes sense. I was basically going to set up a server and use a cheaper mini desktop to virtualize on in my office
what kind of server?
I am just using an old Intel i5 4-core processor and 16gb, with ssd's. But i have a 6-core i7-9500t arriving in a day or two. Both of these are used Dell Optiplex desktops.
scott has a hefty zillion-core AMD, but i am not going to spend that much
the latest Dell was $420 from dellrefurbished.com
there is always a coupon, or just wait a week or two
Haha, yeah I might go AMD but Iโm also considering a r240 from Dell
They have one for $500 right now
do you have other uses for a server? do you need a home media server or something like that?
It will manage NAS storage and whatnot
Iโll be upgrading my Netgear readyNAS 2 bay NAS to a rack mounted NAS
i have been going for single used machines instead: tv computer, development desktop, another desktop for Windows testing, another leftover tiny one for Windows Insider Preview testing, etc. I was tired of managing VM's
For building CircuitPythonโthat is, repeatedly building one particular firmware.elfโhaving a zillion cores doesn't help that much.
(I use Debian & xfce but I don't necessarily recommend it)
@ladyada Did gps_simpletest work for you? It is not seeing a fix for me.... echotest works fine.....
this "new" machine I am getting is 6 cores 12 threads, tshould maybe be twice as fast.
it is micro-form-factor, but the speed penalty is only about 10%
i didnt test fix cause thats a 'sit it outdoors' thing and its really cold out :D
hopefully not related to UART -- trying to figure it out....
i used debian for a long time but I like the up-to-date-ness of ubuntu
Iโm also going to probably host a website or two. Iโm not sure yet. Itโs more to play around with, get better setting up and developing in Linux and creating an isolated development environment away from my regular computer
Iโm probably going to load a docker container on it to to manage my 3D printers
Plus circuitpython development will happen there
Throwing 16 threads at the build process only speeds it up by less than 4x...
make sure the remote desktop setup you proposes works well for remote USB. I am sticking to native so I can see USB problems for what they are, instead of being confused by VM USB issues
does the remote desktop sw you are using do remote usb?
Iโve not chosen Remote Desktop software yet, Iโve used VMware Horizon Client
But Iโm not sure if it supports native USB
so plugging/unplugging boards, using J-Link etc. might be problematic
Potentially
Maybe Iโll set up CI on the server that I can fetch on my desktop
Like a local git server or something
There may be an issue -- the gps.update is faiong in _read_sentence here:
def _read_sentence(self):
# Parse any NMEA sentence that is available.
# pylint: disable=len-as-condition
# This needs to be refactored when it can be tested.
# Only continue if we have at least 32 bytes in the input buffer
print(self.in_waiting)
if self.in_waiting < 32:
return None
self.in_waiting seems to be 1 all the time
There may be an issue -- the gps.update is faiong in _read_sentence here:
def _read_sentence(self):
# Parse any NMEA sentence that is available.
# pylint: disable=len-as-condition
# This needs to be refactored when it can be tested.
# Only continue if we have at least 32 bytes in the input buffer
print(self.in_waiting)
if self.in_waiting < 32:
return None
self.in_waiting seems to be 1 all the time
i haven't really had the need for that kind of thing. Usually I just push to github at least every day for backup reasons, and when I'm ready for a PR, I rely on GitHub to do the big CI. But if you are doing other dev tasks too, that could be handy.
It's a good idea to have some kind of backup plan for any data you're working with. Anything that backs up your user files will work to back up your working files & local (non-pushed) git changes. but pushing regularly to a remote system like github is also not a bad idea, because it means you have different independent kinds of back-ups.
Yeah, thatโs the thought
Iโm just mostly looking to brush up understanding and learn more stuff related to developing software and devops things.
Hi! I was directed here by @slender iron, as I'm in the process of adding definitions for Pimoroni RP2040 boards. I've got them written and compiling, and am looking to create a draft PR for review. The only issue is, as we already have a fork of Micropython, Github won't let us create fork of Circuitpython too. I could fork to my personal account, but that will become problematic when several of the team wish to contribute.
Scott mentioned something to me about "adding pimoroni/micropython as a remote to push to" but I'm a bit of a beginner when it comes to Git so have no clue what that actually means ๐ . Any help with this would be greatly appreciated
I think you should be able to add adafruit/circuitpython as a remote to your local pimoroni/micropython clone. Then do git fetch adafruit/circuitpython. You can then checkout adafruit/main, branch it, and create a PR. But you might see "detached head" warnings - I'm not sure.
@ebon ingot you can create a new branch from CircuitPython & MicroPython break-point (i.e. before Jan 1 2017) and then pull in the changes from adafruit/circuitpython...
For this, I would strongly recommend NOT using that environment as your sole/primary backup or storage plan. If you want to try stuff out, but you risk losing data, or want to reset
Thanks for the suggestions @tulip sleet & @analog bridge . No idea how to do either of them, so any guides you could point me too that would step me through the process would be welcome
@ebon ingot I think this is going to be painful for anyone else trying to do PR's to circuitpython in your organization. You might consider creating a new organization to hold a new fork. I know that's not great. You could segregate all circuitpython dev there (e.g. also CPy libraries), and then it begins to make more sense
I wish github handled this better
i will do a little research
git checkout -b branchname 0ae344841
git pull https://github.com/adafruit/circuitpython.git
@ebon ingot ๐ and you are good to go
Is the code based on nrf code? That has (had?) a flaw: https://github.com/adafruit/circuitpython/issues/3030
And that's to be applied to a clone of our micropython repo, yes?
I'd suggest doing another clone as the change is too big and switching branches would be cumbersome
git clone https://github.com/micropython/micropython.git circuitpython
Okay, thanks. I'll give that a try
@analog bridge so @ebon ingot and colleagues will need to repeat git checkout branchname; git pull https://github.com/adafruit/circuitpython.git in each new clone, right?
where branchname is circuitpython-dev or similar
whatever it was called the first time
(and that branch should be pushed at some point)
@ebon ingot Also be careful when you submit a PR that it's against adafruit/circuitpython and not micropython/micropython, which can be embarassing (I've done that by accident a couple of times).
ya... the gui will default to micropython
to do circuitpython work, why don't you suggest making the initial clone be of adafruit/circuitpython, @analog bridge ?
oh shooot I suggested the wrong repo here... I meant the clone of your forked micropython repo
I see.
this can also be done... I think this requires a remote change to the forked repo
Git accommodates a lot of different workflows; I typically start by cloning where I eventually will pull-request to, so that origin/main or origin/master refers to the place I want to start branches. I add my own fork with git remote add jepler .... Starting new work is git fetch origin; git checkout -b project-name origin/main (or origin/master). Pushing it (first time) is git push --set-upstream jepler HEAD and subsequently is git push. Creating a PR is visiting the intended repository and going through the steps manually to create a PR from my repo to the intended repo. Take that all for what it's worth.
the base problem is that they already forked micropython in their org, so they can't fork circuitpython also, maybe your workflow accomodates that. I always clone my own dhalbert/circuitpython, because it contains my un-PR'd branches, etc.
this is also a problem at the user level too and not just for org
is there potentially an issue with this not returning the correct value for bytes in the uart? https://github.com/adafruit/circuitpython/blob/b12ccefbe6afd2c8b1743ce7759880ef3b01e9ed/ports/raspberrypi/common-hal/busio/UART.c#L231
Just to confirm, which repo was this meant to be to. I saw your comment about having said the wrong one, so I took that to mean I should clone pimoroni/micropython instead of micropython/micropython?
yep... pimoroni/micropython it is
Hmm okay. Well it shouts at me when trying the checkout line
fatal: '0ae344841' is not a commit and a branch 'circuitpython-dev' cannot be created from it
hmm... let me give you an older commit.... how about a081b49d
That worked
Everything will have redundancy in terms of storage
Thanks! @ladyada and @jerryneedell for the extensive testing... ๐
is there potentially an issue with this not returning the correct value for bytes in the uart?
Seems like uart_is_writable can only return if data is available or not and not the actual number of bytes.
/*! \brief Determine whether data is waiting in the RX FIFO
* \ingroup hardware_uart
*
* \param uart UART instance. \ref uart0 or \ref uart1
* \return 0 if no data available, otherwise the number of by...
So when I come to push, what should I add on to the command? Git suggests ```git push --set-upstream origin circuitpython-dev
@tulip sleet would it become more difficult for us to merge from Micropython if Circuitpython became a non-fork repo?
yes... its like any other branch
Yes, that's the reason we haven't separated.
yeha we should be buffering the UART data internally
yeha we should be buffering the UART data internally
yup... that's what I was thinking for a workaround
An exclude list is better than nothing ...
Closes: #4220
After all that, it seems I cannot do the push because of some stupid permissions thing, despite having successfully created many branches for this repo before
fatal: unable to access 'https://github.com/pimoroni/micropython.git/': The requested URL returned error: 403
this is for the new clone?
Yes
you can make branch upstream and then modify it locally and force push
should we switch to #help-with-git as this is getting more git focused
Ah yes, good idea
@iakovos-t I'm not able to replicate this error using the latest master MiniMQTT branch. Could you try downloading from https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/releases directly?
Tested with Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; Adafruit MagTag with ESP32S2 and latest MiniMQTT.
@hierophect this is fixed with the new SSLSocket
Tested with Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; Adafruit MagTag with ESP32S2
@brentru Unfortunately the problem persists with the latest release downloaded directly from the link you provided.
Tested with Adafruit CircuitPython 6.2.0-beta.2 on 2021-02-11; FeatherS2 with ESP32S2 and latest MiniMQTT
Is there anything I can do to help troubleshoot further - seems device specific?
I'm not sure if it's device specific or not, just tried on my Metro ESP32-S2 and wasnt able to replicate either..
Could you attach a logger to MiniMQTT so I can see what's going on? The logging library is here: https://github.com/adafruit/Adafruit_CircuitPython_Logging
to do this - add these lines after the mqtt_client initialization in your code:
import adafruit_logging as logging
mqtt_client.enable_logger(logging,logging.DEBUG)
Then, please re-run your code and copy/p...
Connecting to Adafruit IO...
905.876: DEBUG - Attempting to establish MQTT connection...
Traceback (most recent call last):
File "code.py", line 81, in <module>
File "adafruit_minimqtt/adafruit_minimqtt.py", line 467, in connect
File "adafruit_minimqtt/adafruit_minimqtt.py", line 263, in _get_socket
TypeError: can't convert str to int
Code done running.
Error is consistent with both the adafruit example (as run in this instance) and my own code.
I found some success with multiple probes. See this comment for more information:
https://github.com/adafruit/tinyuf2/issues/74#issuecomment-782260238
I've looked into the nRF52 SDK, but I have not yet established a complete overview of working with the sleep bindings. If I were to initiate the work of connecting your alarm bindings to the SDK, how and where would you suggest that I begin?
@wise wigeon You'll need to reimplement ports/esp32/common-hal/alarm for nrf. I am not sure if TouchAlarm makes sense for nrf, so that might be omitted. Note the discussion of light sleep and deep sleep in the documentation and the Sleep Learn Guide. We initially thought that light sleep on the esp32-s2 would preserve enough state that we could use the ESP light sleep, but it turns out even its light sleep shuts down a lot of things.
The nrf52 chips have excellent power-down capabilities, and you may be able to keep more things on at a low power draw. It may not be necessary to switch to system OFF to achieve very low draw.
Fixed to read as much as possible, including multiple buffer loads, in the time allowed.
Let me know if I missed anything. This is a placeholder that will be updated later with release pictures and purchase links.
Thank you for the swift responses!I will begin running power consumption tests on monday, and as you mention, it might not even be necessary to invest time into optimizing more that it is.
As can be seen on https://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.1.pdf page 56, the difference between system OFF and ON is insignificant in most cases.
yes, I was surprised by that, but they've done an excellent job in power reduction.
Indeed! Thanks again ๐
and thank you for working on this!
I was doing 4 bytes which I believe means I'm not in the DMA code path
@tulip sleet quick couple of questions for you:
- is
common-hal/alarm/pin/__init__.can obsolete leftover? - it references
alarmio, is there a particular reason why we didn't go with that name? I kind of prefer it toalarm, since there's a lot of included IO with the pin interrupts and adjustments to other parts of the processor.
@wise wigeon I am currently implementing alarm for STM32 so I'd be able to help/provide reference for NRF once that's done.
- yes, that is junk; the routines there are not used elsewhere.
- I thought for a while about alarm vs alarmio, and liked alarm better, because some of its functionality is not io, like sleep alarms
Hi, images look great. However, could you please keep the features to those in the list on this page: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads
Also, was esp_sleep_pd_config not useful in narrowing the domains that ESP32S2 shuts down in light sleep? The docs make reference to it as a way to change the behavior of the RTC
i don't think we are going to change it now, since it's in stable releases. Originally it was sleepio, but I thought we might have alarms not realted to sleep later
esp_sleep_pd_config I think might be called one or two places. the ESP-IDF already calls it properly in several places to do the right thing depending on what's enabled
there is discussion with igrr about that in some of the PR's or issues
Ok, I didn't feel especially strongly about it, it's fine to have it in the same category as rtc and os and stuff.
primarily, light sleep turns off wifi, and that's not just pd_config.
Turning off wifi is a big issue?
it changes wifi state, it doesn't just suspend things
hmm. Is that irrecoverable?
That's not such a big deal, though, is it? As long as it's clear upfront. If you have a program that sleeps for 1 hour, your connections are probably borked anyway.
yeah, but light sleep otherwise doesn't save that much power, so you may as well just time.sleep()
Ah, yeah if it doesn't save anything that makes sense. I'm surprised it doesn't though, if it shuts all this stuff down.
@ionic elk It would be polite/efficient to close the connections if you know you're going to sleep for that long unless they are to a private resource.
I'm trying to figure out parallels to the STM32, since ST chips have three states, not two: Sleep, Stop and Standby. Standby is the closest to deep sleep, Sleep is the ideal version of Light Sleep (some savings with no state loss) and Stop is kinda in between
@simple pulsar I'm simply wondering if light sleep should actually handle a clean Wifi shutdown automatically, and warn users of that in the docs.
I'm just speculating though, it doesn't sound like it's priority since the light sleep doesn't save much anyway
we wanted the semantics of alarm.sleep_until_alarms() not to turn things off. It also resets the pins
my light-sleep measurements at the time (no longer in the guide), showed it drew about 1.5mA
so ... maybe losing the pin state was also a big lose
if you are going to lose all that, you may as well just deep sleep and restart
But right now light sleep doesn't actually do anything at all, right?
it just does WFI, it's like time.sleep()
on the nrf you can do a lot better
with a light sleep; you can preserve all the pin state and the RAM and still just draw microamps
the ESP32-S2 is just not a good model for light sleep that preserves state
The PWM PIO example is a good one to try and replicate to prove this code. The init vs exec looks problematic though: https://forums.adafruit.com/viewtopic.php?f=60&t=175662
Hi Melissa,
Sorry about that, I was wondering what was allowed for features but I hadn't seen that page. Thanks for the link.
I was also wondering about how strict "Feather-Compatible" is. It has an unusual board outline and doesn't support battery charging, but it's definitely intended to be used with the Feather ecosystem.
I also changed the copy to have a "Learn More" section since the board is not for sale yet.
@tulip sleet can I bounce a quick question off you regarding the nrf52840 board config? it looks like there are two conflicting BOARD_HAS_ definitions.
sure
Thanks. For feather-compatible, I usually go by "will it work with featherwings?
what's the difference between BOARD_HAS_32KHZ_XTAL and BOARD_HAS_CRYSTAL.
EX: I dead bugged an nrf module and found that adding a 32.768 khz crystal makes the _bleio module importable.
nrf likes to have both a 32kHz crystal and a something-MHz crystal (32, I think, but I'd have to look)
without one of those, you don't have accurate enough timing for BLE.
The CPB is unusual and has only one crystal, I think. Let me look.
yeah, it only has the 32MHz crystal. Most have both, for more accurate timekeeping, I think, when the CPU clock is off
Long ago I wanted to rename BOARD_HAS_CRYSTAL to something more specific for nrf, but didn't get around to it yet.
in CPB's mpconfigboard.h:
// Board does not have a 32kHz crystal. It does have a 32MHz crystal.
#define BOARD_HAS_32KHZ_XTAL (0)
?serverinfo
thank you @tulip sleet ! Ah, I thought (assumed) crystal referred to the 32khz. the watch now has BT! it's the last known bug! switch BOARD_HAS_CRYSTAL on and BOARD_HAS_32KHZ_XTAL off.
great! yes, it's confusing, I spent a while with schematics. The nrf modules often don't mention they have an internal crystal, so I was pretty confused for a while
would it be acceptable to propose a change from BOARD_HAS_CRYSTAL to BOARD_HAS_MAIN_CRYSTAL or BOARD_HAS_32MHZ_CRYSTAL in a pr?
I think that would be great! You can leave BOARD_HAS_CRYSTAL alone in ports/atmel-samd, but change all uses in ports/nrf. The original use for it was to store USB clock calibration data on atmel-samd. It is used only in those two ports.
gladly! i'm leaning towards MHZ over MAIN solely because it draws attention to the units, thoughts or input?
