#circuitpython-dev
1 messages Β· Page 349 of 1
lurking
lurking
lurking
just listening today
I guess "into-the-weed" cannot be in between "Hug" and "Report"?
lurking
Lurking
@old smelt mute please
Folks: meet the PyCorder! My take on a touchpad-based Sharp Memory Display gadget, in gorgeous @oshpark After Dark. More in the coming days, but feeling super stoked tonight because I finally got it up and running (and made a simple input task for circuitpyui; video in 2nd tweet)
191
Sorry!
np
Is there sound? I don't here a thing!
Yes there is
I do hear sound correctly.
Open Hardware Summit (Edition 11), Call for Proposals Link to Apply: https://forms.gle/RNXUfWaZBpohdq5Y6 Description: The Open Hardware Summit (OHS) invites talk proposals for the eleventh annual summit! This yearβs summit is virtual and will be held online on Friday 2021-04-09, 9:00 AM β 5:30 PM EDT. The Open Hardware Summit is for presenting, ...
april 9th
There is no EDT in February -- it's EST
from u/SouthPawEngineer on reddit
I think it still fails. Does not actively make changes as I understand it.
It runs pre-commit hooks which runs black
But when you change version of black... would you run black on all the past content to "fix" them, or make a PR for those change that someone can just accept.
pip3 install pre-commit to install
pip3 install --upgrade pre-commit to upgrade to latest
Or the first person to do a PR will be forced to do unrelated change to keep black happy? Or should you first PR to fix black, then do your PR?
Melissa's audio is wonky.
same problem as last week. seems like an audio capture rate issue
Right.
The big pass through all of the libraries that we worked on should take care of the black formatting for us. The next PR that comes in after this should not wind up with Black action failures from code that wasn't specific to their change. @thorny jay
@solar whale it's a new workflow step:
https://github.com/adafruit/Adafruit_CircuitPython_BME280/blob/c12af54685cad49ed84f4a64b6c5f5fa5d224fe8/.github/workflows/build.yml#L50
you can see the install further up in Pip install pylint, Sphinx, pre-commit
@gilded cradle It sounds exactly like in the meeting last week.
@onyx hinge, could you read my notes? I'm gonna reboot my computer.
(nothing special about BME280, just picked a random lib)
@tidal kiln Thanks -- good to know
Thanks, so you went across all of them, I did not notice.
There are still a select few in progress, but the vast majority are merged at this point.
@solar whale oh, and this:
https://github.com/adafruit/actions-ci-circuitpython-libs/blob/master/.pre-commit-config.yaml
is another piece of the puzzle
The plot thickens ...
yah. i ran into this last friday. and spent some time going down the rabbit hole. π
@lone axle you should add your streams to the newsletter to promote them
@idle owl my internet is down. Trying to get back online.
Will do. these first ones were a bit spur of the moment, but I'm thinking over what time slot will work best for me to be able to most likely to commit to it weekly.
@gilded cradle Alright. Thanks for letting me know.
you can promote the recordings of them too
@onyx hinge have you pushed the audio work upstream yet
What is he finding with the thermal camera?
just asking for CircuitPython DAC
"drafts" places in the house where cold air can enter
No, I'm good
British spelling: draught
Learning two words for the price of one!
I'm back online
Welcome back!
π
Who said that size does not matter?
a lot of back n forth between hardware and software for that touch bug
This is a game in @CircuitPython by @deshipu made for the PyGamer that run scaled x2 on the PyPortal (both from @adafruit).
PyPortal has no build in Joystick but it has AirLift #ESP32 and @ricardoquesada made the #Bluepad32 firmware to support wireless joystick like the WiiMote. https://t.co/XeWjgmu7Rg
@onyx hinge Incidentally, how many dimensions of ulab have you included in circuitpython?
@tulip sleet From the Feather M0 failing on Windows issue after updating the bootloader question from earlier... They gave me what's in their info_uf2.txt file: UF2 Bootloader 3.11.0 SFHWRO Model: Feather M0 Express Board-ID: SAMD21G18A-Feather-M0-Express-v0 Forgot to ask what version of Windows, so I just replied with that question.
@lapis hemlock 2, I think
@idle owl looks ok
@tulip sleet Ok.
@ionic elk do you have a PPK2 to measure power use?
@slender iron not yet, gotta pick it up
kk, I recommend it
@lone axle Do you want to update a guide with the pre-commit info?
@slender iron Follow up question about PID codes for you, are they legally doing ok? I remember seeing a Hackaday story that said the USB-IF was going after them
I haven't heard anything
didn't seem like they had a basis for it, but it worried me
I remember they kinda dropped off the map for a little bit and I was wondering if that was why
@idle owl I can do that, but I will have to get more familiar with pre-commit myself before I'd be in a position to do it. I haven't used it locally yet.
@lone axle Good excuse! π
It's already implemented in the PR I believe...
@lone axle I think it would go here. https://learn.adafruit.com/improve-your-code-with-pylint/black You can leave everything under "Black isn't always right", but the initial part of that page would change, and maybe the title (but never the URL!).
def _read_register(self, address):
with self.i2c_device as i2c:
time.sleep(_I2C_READ_DELAY)
i2c.write(address)
time.sleep(_I2C_READ_DELAY)
i2c.readinto(self.buffer)
time.sleep(_I2C_READ_DELAY)
return self.buffer
_I2C_READ_DELAY = 0.01
One button is a bit. So many button make many properties.
@idle owl okay yep I will work on a tweak for the first section to introduce pre-commit along with Black, and then getthe new steps for the "Installing" and "Using" sections nailed down.
struct.unpack_from()?
@lone axle Perfect. Please let me know when you've got something, we'll partner with Dan to verify content, and Anne to proof it.
You may want the x and y to match.
There is a difference between delay and not querying more than every x ms.
Here we use I2C direct.
If you want to read via Bluetooth, then you use Bluepad32.
I do booth...
The WiiMote.
Ballance are 2 bytes per sensor + extra data.
Maybe just review the PR and propose a way to modify that.
It does. Its used in PyBadger library I believe. (don't know about M0 though)
Should we keep the name Nunchuck if it does more than Nunchuck?
x = (self.buffer[5] & 0xC0) >> 6
x |= self.buffer[2] << 2
y = (self.buffer[5] & 0x30) >> 4
y |= self.buffer[3] << 2
z = (self.buffer[5] & 0x0C) >> 2
z |= self.buffer[4] << 2
We are missing the Guitare.
Maybe the DJHero.
Both are requested by @split ocean π
It is separate file.
@tulip sleet From that person ```Windows 10 Home. Just did a pretty lengthy update a few days ago, that tends to break things but I don't think it's the issue here. I have a few other boards, Trinket M0s and QtPys, and they are 100%.
Another issue that may or may not be relevant, I keep an unaltered copy of the original code.py script that came on the Feather, to steal snippets of it to try in my scripts. It no longer runs in the feather. I haven't had a chance to go through and see exactly what it's hanging up on.``` They're in the #microcontrollers channel on the Python Discord if you want to discuss it with them directly.
I asked if they also updated CircuitPython. Which would explain code.py failing.
Could, rather.
Also how to deal with "*_simpletest" with various example for various "sub-module".
@idle owl I will take a look
yeah... my approach is the same here
create three and then see if we can merge
Will a higher level library be able to accept any of those mesh without having to know what type it is?
Because they have the same API, they can accept object(?) of each type.
sure
there is already issue for zigbee
ESP-NOW is not mesh
its just receiver to transmitter communication
nice... that works... thanks for the inputs π
this can be done by differentiating using object types
or with wrapper
thanks
yep
@onyx hinge re: AnalogOut comments in meeting... are there AnalogOut additions needed for audio on esp32s2, or PWM like paragraph 4: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/dac.html, or...?
Thanks Everyone π
π
Thanks!
there were also cats π
Now I know where that beeping was coming from! I thought it was a truck outside in reverse, but only for a single occasional beep.... π
I am not strong enough in serious Python programming to know what is possible and the proper way to do it... but beeing able to not have to worry about the kind of Mesh it is would be great.
also because nRF will have both ble-mesh and zigbee-mesh
I am thinking something kinda like alarms api
Another update, the DS Peripheral was supported as of the Dec 7, 2020 release tagged 4.2
https://github.com/espressif/esp-idf/releases/tag/v4.2
Today the port is using https://github.com/adafruit/esp-idf/tree/ebe7784258d8c10e9cc334ccc00c3fd270746c8b which is Dec 11th... so should be good, but I didn't look too closely.
Just mentioning it because the DSP support is relatively new...
@tulip sleet They're satisfied for now, though I don't think I really helped with their original issue. They have some steps to try and they're going to ping me again if they run into anything else. I'll let you know if I need more help with it. Thanks.
maybe they could move over to this discord? there would be more eyes on it
That's also a possible option. I had considered that.
@lone axle This seems like it might be up your alley: https://forums.adafruit.com/viewtopic.php?f=60&t=174113
@crimson ferry I'm studying/reimplementing some sample code down in esp-idf's components/driver/test/dac_dma_test, since there's not an esp-idf API available.
From my internal notes:
To make their test, in tools/unit-test-app, run
idf.py -T driver flashcode lives at components/driver/test/dac_dma_test
One of the DAC outputs was weird (clipped?) on my Kaluga (in this test AND in circuitpython AnalogOut), while my Metro ESP32-S2 was fine with an AnalogOut test. I didn't test a 2nd Kaluga, but didn't find any reason in the schematic for this to be the case so it may be a damaged module.
that's about all I know, CP isn't building yet, let alone getting far enough to see if it "does anything". Cooperating with AnalogIn/Out and SPI(!) also needs to be written. DAC DMA somehow reuses the SPI3 peripheral's DMA function.
thanks, I was curious if we were missing functionality, or if it was more fixing or tuning for a purpose
yeah the esp-idf doesn't wrap that hardware functionality yet
@tulip sleet The Windows issue was a red herring. They figured out that if they press down on the USB connector while it's plugged in, it's ok 100% of the time. Multiple cables make no difference, so the connector is loose. They're debating on reflowing the connection or needing to replace the connector. And deciding whether it's worth the repair, or simply replace it. Anyway wanted to give you the final update. We can add "loose USB connector" to our lexicon of potential issues for future reference.
! I have had one person have an intermittent USB-C, but this kind of thing seems really rare
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/1TNTqjN_SQu8wvEgJO2zVFlPS5_vKXTF_gP7CUC9stUU/edit?usp=sharing
CircuitPython Weekly for January 25, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canβt make the meeting and would still like to participate,...
Can anyone tell me when the audio from the meetings usually is posted?
Hmm. The video is posted by EOD, day of meeting. I'm not certain how long it takes to propagate to podcast services. @gloomy shuttle
thank you!
Interesting to see the PPK2 in action. I was most interested in whether the data from it is good, there were some differences mentioned on the Nordic forum with previous verison.
BTW, what was the resolution to the mystery crash mentioned in that video?
@slender iron ^^
Ladyada also used it on this week's "Desk of Ladyada" to show how she was using it for identifying a power draw anomaly
https://youtu.be/c_0uDYDNDxA
It's another STEMMA sunday! This weekend we played around with making TikTok timelapses and built ISO1540 and SHT40 breakouts & tested them / wrote some driver code. We also went back to our ESP32S2 feather and did some low power testing to figure out why our LC709 was acting weird (it's actually just fine!) We also looked at some quad I2S mic A...
@onyx hinge I have a simplified version of the code, and I think I know how to explain it, but I'm uncertain. Had to redo all of these examples because of a complete refactor of the final example, and they all build on each other. Bleh. Better code, but still. Guide page needs to be redone. Anyway. Here's the code.
import board
import digitalio
pir = digitalio.DigitalInOut(board.D10)
pir.direction = digitalio.Direction.INPUT
while True:
if pir.value:
print("Motion detected!")
while pir.value:
pass
Ok, so when the value is first True, it prints, and then it waits though the rest of the signal before beginning the loop again?
Which has the same effect as the previous code?
That sounds accurate. I'd call these two while-loops "nested loops".
Oh right, that was mentioned, but I would have forgotten to include it.
Since a while loop runs over and over again as long as its condition is true (and there's no "break" statement encountered inside it!), while pir.value: pass is a way to say "wait until pir.value is False", right?
Should be, yes.
which seems a bit backwards but there you go ..
as always, a good goal
anything else about it you're looking for good words to explain?
When did the crash happen? I don't remember
I was going to say meaning of life, but lately I'm not even sure I want to touch that, @onyx hinge π
To treasure one another while we're still here.
Of course you had to come up with something legitimately sentimental. Well played. And well said.
I'm not so sappy in real life, only online.
I think I have the core of my #circuitpython-dev2021 published but you are the only one to know: https://gist.github.com/dglaude/54a13c7b04250328fff4f054e7d71c26 I may have to revisit a bit, maybe give credit to those behind the project that I show as going in the right direction for my dream project. Did not read the post from other yet, except what Scott did show on live streaming.
Circuit Python 2021: The year of the CircuitPython Retro Gaming Personal Computer - CircuitPython2021.md
Maybe that is not the proper format, but it is the one project I would like to exist (yeah, it look like feature request).
@slender iron This crash from about a week before Christmas: https://www.youtube.com/watch?v=aOWp1GwT7Fs&t=1h32m30s
Iβm sponsored by Adafruit to work on CircuitPython. Support them, and by extension me, by purchasing hardware from https://adafruit.com
Chat with me and lot of others on the Adafruit Discord at https://adafru.it/discord.
Deep Dive happens every week. Normally Fridays at 2pm Pacific but occasionally shifted to Thursday at 2pm. Typically goes for...
I don't remember π
coming back to me....
we weren't properly saving the alarm object from garbage collection
having the print causes the pointer to remain on the stack and get collected
I am listening back to the meeting from today as someone who has been hacking on the nunchuk library, I don't think the problem is completely understood. I think I had solved the speed read issue.
the i2c read was only delayed because in the library as it exists it reads the data for each property.
@gloomy shuttle yep. that's the basic issue. the question was more best python-y way to return all the parameters from the single read.
I am afraid the discussion was done without watching the PR you did this week-end. I tried to explain that in the chat but that did stay theoretical discussion.
I think my original PR solved both of the issues that Carter mentioned today. What it does is each property calls read_data and the read_data wont update the buffer if it had been updated recently. I introduced _I2C_BUFFER_UPDATE_DELAY for this reason. then the property parses out the sensor information accordingly.
For using the library for the tablet, I also want to make sure that X and Y are read at the same time, as I don't want the cursor to go to X from T1 and Y from T2. I need the X and the Y from the same I2C response from the hardware.
This is not a problem anymore.
Please @tidal kiln, have a look at the PR and if you have a better way or better API, document what you think would be best.
I think I would like to do the PR over again for clarity and remove the values function as I don't think it is concise. I think the property method was better for parsing the buffer.
This looks good! Please email it to circuitpython2021@adafruit.com when you are ready for me to post it on the blog
I'll add some more commentary over in the PR thread. Had to cycle around to some other things first today.
What is the deadline?
But before I do that, I think the bigger question is whether this should be a single community bundle or each accessory should be its own community library.
next monday
There is not a lot of shared code between the libraries. the only thing that is really shared is the read_register and read_data functions, but I do think there is some benefit to having them all in the same location like the WiiChuck library for Arduino is.
either way is fine with me
my only concern is that each peripheral has it's own file to import
That is in place already init and one file per type of device.
yes, that is how I have it setup right now.
β²οΈ π€ (sorry, I think I have to wake up early tomorrow)
good night!
good night!
@hathach In 5.3.1, we called tud_task() as one of the background tasks that runs on every timer tick, which was 1msec. The calling routine is usb_background().
That was changed in #2879 during 6.0 developoment. Now tud_task() is only set up to be called once each time the usb_irq_handler() is called:
https://github.com/adafruit/circuitpython/blob/409b5ff009811571adef9c519bcbb1f103340127/supervisor/shared/usb/usb.c#L97-L100
(It is not called in the interrupt handler, but it is put...
So i am following this guide on adafruit. https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/overview
which let me to this pull request. Pidcodes requires the open source software and hardware. I can't get my board added to circuitpython without the VID/PID so it's a catch 22.
You can open source the code in your own fork to satisfy the pid.codes requirement and then PR to CircuitPython after.
I suspect the specific issue here is that the internal touch circuitry wasn't actually connected to the outside world by the mux. This would cause the calibration to happen on the internal wires only. The short trace board is probably similar enough to work but not long wires.
I did confirm that this happens with the official 6.1.0-rc.1 .uf2 and not just my debug build. The default .uf2 includes the boot state of PowerOn or DSLEEP in the Debug UART output which I capture to a file. From a practical matter my program has run for about 24 hrs posting data to NodeRed without any noticeable lost of reading. It's hard to see if only 1 minute reading is missing in a 24 hr period. For now it's a good thing I really need the alarm.memory loop counter since is rarely goes 1...
I have a question about this "pin in use" thing. Due to this I am unable to reference an IO from both DigitalIO and AnalogIO right?
you can't at the same time
So if I wanted to have IO4 as an ADC input, pulled low I can't do it.
are you going to rely on the value of the pull down resistor?
As there is no Pull on AnalogIO and I can't do them at the same time.
what are you trying to do?
I'm curious to try, yes. I don't need exact.
I'm trying to remove a voltage divider on the Ambient light sensor which will always sink to GND and use the pull down on the IO instead, so I can set the pin to high impedance and have the Amb sensor suck no current.
it's not possible from circuitpython currently
what the value of the resistor is, is really no important, from board to board...
Ok, I didn't think so, bummer. Ok π
the Amb sensors sucks 30uA π¦
And that's with a 100k resistor - i can go higher, but then introduce more erratic results - and the ESP32's ADC's are already underwhelming as it is.
this is the first time I've heard of someone doing that π
Someone on my stream recommended it today... I have also never heard of it... π
The pull up/downs are "supposed to be" around 47k. I don't care if that is +/- 30% to be honest, so long as it's consistent on that pin on that specific chip.
right
Ok, well something for the wish list then π
yup, that's what issues are for
I found the 2 culprits on stream today that are keeping my FeatherS2 at 85uA in deep sleep (I'm totally find with 85uA as the FeatherS2 was never about best in class deep sleep) - but I was able to get it to 31uA
nice!
Not bad
I can move the AMB sensor to LDO2 so it takes no current in DS, but I lose the ability to wake the ESP32 with it - as I deliberately connected it to an RTGPIO
But I have no idea if that is even a useful thing for anyone
Re #2868 I don't mind at all modifying how we control when usb_background() or tud_task() are and I'm happy to help figure out what needs to be changed. It's not an understatement to say my changes were based on an insufficient understanding of tinyusb as well as just seeing "what worked"...
@slender iron so if I was to do a "new revision FeatherS2" with some changes on it, how would that usually be handled in CP ? Would I have to introduce another board?
it depends on what the changes are
Surely, Adafruit have had board revisions in the past pin changes or feature changes, and I don't see different boards for them.
they are usually identical from the software side
we do allow multiple flash chips for that reason
So lots of folks are asking me for a VBAT voltage divider. That would be another pin definition, but would only work on new revision boards.
if you are changing any pins around you'll want a new board
if you are using a currently free pin then you could probably just add it
but having it be clearly distinct will save you headache in the long run
Not changing pins, but adding new currently unused ones.
if they are unused you could then just add the pin defines
How would I make it distinct? any advice would be welcome!
clearly labeling it in silkscreen
but if someone uses that on an older board where the pin is not connected, they'll get weird/wrong results
yup! that's why it need so to be obvious they are using an old rev
adafruit boards include a revision letter on them
Right, ok. Gotchya!
I have my P number. P1, P2 etc
Ok, this is great info, thanks. I'm not 100% sure I'm going to add anything new yet.
But great to know I can without having to make a new board definition@
is there a P2 now?
P2 is current and P3 is coming... but no changes for the user on P2 (just some DFM changes for me) and P3 has fixed silk for IO14 (current has IO13 by mistake)
no functionality changes
cool, I have P0 and P1, I won't confuse myself by getting P2 right now π
actually I'll get whatever Adafruit ships me o_O
I have to say - on my stream today I was showing my FS2 and CP on the PPK2 - looking at the deep sleep stuff - it may have looked like I bagged CP a bit about power cost in boot/wake/start USB time etc...
in my ideal world circuitpython would be able to read what board version it is but that'd cost board $$$
I won't watch it then π
we know there is more room to optimize things
but I did state very clearly that CP on ESP32 is brand new, and deep sleep only just came in this version and there are stacks of optimisation opportunities still
I'm more interested in bringing deep sleep to more ports
exactly... I didn't want to sound like I was bagging CP - but I was aware at the time it might have come across that way.
So letting you know here in advance incase it comes out in the wash π
DS so far is excellent on the ESP32/CP - it's more about the 2.5 Seconds of boot time at "full power" before my CP code starts running
Maybe we need to queue up tud_task after we queue a response back into tinyusb. For example, maybe we need to trigger tud_task after a write completes.
and the PPK2 really showed that as a concern as it look longer for that to happen, then for my actual code to run and go back to sleep.
@atomic summit did you get to editing circuitpython code to partition the start up time?
that'd be the way to find the issues
Sorry, what do you mean?
editing the circuitpython c code
make a smaller partition for faster boot ?
Oh, no.. focus was on DS and FS2 debugging...
you could figure out how long it takes to enter CP main() for example
It was a hardware deep dive today... but I think it's due to the flash size. I think the bigger the flash, the longer it takes to boot.
The Q is.. when only running on battery, how do we detect that and stop the USB side from even starting up?
That would be the ultimate fix π
why do you think usb is the problem?
we do know the wake reason and try to skip normal startupy things when waking from deep sleep
(or at least we should)
we should only slow start on a power on reset
I can see on the PPK2 timeline when my LED turns on and kinda work back from there...
right, that makes sense
LED on is the first ting that happens after imports- and LED on is about 60% of the way into the graph
did you move it to before imports?
or after native-only imports
pulls up the stream
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.IO13)
led.switch_to_output(value=True)```
I could move time, & alarm after, but they should be smallish
ya, they are all native so I would expect it to be fast
right, so anything pre first user code import is out of the users hands...
yup, so we'd need to optimize it
and I know in MP for instance (no native USB) my TP gets to user space code in sub 1 second
with 4MB of flash
so I'm assuming the extra flash size and native USB is the overhead
right, so the question is "what is slow"
and you could add pin level setting in the circuitpython c code to find it
I'm not overly concerned right now.
Oh, turn on the LED in c? see where that happens?
right, I'd start by putting one at the top of main() so see how slow the bootrom and tinyuf2 are
Ok, I'll find some time to look into this! Thanks for the tips π
np. thanks for looking into it!
Out of curiosity, where/when do you stream @atomic summit ?
I have to finish these Display Shields off and I have a bunch of other stuff to do and talk about
#Soldering #PCBassembly #Chat [ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ]
If you'd like to support me on my journey, please consider buying one of my products on tindie
https://ww...
I have to finish these Display Shields off and I have a bunch of other stuff to do and talk about
#Soldering #PCBassembly #Chat [ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ]
If you'd like to support me on my journey, please consider buying one of my products on tindie
https://ww...
timecode for power stuff
Cool, thanks @slender iron! Always love seeing what others are doing and soak up what I can
3.5 hours today... that's about 1.5 hours too long... but lots of folks wanting to see the final solution to the DS probe
π
that's why I do timecodes in the stream now
here is an example of what we should be doing: https://github.com/adafruit/circuitpython/blob/main/main.c#L473-L477
when starting on power on we want to be cautious and delay
likely we need more of those π
or that one isn't working
common_hal_mcu_processor_get_reset_reason() == RESET_REASON_POWER_ON
yup, removed my comment, sorry
np
I looked backwards to see how skip_boot_output was set, not forwards, sorry!
π
Have we confirmed common_hal_mcu_processor_get_reset_reason() == RESET_REASON_POWER_ON actually works?
I guess I can light up my led in there.. to see if it fires
hahaha
so if (serial_connected() && serial_bytes_available()) { detects if USB is connected ?
ya, that should do usb
so supervisor_set_run_reason(RUN_REASON_STARTUP); wont alter the VM wake reason?
I'm open to not starting the usb peripheral when waking from deep sleep
If USB is connected it would be fake deep sleep right ?
there are multiple reasons. one is why the vm ran and one is why the mcu ran
right, with usb you'll pretend to deep sleep
@jfabernathy How are you powering the board? That is weird you are seeing a mix of poweron and dsleep reasons.
Another option would be to ask Espressif to get a VID and give PIDs for products with their chip. This is commonly done by other vendors. (USB-IF may not allow this anymore though.)
The board where I'm capturing the UART logs is powered by a Lipoly 2200mah battery. I recharge with a 12v barrel connector power supply. I wanted to eliminate the USB C being connected. You of course see non of this if you are connected to a Laptop because it only simulates deep sleep. Every time it starts up with DSLEEP indicated the counter is not reset. When it shows PowerON, the counter is reset. This is not unique to a particular board, I have the issue on both my ESP32 s2 Metros.
I don't know if all this is connected to the real problem I was chasing, but I found this issue with resetting my Alarm.memory counter when I was setting up diagnostic counters looking for why the system board would just stop running. No flashing LED or any indication of life except for the power LED. But I found this problem first.
CP is driving the APA all the time, so parasitic current is leaking form the APA and causing 1.4-1.6V to come out of the 3V3O pin when LDO2 is shutdown.
Is this a larger issue? We shouldn't communicate with the APA when LDO2 is off then right?
It's also confusing folks as the APA is now "doing it's own thing" all of the time now, not just when the user is in the REPL.
The APA should be blinking like it would on all CircuitPython boards. It was a bug before when it wasn't being co...
@maziarzamani The first thing to do is determine what the new API will be. The research phase of coming up with this is collecting links to other implementations and listing the uses we want to support. Once we have examples, I usually document the goal API and write non-working examples for it.
Bonus points for any existing Python zigbee APIs since we could choose to follow their API.
@dhalbert should these boards build now?
CP is driving the APA all the time, so parasitic current is leaking form the APA and causing 1.4-1.6V to come out of the 3V3O pin when LDO2 is shutdown.
Is this a larger issue? We shouldn't communicate with the APA when LDO2 is off then right?
Well, yes, I guess if it's considered a bug for the APA not to be behaving the same as other boards, then the way to solve this is for the code that does the LED thing to only do it if LDO2 )IO21) is high, but that's FeatherS2 specific...
@atomic summit when circuitpython resets pins it should disable all pulls and all buffers
we likely need to "deinit" pins for the rgb led though
@gilded cradle when you are working: https://forums.adafruit.com/viewtopic.php?f=60&t=174195
^-- they may be using MagTag lib before Dec 4 since they had 6.0.1
(that's when the voltage multiplier was changed from 2.6 to 3.3)
Zigbee is a licensed protocol, though it appears that it could be used for free without certification. I have not seen a really clear answer about this. We are currently using the nRF SoftDevice for BLE. There is SoftDevice support for Zigbee, but again, I don't know if there are licensing restrictions. I would assume Zephyr has its own Zigbee stack. Are there restrictions on its use?
@dhalbert thanks for detail explanation, most of the usb task job is queued by ISR, however, there is a few exceptions especially with MSC. E.g when scsi read/write callbback return 0 as busy indicator. The whole transfer is already complete, but since the application is not ready, tinyusb will need to re-schedule the event by itself without ISR (re-submit event to task queue).
https://github.com/hathach/tinyusb/blob/master/src/class/msc/msc_device.c#L366
It is probably our case here i...
@anecdata Here are some things I've tested tonight, letting then run for ~ 1 minute each.
Passed
- wifi.connect and ping in the While Loop. No issues. sleep of 5 seconds.
- wifi.connect outside the while loop. Ping inside the while loop. Sleep of 5 seconds
- wifi.conect, pool, and requests setup outside the while. Aio setup, aio.receive_time and ping inside the loop.
- wifi.conect, pool, and requests AIO setup outside the while. Aio.receive_time and ping inside the loop.
The fo...
For me, it doesn't really matter whether its nrf52 or any of the Silicon Labs IC's which are currently utilized by IKEA for their TrΓ₯dfri series. I am currently using both IC's for ZigBee applications, and at the end of the day I'd rather use SiLabs, but I am assuming no such porting really exists?
Did someone say TrΓ₯dfri? Wake me up if there is a way to integrate CircuitPython with TrΓ₯dfri... my house is slowly transforming to that technology.
Thanks very much for stress testing! The PR mainly addresses multiple sequential connects, whether wifi is started or stopped, and a little resilience with connecting and disconnecting repeatedly.
I do think the last case is separate, since socketpool init and requests init are inside the loop (I don't know about the AIO init, but it looks like that held up in yout 3rd test)), brentru or tannewt could perhaps comment better on that... I've always kept the setups outside the loop.
Maybe the easiest way to get around this is to use the XBee3 modules, which already supports MicroPython.
Did someone say TrΓ₯dfri? Wake me up if there is a way to integrate CircuitPython with TrΓ₯dfri... my house is slowly transforming to that technology.
Likewise, but I am not really looking to reverse engineer any "TRΓ DFRI protocol" here, but merely adding a new one which works with a different system (Conbee etc.).
Looks like Espressif already has a VID 0x303A, and they recently started giving out PIDs.
I can send them a pull request later today.
Certainly, a CircuitPython library could be written for an external module, and there would be no licensing issues. That is probably much less work than supporting Zigbee via the native SoftDevice implementation or a transplanted zephyr implementation.
@tulip sleet how should I disable a particular alarm for a port
we don't have that right now. For now you could just raise NotImplementedError. Which do you want to disable?
I could add some preprocessor flags later
actually I am working on mesh api... taking some tips from the alarm api
is it a top-level module?
if so there would be a CIRCUITPY_MESH, default 0
is this mesh or ESP-NOW? I forget.
mesh\
ble\
BLEMesh.c
wifi\
WiFiMesh.c
zigbee\
ZigBeeMesh.c
__init__.c
__init__.h
it is ESP-MESH
ya that would disable all
i am not sure it is worth making a hierarchy here. Do they share common code or API? E.g. ble_mesh, wifi_mesh, zigbee_mesh, etc. Do you expect there to be a Python helper library. _bleio might be the module: low-level impl whose API can change and is not guaranteed. We always use the adafruit_ble library on top of _bleio.
esp-mesh looks to be only wifi
thing about mesh is that the stack is capable of handling everything scan/connect/re-connect/self-heal... so supporting python library isn't needed
I am thinking of something like following :-
import mesh
wifi_mesh = mesh.wifi.WiFiMesh(...)
ble_mesh = mesh.ble.BLEMesh(...)
# common functions from here
mesh.start(wifi_mesh)
# or
mesh.start(ble_mesh)
also since you won't be doing two different mesh types simultaneously... there isn't a need for supplying that particular mesh object again and again in the subsequent calls
Looks like Espressif already has a VID
0x303A, and they recently started giving out PIDs.
I can send them a pull request later today.
Awesome! That's great news! Thanks for the link.
I also don't think we need a hierarchy. they can still share APIs without it
@slender iron since you are here... question for you.
Is it possible to get the WiFi object with ssid, bssid, passwd... parameters so I can pass it directly into mesh.wifi.WiFiMesh(wifi_object)
the wifi object doesn't have those items until you connect
does it make sense to connect before having a mesh?
ESP-MESH takes over the WiFi and LwIP stacks... the docs explicitly say that external calls will tamper mesh functioning... so no wifi simultaneously with esp-mesh
on power_on several devices broadcast with same mesh network parameters and start forming a network... they then choose a root node... the root is responsible for connection with WiFi...all of this is handled by ESP-MESH
right, I'm not sure it makes sense to make a wifi object to start
I am trying reduce the number of arguments being supplied to wifi_mesh object constructor... its already 6... with wifi parameters added it would surpass 10
also there is a possibility of conflicts with things like password... is it for mesh or for wifi
what if you want to use the same api later with other ways -- like the external modules and such?
external modules as in...?
I would think there will be API and semantic differences between the different meshes. They share a concept, but I don't think they reference a common detailed spec, do they?
as far as I have dug into zigbee... its safe to assume that they do have differences...
Thread (based on zigbee) on the other hand is common
@supple gale did you go down the vendor usb pid rabbit hole? https://github.com/pidcodes/pidcodes.github.com/pull/609
hmm... haven't given that a thought yet...
I also need to create a github issue for this
The STM32WB55 series runs the radio firmware on a second core. This lets it act like a discrete module integrated into the chip.
I was thinking I am making the function with most arguments in CPY but seems like displaio is way ahead in that regard.
Dumb core question, but can we add constants to a class in Circuitpython? Are there any classes that do that?
@BradChan please get a PID from espressif here https://github.com/espressif/usb-pids
@cotdp @gravitech-engineer please get a PID from espressif here https://github.com/espressif/usb-pids
I'm also fine with being told "don't do that". I do think as we get into power saving sleep it might be needed and raise the same issues, but I've not tried it yet. That is next on my todo list though.
I'll open a new issue for it and offer my approval based on the testing on the PR.
I'm offering my approval based on testing comments in the issue. Someone else should review the code.
@ionic elk Depends on what you mean by "constants". If you mean "something that can't be changed", it's (very) hard. If you just want a bunch of values you can refer to elsewhere, you can define them as class members. Usually they are all upper case to mark them as 'constant'.
class Foo:
BAR = 42
If those constants are integer values, you can write :
class Foo:
BAR = const(42)
This is a micropython extension, and the compiler will be able to optimise references to Foo.BAR in the module, making it as fast as if you used 42 directly.
Thank you, but I mean within the C implementation of a Circuitpython module, is it possible to create non-function attributes within a class (I said "constants" because the ssl module has a large section of these under that label https://docs.python.org/3/library/ssl.html?highlight=ssl#constants)
I don't recall any examples of this in a C-implemented Circuitpython module in the shared-bindings domain that I've seen, but they might just not be present in the modules I've worked on.
sorry for being vague.
my Python vocabulary still isn't super amazing, I've only really started on that this year
@ionic elk no problem π but I have no experience regarding the C implementation. However, I think something like MP_DEFINE_CONST_DICT could be used, like the one used in board.c to map pin names to pins. Don't know if it's usable for a class.
@slender iron I've just realised you mentioned a Joulescope (I thought you said dual scope!) in your YouTube video. Have you (or @tulip sleet or @atomic summit ) compared that to the data from the Nordic PPK2?
Looking good with espressif allocating pids. Will you be requesting pids from them for the various espressif dev boards currently using the Adafruit VID ? Iβm wondering if I should request pids for some ports I did or contact the board mfgr and ask them to do it.
I see ladyada is asking people to go get those PIDs. π
No, anything that already has a PID we can leave. We wouldn't want to reuse them anyway.
No, I haven't compared them. My plan is to move to the PPK2 simply because it's more accessible for folks
Any advice on fixing why this check is failing mpy-cross? I ran mpy-cross locally and it compiled. https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k/pull/30/checks
@prime cove it's using an old mpy-cross that doesn't have the f-string support
Thank you! So are f-strings typically avoided for this reason?
I suppose. you are the first person to hit this that I know of
@mild fog we now rebuild and upload mpy-cross on every PR: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/
@tulip sleet it's the library CI
ah
Are f-strings on all CircuitPython builds?
@simple pulsar only "FULL_BUILD" boards, so not the smallest ones
Yes I see it mentioned in https://github.com/adafruit/circuitpython/releases/tag/5.1.0 - I tried f-strings out on something last week and found it missing.
5.1.0
This is CircuitPython 5.1.0, the latest minor revision of CircuitPython and the first 5.1.x stable release. It is identical to 5.1.0-rc.0.
Download from circuitpython.org
Downloads are avail...
@tulip sleet do you have a plan for making 6.1 stable?
I wonder if an mpy with an f-string works in a build without f-string
I suspect it does because I think it's a transformation to string.format()
This looks good to me too but I think we should hold this to after 6.1.0. @dhalbert can approve and merge after.
I'm also fine with being told "don't do that".
We should have CircuitPython tell you not to do that. We should track if the radio already has a pool and raise an exception on the second init. We'll need to add a deinit to SocketPool too just in case you want to deinit and recreate. This matches how most of our APIs hold exclusive access to things.
I'd rather use SiLabs, but I am assuming no such porting really exists?
I've looked at their line up of chips but haven't found ones that provide something unique to CP. We can support anything with 32k RAM and native USB but there is a non-trivial amount of work to support new peripherals.
I am sort of considering pivoting to the XBee3 which already runs MicroPython out of the box and can be bought as dev boards or modules. All the (nasty) low-level ZigBee code abstraction is already dealt with. At this point I do not see the hassle in trying to reinvent the wheel on nrf52.
The question then is, should LDO2 being forced as output/high on boot? I don't like that as that means the LDO is turned on without the user doing it, rather than by the users hand. If it's not forced on, then the LED won't do the "CP" thing, and would then still be considered a bug.
I need to think more about this. I expect more boards in the future to do similar. I like that CircuitPython could manage when the board is on automatically but understand the 1mA of neopixel power (or whate...
Will tud_task_event_ready() return true after tud_task returns in this case? We could schedule another call if that's the case.
Do you still have the issue when the 12v connector is connected? This sounds like it might be an issue with the reset reason.
This looks good to me! Thank you! I'm holding the approval so this is merged in for 6.2 rather than 6.1. @dhalbert can merge post-6.1
This looks good to me! Thank you! I'm holding the approval so this is merged in for 6.2 rather than 6.1. @dhalbert can merge post-6.1
Sounds good. I have the TLS server separation PR ready to go as soon as this gets merged, so we could potentially get both of them into the same release.
It makes total sense for Espressif to offer PIDs for smaller companies making products using their USB enabled MCUs. Just like Microchip, Silabs and other vendors do.
This is going to make it much easier for smaller companies like me that might only make a small range of USB enabled products over a few years, so I'm glad Espressif have done this.
I usually plug in the 12V connector while the board is in deep sleep. It has no effect on what I see. I've also used a USB power adapter and that also works correctly. I've tried to trap all the exceptions. Early on I'd find the board flashing a bunch of LEDs and not running. I had to assume it had broken to REPL. Once I finally found a good way to trap everything it would run for as much as 3 days before it would stop. No LEDs except power. I was hoping to trap that error with all the ...
@slender iron I noticed you allocate a unique PID for CP, Bootloader and for Arduino. Any reason why they all can't use the same PID? It's not like a single board can be used in Arduino and with CP at the same time.
Will
tud_task_event_ready()returntrueaftertud_taskreturns in this case? We could schedule another call if that's the case.
I think I can test to see if that is true.
Hardware: Trinket M0
Bootloader: 3.10.0
CircuitPython: 6.0.1
I'm having trouble using PWM on Trinket M0.
Examples point me towards a library called pulsio, but I cannot find it anywhere, including the CircuitPython 6 library bundle.
pulseio is a built-in (C) module, but is not available on SAMD21 boards that don't have external flash chips ("Express" boards), for space reasons.
You could make a custom build, at the expense of removing some other things that you might not need. Or just switch to a more capable Express board.
Not at the same time, but the host may want to behave differently depending on what is running on the board.
ok, but why can't they still share the same PID? So long as the PID is unique to that board in both environments?
I'm obviously going to grab some PIDs from Espressif for some upcoming boards and I'm trying to work out if I really need to ask for 2 (or 3) per board to cover CP and Arduino.
Let's wait for Scott, but I believe he discussed the topic in one of the Deep Dive video.
I think they can, if you want to.
I mean, PewPew uses the same PID
because I only had one
@stuck elbow Yeah I know it can be the same, that's why I'm curious about why Adafruit assigning multiple. @thorny jay I remember Scott talking about ti on one of his streams, but can't remember which one π
@atomic summit hosts may cache the usb descriptor based on pid and get confused when it changes
@slender iron you see! A really good reason π Thanks!
It is probably our case here if we do
return 0in write callback. If so you only need to make sure to set the isr flag to run background when returning 0 or run background when flash is ready again (once 0 is returned).
Our tud_msc_write10_cb() is synchronous, and never returns 0, so unfortunately that is not an opportunity to reschedule.
This looks very much like I expect. No testing performed.
The lone build failure was an occasional CI weirdness.
@tulip sleet @slender iron ^^ will merging this disrupt any release-making plans?
let's wait to be safe
OK, I like safe
I wrote it and I agree! Joking aside I have a limited amount of devices to test it on so if you're close to a release candidate best to wait to the new more experimental release
I cannot for the life of me figure out how to turn LWIP_DEBUG on. Does anyone know how to do that? I've tried putting it in CFLAGS, adding a header file for options, and it still won't message what's going on.
@slender iron any chance you ran into that, when you were doing socket stuff?
or maybe the IDF doesn't actually override how it prints. hmm.
>>> import microcontroller
>>> microcontroller.nvm[0]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: NVS Error
``` what's this mean and how do I fix it?
@ionic elk any esp-idf debug stuff goes to the hardware UART pins. Setting CFLAGS in "our" Makefile probably doesn't set them during the esp-idf build. I thought maybe LWIP_DEBUG would be a setting in make menuconfig but I don't see it ..
@analog bridge ^^ maybe you know about my NVS error ?
I'm reading about 144976 bytes of free memory on an nrf52840 after boot/ after the vm loads. does it really take 105k of ram?
@lone axle have you seen this https://github.com/sidoh/epaper_templates
I have not but that is slick! I briefly consider feeding my layout system with JSON from a live server, but they put it together far nicer than I could have imagined.
The live preview in the web, and single property editors are really nice.
yeah, i saw it mentioned on an issue somewhere and want it for magtag all of a sudden!
esp32s2: seems to be only the first time```
import microcontroller
microcontroller.nvm[0]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: NVS Error
len(microcontroller.nvm)
20480
microcontroller.nvm[0] = 5
microcontroller.nvm[0]
5
I guess I never tried to read w/o writing first before
I can reproduce a problem by running this in the REPL on a Kaluga:
>>> b = b'\1\1\1\0\0\0' * 240
>>> d = digitalio.DigitalInOut(board.IO18)
>>> while True: neopixel_write.neopixel_write(d, b)
...
AND continuously writing to the CIRCUITPY drive from Linux:
pi@raspberrypi:~/media/CIRCUITPY $ while sync; do touch boot_out.txt ; done
Here's a "good" neopixel trace from saleae:
 calls when using the update() method. What are your thoughts? https://github.com/jfurcean/CircuitPython_WiiChuck
interesting. i tried this and it didn't work.
https://github.com/jfurcean/CircuitPython_WiiChuck/blob/79043ca7a0e352ca666ea617da5067f7891bdfa1/wiichuck/nunchuk.py#L56-L59
those sleeps came from the arduino libs and other info
what board are you using as a host?
@crimson ferry ah that's good to know. I'll file an issue with your info
I noticed and @anecdata confirmed that if the first operation on nvm is a read, you'll get an "NVS error":
>>> import microcontroller
>>> microcontroller.nvm[0]
Traceback (most recent call last):
File "", line 1, in
RuntimeError: NVS Error
>>> len(microcontroller.nvm)
20480
>>> microcontroller.nvm[0] = 5
>>> microcontroller.nvm[0]
5
The QT PY
I had removed them at some other point and ran into issues but that was without the update() function approach.
yah. that does seem to work on qt py. let me play with that some more. i feel like there was some reason those delays had to stay in there. it would be great if they could go away.
I just tested it on the featherS2 as well and it works.
@gloomy shuttle it'll have to wait until tomorrow before i can test things. but if we can do the i2c read without those delays, we may not even need a fancy approach for speeding things up. dumping them is an instant 20ms savings.
I think you may start getting bad data if you try to call the read_register too quickly in a single loop of a code.py.
yah. i just did quick test like that and it seemed to work.
but i thought i tried that when i first wrote that library
i based the library on existing arduino ones, which had those in there
they were an obvious "why are these here?" aspect that i was never really happy about, but figured it was some nunchuk unique requirement
I still think you may want to avoid calling the read_data more than once in a single loop. It takes about .016 seconds per read.
Automated website update for release 6.1.0 by Blinka.
New languages:
- nl
- sv
- fr
- fil
- it_IT
- el
- cs
- en_US
- en_x_pirate
- ko
- ja
- de_DE
- hi
- pl
- pt_BR
- ID
- es
- zh_Latn_pinyin
This is the expected behavior on esp32s2 port... the flash needs to be written before reading it.
The NVM implementation here doesn't directly interact with the flash instead it is built on top of NVS library.
The ByteArray functionality is emulated. NVS uses key-value pairs... in our case :-
microcontroller.nvm[a] = b
# a is the key
# b is the value
If a key isn't found... we throw an error RuntimeError: NVS Error. This however can be avoided by instead returning 0.
I think this can be done in menuconfig...
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/kconfig.html#component-config-lwip
anyone awake?
π€
not sure you have the approvals for: https://github.com/adafruit/circuitpython-org/pull/622
maybe @gilded cradle is?
Today, weβre launching our first microcontroller-class product: Raspberry Pi Pico. Priced at just $4, it is built on RP2040, a brand-new chip developed right here at Raspberry Pi. Whether youβre looking for a standalone board for deep-embedded development or a companion to your Raspberry Pi computer, or youβre taking your first steps with a micr...
interesting...
The RP2040 is new microcontroller from Raspberry Pi that features
two Cortex M0s and eight PIO state machines that are good for
crunching lots of data. It has 264k RAM and a built in UF2
bootloader too.
Datasheet: https://pico.raspberrypi.org/files/rp2040_datasheet.pdf
Please define full computer... is the C64 a full computer? is the Maximite Color 2 a full computer?
Like my router?
I don't have time to debate this
Anyway, I came here to say that this Pi existed, but before I wanted to secure one (two). Was Adafruit in the secret, did you have a chance to get some sample to investigate this and think about CP on it? Also I planned not to order anything this year but use all the hardware I already have... and that is broken.
@thorny jay I've been working on it for the last month π
and already made a pull request
Perfect. I love it. I guess the most important think will be some Feather adaptor or Pi pin adaptor (I guess this is 3V and that 5V thing will be annoying like for the micro:bit adapter). Maybe it is the night and I should let you sleep (and start to work).
Make a lot more sense than another set of messy adapter and yet another pinout to deal with.
Congrats on the new port @slender iron !
I'm excited to look over the specs of the Pico. Will it become a source of jealously with my ESP32-S2 collection? We'll see... π
Thanks! It's been fun. Really interesting chip with really good docs
no wifi so the S2 is safe for now π
I think limor already tested with an airlift
And so Friday you will stream on the topic, right?
And this is why you were less active in the open?
@thorny jay yes and yes
@slender iron Awesome work. Really looking forward to get the feather board.
https://hackaday.com/2021/01/20/raspberry-pi-enters-microcontroller-game-with-4-pico/
Also Hackaday has some more info on the chip.
Will be interesting to see how PIO can be abstracted for use in CP.
@subtle sun https://github.com/tannewt/circuitpython/blob/rp2040/ports/raspberrypi/bindings/rp2pio/StateMachine.c#L45
@slender iron This is so elegant. Probably the best abstraction i have seen in Python for a microcontoller.
Now to find where to order the board from.
Will try to catch one before they all sell out.
Looking forward to the future Deep Dive on state machines
friday π
I have a feeling tomorrow will be me saying "try circuitpython!"
though who knows when folks will get them in hand
ok, bedtime for me
@analog bridge sorry if my question is asked incorrectly - am I reading correctly that there are firm plans for CP to support espressif's mesh tech - i've been fighting through using it in C and my C skills are about 30 years out of date... Thanks for your time!
HI @broken coyote Yes, I am working on a new MESH module for it... though its still at an early stage.
I opened that issue separately over here in requests. It had nothing to do with AIO.
https://github.com/adafruit/Adafruit_CircuitPython_Requests/issues/62
When Dan chooses to merge this can close
@analog bridge that's awesome! i'm co-founder in a healthech startup where i'm using all espressif and a combination of MP and CP with a goal of being all CP as soon as the CP MQTT libs are done. we want to add the RGB lightbulb that espressif ship as a mesh devkit but if the only way I can interact with it is by us having to run their C stack on some kit it will be a killer. Again, forgive my Aspie lack of interpersonal skills - is there some way I can help or at least keep up with what you/others are doing on this?
i apologise if this is the wrong forum / wrong way to ask
nice to know that... would love to hear your suggestions regarding the new api... I am making a couple github issues now so that its easier to follow along the development
its always great to have people testing a new api and approaching it with different use cases π
ESP-MESH is a networking protocol built atop the Wi-Fi protocol.
It allows numerous devices (nodes) to be interconnected under a single WLAN (Wireless Local-Area Network).
ESP-MESH API docs are here.
Some traits of ESP-MESH include:
- Can spread over a large physical area (both indoors and outdoors)....
Discussions regarding a common or a similar api for different kinds of mesh networking infrastructures can be done here.
The goal here is achieve an api which can be inter-portable and can be used seamlessly irrespective of the underlying networking infrastructures.
The MESH networking infrastructures include :-
- BLEMesh
- WiFiMesh
- ZigBeeMesh
How about a new MESH module for this... the top-level stuff can also be shared with Zigbee (#4007).
I got confused between ESP-NOW and ESP-MESH here.
ESP-NOW seems to be more of a point-to-point receiver-to-transmitter communication rather than a mesh network.
@analog bridge this is awesome, thank you so much! should I DM you with thoughts - i'm sorry but i'm old and don't know the correct etiquetteπ
FWIW, i'm using their esp-mdf C stack right now doing some PoC for my healthech startup - utilising their meshkit-sense, meshkit-light and soon meshkit-button. Their reference code for the button actually uses both esp-mesh and esp-now modes. Don't know if that is useful to you guys at all.
if its related to CPY
then this channel is a better place since others can step in and provide info or gain from the discussion
@analog bridge a simple question for now then - are you aware of anyone using any sort of python to talk to espressif meshkit devices?
I haven't found anything related to that... it would be interesting to see how mesh would handle cross-platform.
that's exactly my hope - the lightbulb espressif make is cheap and really well done - but it is a self contained unit as you'd expect (running on mains power directly). ergo, no serial cable to debug and hence no easy way for me to use something other than their firmware on it. my desire is to use those bulbs as shipped, but interact with them entirely within the CP and 'stock' esp32 boards
i have no experience using C with python or i'd be happy to do the work 'on my dime' and then contribute it back
Their reference code for the button actually uses both esp-mesh and esp-now modes.
Interesting... ESP-NOW is more lightweight than ESP-MESH so one can assume it would work better when it comes to sensor or button nodes which are not always active and require power consumption to be minimal.
@analog bridge exactly as you state above, the button pcb reference design is meant to be run with battery. the PITA however for developers, which they seem to have missed, is that if you use that image with a usb connection (so you can have a serial console) it thinks you are exclusively in setup mode and prevents you trying to test the buttons. you end up in a catch 22 - which is what led me here - how can i stop using my 30 year old C skills and get even rudimentary access to their mesh network - just to turn the darn light on and off...
CircuitPython version: 6.1.0-rc.1-51-gfb1e0106b
dir(board) yield the output of:
['class', 'A0', 'A1', 'A2', 'GP0', 'GP1', 'GP10', 'GP11', 'GP12', 'GP13', 'GP14', 'GP16', 'GP17', 'GP18', 'GP19', 'GP2', 'GP20', 'GP21', 'GP22', 'GP25', 'GP26', 'GP26_A0', 'GP27', 'GP27_A1', 'GP28', 'GP28_A2', 'GP3', 'GP4', 'GP5', 'GP6', 'GP7', 'GP8', 'GP9', 'LED']
There are missing GP15 in the list.
Talking about the RP2040 maybe CP is missing the "Adafruit ItsyBitsy RP2040" board and I have also seen the "Tiny 2040" that I did not find yet in the list of board. π
this one?
I really want to get my hands on some Pi Silicon
But you probably have to be a distributor to get it
I think it will become generally available soon
it wouldn't make sense if you couldn't switch from a dev board to a standalone project
Yeah, true. Iβm just looking forward to making a board for ODT.
In an effort to product a test version of this program that still shows the bug but can be run without my server, I created a new code.py that is a combination of a simple http aio example and my code. I included the alarm.memory counter that gets reset randomly and my UART program output and Debug UART output. On a Raspberry PI 4 I used 2 sessions of screen with the logging turned on.
code (copy).txt
I did an extremely quick pass. Fantastic!
- The
esp32s2builds are failing due to a newly guarded include insupervisor/shared/safe_mode.c. I would try to fix it but I can't push to your PR's. - Trivial copyediting. Not important.
- Calling the port
raspberrypimight be confusing given one of your aspirations. :smiley: Did you think aboutrp2or similar?
The reset of the alarm.sleep_memory contents would indicate either a power glitch or maybe a hard reset, as discussed. This sounds like some kind of software bug. But does it make any difference if you power the board for long periods with an AC adapter instead of the battery?
@slender iron pre-emptive hug for all the rp2040 work. thank you!
Before I recently received my Adafruit lipoly batteries, I used the USB-C power adapter I have from my Samsung S8 which is a Fast Charge higher current adapter. I re-hooked that this morning to eliminate the batteries as a cause. My memory is that I've seen this issue with the USB-C powered but not connected for serial comm. But I'm old and I don't trust my memory from a week ago. So I'm retesting now. I'll update when I have data. It should not take more than 45 minutes. I've never seen t...
Yes. So I start to understand what is happening here. (1) Raspberry Pi (is it the foundation or the factory side?) make a new silicone (2) Raspberry Pi (same question) build a board with that (3a) adafruit make a Feather and a ItsyBitsy with the silicone from 1 (3b) Pimoroni make the Tiny 2040 with the silicone from 1 (3c) Sparkfun make a board Feather format with SD card with the silicone from 1. (3d) Arduino is working on one
Pimoroni / Adafruit / Sparkfun knew about the chip and the new board... but maybe not about each other project.
That didn't take long. With the USB-C connected to a AC power adapter. It failed after 7 loops. Here's the sequence most recently logged.
USB C powered plugged in while sleeping after loop counter incremented to 5
After incremented to 6, the next loop had PowerON status and counter was back to 1.
Made it to 3 before resetting on next loop.
only made it to 2 then reset,
only made it to 3 then reset,
made it to 7 before reset.
So we have board competition...
And maybe for the first time we have MP vs CP competition on the same board...
I have two board (in the postal service and that need to try the post Brexit thing)... so I can try CP and MP side by side.
This is the best news https://www.recantha.co.uk/blog/?p=20762
s/runs/will run/
it runs now
I'm waiting for the feather, I want a reset button π
boy, you go to sleep for ~8 hours and then this happens
yeah new pi form factor in that time right
I encountered a second problem which may be related to the same design choices, so I'm adding it to this issue.
I wanted to assign each element in microcontroller.nvm, there are apparently 20480 of them. However, after assigning 503 of them I encountered an exception:
Adafruit CircuitPython 6.1.0-rc.1-16-g89d716507-dirty on 2021-01-20; Kaluga 1 with ESP32S2
>>> len(microcontroller.nvm)
20480
>>> for i in range(len(microcontroller.nvm)): microcontroller.nvm[i] = i % 256
...
Tra...
At this point, nvm seems unwritable, even at indices that were written before:
>>> microcontroller.nvm[0] = 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Unable to write to nvm.
@slender iron cool to see the big reveal. So the big appeal of this chip is the PIO subsystem?
@ionic elk and the generous amount of on-chip RAM ain't bad
Closest match I'd have on the ST side would be the F722, I think. I'd have to compare power stats to see how they line up.
@slender iron @onyx hinge I am going to start on draft release notes for a 6.2.0-beta.0 release that will include the RP2040 port.
@stuck elbow oof you weren't kidding about the power
@ionic elk which chip's power consumption are you talking about?
The RP2040, I think, unless I'm reading this datasheet wrong
@tulip sleet did you merge already? it wasn't ready last night
no, the build had issues. I did a review
i am just writing the release notes in advance
Basically yes. We know they knew
@ionic elk SAMD51 is like 24mA at 120MHz running a benchmark program.
Yup! It'll be good for getting data in and out of the chip
Compared to some micros yes but compared to a regular raspberry pi it's much better. Remember where they are coming from
@tulip sleet I'm just comparing to the F722 stats. I think the PIO will have to be the draw for me
@ionic elk did you order picos from adafruit already?
F722 seems to eat it for breakfast stat-wise but I'm sure RP will have much better docs, and hopefully better reliability
@tulip sleet kk, good π we need to update tinyusb first
i did see the tannewt/tinyusb
please do
@slender iron does Adafruit stock that low power measury thing I needed to get too
I don't think so
no, get it from digikey or mouser
k
looks like avnet is actually out too, just Octopart doesn't show it
there were four a few minutes ago, sorry!
at the link above; maybe some lurkers saw my link π
I'm glad I ordered mine before US woke up
Wait is the PPK brand new or something?
dang
Is there a holdover power profiler I could get in the meantime? I had a list way back, I could look for it
no, it's been out for a couple of months, but it really fills a niche
oh, sorry I thought you are tallking about the rpi pico
@ionic elk you could also use an INA219 or similar. I started to set one up but got an actual power meter before I used it.
@tulip sleet can i ping a quick nrf question off you?
ya sure
how much ram should be available on a 52840 after boot? I'm seeing about 100k of ram being used for the vm.
but that seems quite high
I've looked through source and guides but have not seen any docs or in-source mention of what it should be.
@marble hornet 56kB is used for BLE-related storage by the SoftDevice (nrf firmware). 8kB is used for an SPI buffer to work around a hw issue. So ~150kB sounds right. I just checked on one.
stack is 24kB, I think
π thanks for the sanity check.
I am able to replicate this... though for some reason the max key caps out at 403 for me.
Adafruit CircuitPython 6.1.0-rc.1-16-g89d716507 on 2021-01-21; microS2 with ESP32S2
>>> len(microcontroller.nvm)
20480
>>> for i in range(len(microcontroller.nvm)): microcontroller.nvm[i] = i % 256
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Unable to write to nvm.
>>> i
403
This was a concern when implementing NVM as suc...
I just got an ESP32 and I've made it flash an LED. I've got other things I should be doing but I'll give its ADC a spin in Arduino-land to see how it compares in a day or two.
@simple pulsar after more investigation, I don't think 3.3v is true, probably more like 3.1v with 11dB and 12-bit (and possibly some minor chip-to-chip variance), perhaps higher with less resolution as you pointed out in the issue
n00b question, but could esp32-s2 NVM writes still use the k->v buffering, but reads do a direct flash read?
Another great place for Espressif ESP information is their forums. https://www.esp32.com/ I have had great responses from their in-house engineers.
@slender iron draft release notes are ready for a 6.2.0-beta.0 that includes your upcoming PR
thanks! getting the pioasm library published so I can switch off of my mac
I'm looking at the uheap module in readthedocs https://circuitpython.readthedocs.io/en/6.0.x/shared-bindings/uheap/index.html But it isn't mentioned in the support matrix.
it's not turned on; it's for debugging only, and we haven't used it in a year or two
That's what I figured. Is there another way to find the size of an object?
It's for a forum question relating to optimizing memory use
mem_free before/after I suppose.. but that's not necessarily the object of interest.
the minimum object size is 16 bytes, and they are allocated in multiples of that. But integers and floats, etc. are 4 bytes because of their encoding.
Hmm.,. for example I add an int to a list and 240 bytes are consumed.
a list has a minimum size and has room to grow
rather mem_free and mem_alloc change by that much
exactly
you could make a build with uheap on, i think it would still work
just set CIRCUITPY_UHEAP = 1 in the build's mpconfigboard.mk
if you want one, let me know the board. No problem. It will be fast
If they need it beyond curiosity IO can do a build easily enough, but thanks.
@gilded cradle hey, tracing into a pyportal lib issue, and i think i've found where it's tripping. the tides api returns content-type application/json;charset=ISO-8859-1 and that extra charset stuff is making it fail json detection
Its on the edge...
It says debug...
Is it https://debug-edge.io/ ?
Newp... Or I don't see a 3-pin variant. So close....
no, it's not
@tidal kiln Thanks. Can you submit an issue for it? I think that code is in PortalBase.
* Calling the port `raspberrypi` might be confusing given one of your aspirations. smiley Did you think about `rp2` or similar?
I know it might be confusing. MicroPython is rp2 so we can't use it. My thought is that this is the chip manufacturer. For raspberry pi boards we'll add ports/broadcom.
* Calling the port `raspberrypi` might be confusing given one of your aspirations. smiley Did you think about `rp2` or similar?I know it might be confusing. MicroPython is
rp2so we can't use it. My thought is that this is the chip manufacturer. For raspberry pi boards we'll addports/broadcom.
Fine by me! Could be rpi or rp2x but raspberrypi fine as well. I will just type <tab> :smile: .
@gilded cradle maybe the api changed to? fetch() used to return a dict, now it looks like it's a list?
@tidal kiln it's possible. I can compare. If it's different, then that's something that needs to be fixed. It should be the same.
it's related to this:
https://forums.adafruit.com/viewtopic.php?f=60&t=174180
and i can recreate the issue. basically, old code not working with latest lib.
Ok, I can go through and test with the Tides Viewer and submit PRs where applicable.
This is on purpose, GP15 should not be used, it is used by the internal USB peripheral
ok. thanks. i tried using .network.add_json_content_type("application/json;charset=ISO-8859-1") to get around the header issue
Yeah, but what I was going for is that code shouldn't need to be updaed.
Yeah, I'll ping you if I need anything else.
awesome sauce! thanks.
yw
i'll hold off on opening an issue for now. since it could just be me.
ok
This is due to our understanding of Erratum RP2040-E5 -- see the datasheet down at page 632 or so.
@slender iron i didn't see a push to your rp2040 pr, are you still working on it?
yup! almost done
just looking for my USB todo
(and realizing things I still need to do)
ah, ok, looked like you were doing housekeeping
want to merge the other two post-6.1 PRs?
The RP2040 chip itself doesn't have a unique id so implement it by getting the flash chip's ID.
i will re-run #3911 again (builtin help localization)
#3936, native bus device is approved by jeff but not tested
i thought we might hold off on that for a bit
there is also tcp server
Approving and merging as requested.
Right now the flash size is hard coded and the init code is as well. The flash init code is 256 bytes of arm code loaded by the bootloader, checksummed and run. The build process is a bit tricky due to the checksum so it's hardcoded for now.
@slender iron i will approve after the xtensa builds work - thanks!
kk, I figured we'd wait for CI
What's the plan for PIO programming from CircuitPython on the new RP2040 series?
Silly me, I was sleeping for "Show&Tell" and "Ask an Engineer" because it was 2AM and the middle of the week. But usually when Limor wear it's Raspberry Pi T-Shirt it is that a new product will be coming. And then she and Phil stayed up until 2AM to tell us about the RP2040. All the clue were there, I should have known.
@simple pulsar https://github.com/adafruit/Adafruit_CircuitPython_PIOASM
@onyx hinge That's the only bit I'm still excited about
Are those PIO used for RAM to pin signal only (screen, Neopixel, ...) or can they do pin to RAM and pin to pin?
Many were announced and will likely be available in the next few months.
- [ ] Adafruit ItsyBitsy RP2040
- [ ] Arduino Nano RP2040 Connect
- [ ] Pimoroni PicoSystem
- [ ] SparkFun Thing Plus β RP2040
- [ ] SparkFun MicroMod RP2040 Processor
- [ ] SparkFun Pro Micro β RP2040
- [ ] Pimoroni Tiny 2040
@thorny jay I don't want to risk incorrectly summarizing PIO to you so I suggest you check out chapter 3 of https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf
@slender iron good grief, #3911 is still failing on xtensa build due to bad build cache. If yours builds, I will merge it and then re-run #3911.
Can I help folks (@gadgetoid, @nseidle, @mbanzi) do board defines for your boards? We'll need a USB PID for each, the pin names on silkscreen and the flash chip used.
Cytron have a Maker Pi Pico which looks like its the Raspberry Pi Pico soldered the larger peripheral board.
The PIO state machines can shift data in as well
and ya, you could theoretically DMA from one SM to another
the PIO neopixel example seems to be adapted from 3.6.2 if you want more explanation of what's happening.. https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/blob/main/examples/pioasm_neopixel.py
Although not designed for computation, PIO is quite likely Turing-complete, and it is conjectured that it could run DOOM,given a sufficiently high clock speed
β¦
A full 32-bit addition takes only around one minute at 125 MHz
So CP compile from Python bytecode for VM and that VM run on the MCU. Then in Python there is an assembler that produce the code for that PIO statemachine? Maybe I need to take a break and let my brain sleep before it blow up.
pio "programs" are loaded dynamically; they don't need to be part of the CPy firmware
basically yes
some we can build in advance, like NeoPixel
PIO programs are very small. at most 32 instructions
and that 32 instruction space is shared between 4 state machines
individual instructions are pretty powerful though
That's pretty wild, can't wait to check it out
Can it pull in replacement instructions from memory, i.e. self-modifyin code?
@simple pulsar it can run instructions out of the fifo but not store to the instruction memory
ok, run time for me
we need to change how Mu detects a CP board
and really π
it was changed to just use the VID, I thought
Can Mu deal with multiple boards plugged in at the same time? (I only use it occasionally.)
some people rename their CIRCUITPY drives to accomplish that. I don't the serial console does
@simple pulsar the serial/plotter will get confused
also, depending on your platform possibly, it may get hard to tell which Mu tab belongs with which device
@split ocean frequently has difficulties because he use CP to run some controller for his camera and also want to demonstrate CP. There must be ways and trick to deal with that. Typically, my PyRuler, if I want to use it "permanently" and work on another board... I need a kind of feature to make the PyRuler not be detected as a CP board. I would love to know the trick. Some requested to have a way to disable the CP drive.
That would be great. When I think about my uDraw tablet to mouse... it's almost like a product, I want it to be a mouse and forget it is a QT-Py and that I could change the behaviour just by editing a file.
i have a volume control built out of a trinket with a custom build to turn off everything but the HID devices
I wonder what's going on with these spikies. [not really expecting an answerto that] Anyway, it looks like esp32s2 just did an analog out ramp with my WIP code, even if it's not what I expected.
This adds 7 new boards (though only 6 new ones are displayed due to lack of info). I updated some board added dates to reflect when boards were actually added to Blinka instead of to circuitpython.org. If an image isn't available, an unknown image is displayed. Boards are now actually hide-able.
DMA looping works too
I also updated the NokoGiri version per the dependabot alert.
@onyx hinge SAMD51 has setting on its DAC where it can hold the output or not. Otherwise it starts drifiting down. Maybe there is similar on the ESP??
the default was not to hold, which was confusing
I think it would be kind of cool to change whether the drive is enabled or not (or other things) from the UF2 bootloader, but not like by droping a different build onto it, but with some small configuration file thingy
maybe have a UF2 that writes to just a few dedicated bits if that's a thing
the idea being that by using the bootloader, it's always recoverable
yes, right now I just load a "regular" UF2 to edit
a safe-mode boot would bypass such settings
pretty sure safe mode skips boot.py altogether
true
I didn't mean to merge that yet. A couple of small clean-ups to radio.c. Should I back it out and make a separate PR after this one, or leave it in?
Test code for checking enabled before scan:
ITERATIONS = 10
DELAY = 0
for _ in range(ITERATIONS):
print("Enabled? ", wifi.radio.enabled)
try:
for network in wifi.radio.start_scanning_networks():
print("{0:02X}:{1:02X}:{2:02X}:{3:02X}:{4:02X}:{5:02X}".format(*network.bssid), end=" ")
pri...
Thanks for the PR! Sorry I left these pending. Thanks for the ping!
Do you mean the commit was premature? Just push another commit when you're done. No need to start over.
It's not merged yet. If it's in progress, you can mark it as a draft PR.
wait until I merge rp2040, which has a fix to use a good xtensa build cache. Some PR's without that are failing.
k
It's done, it's just a little tangential to the original. Independent except for an error string. It's ready to go once the checks are done if you want me to leave it in this PR.
What are you showing there?
sparkfun_samd21_dev for de_DE ran out of space. Will try to fix that.
@simple pulsar Early work on analog AudioOut for esp32s2. It should have been a sawtooth wave, I don't know what the little "spikies" are yet.
@onyx hinge They have a characteristic look (inc. spacing)
My gut is telling me they happen when a more-significant bit changes
I don't have it anymore but I soldered up an 8bit DAC to a parallel power in my youth to play mod tracker files on a PC. Probably better than Espressif's efforts
I read plans for them back in the day but it was beyond my non-existent electronics skills at the time
failing on xtensa builds, which if I'm reading Discord right, is dependent on the rp2040 merge
right, I will re-run these failing PR's after the #4031 merge (which is having a small issue with the size of one build).
Oh, I misunderstood. No problem. Does it fix another issue, or is just an improvement?
Exactly, the detection should work with other VIDs too.
@slender iron I am cleaning up one thing in the rp PR, and then will re-run the other PR's that are done but not merged
i was able to push to your repo - thanks for the collab invite
i figured you just got back
The missing step for new board creators is when new CP boards come into existence, this file needs to be updated. https://github.com/mu-editor/mu/blob/master/mu/modes/circuitpython.py
new data, I wanted to see if this was WiFi related. I commented out anything to do with setting up a WiFi connection or using AIO. It still resets to loop counter occasionally, I'm going to make a simple program that just does alarm counter increments and see if it still fails and if not look to see if this is the amount of time that the system is in deep sleep
@idle wharf right. we should come up with a way to detect CP that doesn't involve updating that file
Someone who really enjoys using Mu could look into a non VID PID based CircuitPython Mode for Mu..
https://mu.readthedocs.io/en/latest/modes.html
yup, I'll add that to my todo list. may be something we need to add to the usb descriptor
Doesn't have to be you.... just saying someone... ^^^ π up there maybe.
in my opinion Mu needs a simple little serial ports menu to override the default auto detection when it fails or gets it wrong, but I made myself a python script that does it's best effort to detect boards, their name, associated serial ports and drives like I wish already existed, I wonder if building a library for that would be interesting for anyone else (there's still work to do, turns out it's very os-dependent)
like, it gives you that:
[{
'manufacturer': 'Adafruit Industries LLC',
'name': 'CLUE nRF52840 Express',
'ports': ['/dev/cu.usbmodem144443111'],
'product_id': 32882,-
'serial_num': 'F88EE0399C0E1FC6',
'vendor_id': 9114,
'version': '6.0.1',
'volumes': [{'mains': ['code.py'], 'mount_point': '/Volumes/CPCLUE'}]
}]
without needing to know vids since it takes any USB device that has a serial port
Just two small improvements, no associated issues.
Does anyone recall what a solid red LED means on boot -- trying to help in #help-with-projects <#help-with-projects message>
if it's an itsy m4 and didn't have its bootloader updated it may have a smashed bootloader
Thats what I thought π¦ also would be a bad cable, correct?
normally one gets a fast blink on the LED with no USB connection
but I will try an itsy
ah -- sounds familiar...
the dotstar is red also?
appears to be
i have one of those switchable USB cables
just tested with itsy m4 with cable set to charge
dotstar is solid red, LED blinks
after double reset
i get fast blink on LED next to reset button with an AC adapter for both itsy m0 and m4 with double-click
If anyone feels like commenting to the thread -- feel free. Sounds like a bad bootlader.
or something with what the itsy is attached to
probably; you could have them try an AC adapter to double-check, just in case it's some weird host problem
I need some pointers on pointers!
I'm trying to add the ParallelBus for the ESP32-S2. I need to write an 8-bit integer into the GPIO output register (32 bits). Following the other incarnations of ParallelBus, I take the GPIO output registers (g->out) and create a uint8_t pointer into it at the right location for the correct pins (self->bus).
The trouble I'm having is that I can't seem to write using the uint8_t pointer (self->bus).
Here's my trial code:
gpio_dev_t *g = &GPIO; /* this is the GPIO registers, see "extern gpio_dev_t GPIO" from file:gpio_struct.h */
self->bus = ( (uint8_t*) &g->out ); //pointer to GPIO output register (pins 0-31)
mp_printf(&mp_plat_print, "\n\nPointer addresses:\n");
mp_printf(&mp_plat_print, "&g->out: %x\n", &g->out);
mp_printf(&mp_plat_print, "self->bus: %x\n\n", self->bus);
mp_printf(&mp_plat_print, "Writing zeros to parallel output\n");
g->out = 0x0000;
mp_printf(&mp_plat_print, "Current output g->out: %x\n", g->out);
mp_printf(&mp_plat_print, "Current output *self->bus: %x\n\n", *self->bus);
mp_printf(&mp_plat_print, "Writing ones to parallel output\n");
g->out = 0xffff;
mp_printf(&mp_plat_print, "Current output g->out: %x\n", g->out);
mp_printf(&mp_plat_print, "Current output *self->bus: %x\n\n", *self->bus);
Here's the output:
Pointer addresses:
&g->out: 3f404004
self->bus: 3f404004
Writing zeros to parallel output
Current output g->out: 0
Current output *self->bus: 5a
Writing ones to parallel output
Current output g->out: ffff
Current output *self->bus: 5a
The GPIO pointer is uint32_t (g->out) seems to write zeros and ones just fine. But somehow when I try to use the uint8_t (*self->bus) to read it, it seems to be pointing somewhere else. I thought \*self->bus should return ff but it returns 5a (I assume some random value in memory).
I think this may be something to do with the 32bit vs 8bit but I can't figure it out. Anybody can "point" me in the right direction?
@mental nexus you can also print the pointer itself with %p in printf
you can use that to confirm you are dereferencing the right location
I would double-check the operator precedences
add parentheses to make sure
but I think those are ok
Here's the latest. Not WiFi related! I ran the code.py below with a deep sleep timer of 10 seconds and I let it get into the 90s before I reset. I had no Poweron status except the one immediately after reset. When I changed to deep sleep timer to 60 seconds I started to see a large number of Poweron status exiting DeepSleep. I'm going to start playing with the alarm timer interval to see where it's stable and where it starts to reset the MCU,
import busio
import board
import a...
@tidal kiln want to test https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/pull/103 ?
hey all, wondering about how the RPi pico works with the official micropython and circuitpython.
for the official micropython, do you download the UF2 file and drag a .py file with code onto a mass storage device to run? and the same with circuitpython, i assume that's how that's working too? just a bit of confusion on my end.
@gilded cradle cool. thanks. yep. will do. i'll respond in pr thread.
Thanks
@slender iron @tulip sleet ok I will take another look. I thought maybe I have a big/little endian confusion but I canβt trace it. Iβll try your debug tips and see if I can track it down.
Memory is sufficient on the RP2040 for longint support. My build for the raspberry_pi_pico went from 499040 bytes to 512380 bytes used, leaving 536196 free.
@zinc maple for official micropython you have to use Thonny to load code. They don't have the device show as a mass storage device (and use non-FAT filesystem internally)
CircuitPython acts as mass storage and stores files to FAT
basically works like all CircuitPython boards
@slender iron #4044 ^^, I could add this, just looks like forgotten in mpconfigboardmk
?
Thanks! It might have just been an oversight. Will merge after a good build.
oh that's bad news, i just spent a few hours making a cool chrome based code editor web app that used the new direct file system api to allow you to edit files directly on the board without downloading every time you wanted to edit it. Might have to spin it into a Circuitpython editor instead π
@zinc maple please do! I have no idea why they don't show as a drive
for anyone interested in an early beta
i could swap things out for circuitpython
my fault for not checking how it worked before i wrote the app, would make a cool circuitpython web editor still though
Can you enable it at the port level instead of board? We should be able to assume we can fit it since they always use external flash.
i was too fast
Thanks! It might have just been an oversight. Will merge after a good build.
I'm inclined to close this issue. Current status:
Logging
- All wifi Events are now logged from the event_handler (PR 3903), I think we should leave this in place as it's very useful for troubleshooting
- All Disconnection reasons are logged from the event_handler, ditto my vote for keeping this in place
- There is no logging in
wifioutside of the event_handler ininit.c. However, I'd suggest when major new features are added, we consider adding it in for some period of time ...
Thanks for all of the investigation @jfabernathy! Sounds like you are closing in on the issue.
is there a spec on how long you should be able to deep sleep?
My original sample program when I wrote https://learn.adafruit.com/deep-sleep-with-circuitpython/sleep-memory did not have this problem, and I was not sleeping that long. I let it run for dozens of cycles. See the example there. So something may have changed. 10-20 seconds should be fine, and not too low.
@slender iron are you ok with the latest commit in https://github.com/adafruit/circuitpython/pull/4017
I'm doing a 30 second deep sleep test now. once it gets to >255, I'll be happy. I want a one minute sample rate on my temperature readings. So since 60 seconds will not work reliably, I may have to sleep 30 seconds and only post data every other time thru the loop. I'm surprised that 60 seconds is a problem. That sounds like a issue, especially since the battery voltage is good. Must be an internal MCU issue or drain on a power rail.
We deep-sleep for anywhere from 10 seconds to 24 hours. All should work. It's a bug if you can't.
Closing. I haven't seen this for a couple of months, probably addressed by other improvements.
@gloomy shuttle @thorny jay I've been playing with Nunchuk code with delays completely removed from the I2C read and it seems to be working very reliably. The only thing I can think that made this not work before was that the I2C bus may have been clocked at 400kHz instead of 100kHz. At 100kHz, it seems pretty solid. The removal of these delays essentially negates the need for any fancy buffering or special reading. Please try the version of the library code here
https://github.com/caternuson/Adafruit_CircuitPython_Nunchuk/blob/speedup/adafruit_nunchuk.py
and see if that performs OK with current Nunchuk examples - with no other changes to the example code. Hopefully it's just fast now. And make sure whatever host you are using has I2C SCL set to 100kHz. It defaulted to 400kHz in some older firmware and maybe even library code.
I am not sure about the course of action: (1) fix the mouse hid (2) make the above the new version (3) change to module (4) add other device with simpletest. And most importantly who does what step and what device.
We have many cancelled PR and WIP.
(2) and (3) sound like same thing? basically update library to something like that and (1) is just fixed.
(4) comes later
i can PR the suggested change, but was hoping you could also help test if you wanted to - for the nunchuk case
(3) is a folder with or without _ _ init _ _
oh, is see. ok (3) comes later also.
I can test the new Nunchuck, but all the version I tested worked.
(5) rename to match (4)
this should hopefully work with the current analog mouse code though
some of the other approaches required new code for that example
I try tomorrow (1 AM here).
sure. np. can be whenever. thanks!
I will test the nunchuk version you just linked to tonight. I have something form 8:00 to ~9:00 pm est, so I'm not sure if I will get it tested before that.
My 30 second deep sleep did not work. I saw 10-15 Poweron statuses in the last hour. I'm going back to 10 seconds and let it run overnight and keep it on USB C power
@tidal kiln this version switches to the values approach which shouldn't change anything for testing, but are you planning on implementing it this way? Also, there is another potential sleep that could be removed in the __init__ method.
i might change that in the final version. it would be functionally equivalent though. i'd probably remove values and move code back into each property.
yep, i saw that delay in __init__ also. that one's less annoying since it's just run on once. but i do want to look at that also and see if can get removed as well.
and no real need to hurry on the testing. just as you can. and then can ping me back here whenevs.
I agree with all of the above. I didn't need it during my testing yesterday.
i really wish i knew why that didn't work before. the SCL freq is just a guess. may never know.
I figured out how we can get searching of code working in the CP Repo...
https://docs.github.com/en/github/searching-for-information-on-github/searching-in-forks
"Forks are only indexed for code search when they have more stars than the parent repository. You will not be able to search the code in a fork that has less stars than its parent. To show forks with more stars than the parent repository in code search results, add fork:true or fork:only to your query."
We need about 10,000 people to star the CP Repo for that to be true.
https://github.com/adafruit/circuitpython
there is a code search sort of service that notro setup at one point
we could run one separately
I like the idea of 10,000 new stars. But yes. I mean I could search my filesystem too...
we'll get there π
Someone run serverinfo.... CP has 2k stars... so I think about 24,000 people could help π
Regarding my pointer issue, I'm unsure if the ESP32-S2 will allow non-aligned access. There's a note here in section 10.3.3 of the ref manual:
I'm trying to access address 0x3F404004, right in the middle of this section that may cause an interrupt or exception.
Also, there seems to be a related issue here: https://github.com/espressif/esp-idf/issues/597
I posted a question about this on the ESP discord. I'll report back here if I get any good leads or clarification. In light of this stumbling block on single byte writes to the GPIO registers, Iβll craft a version with full 32-bit writes as a starting point for ParallelBus.
@tidal kiln it runs great on the QT Py, but not so well on the featherS2. I tested all the examples on the QT Py. I used the nunchuk_analog_mouse.py on both the QT Py and the feathers2. The QT Py averaged .0079 seconds per loop while the feathers2 averaged .059 seconds per loop. I know there have been some reported issues on the feathers2 with I2C, so that may be the issue - https://github.com/adafruit/circuitpython/issues/3894
I've got a Feather S2 and this sparkfun board: https://www.sparkfun.com/products/16294 . The sparkfun board is at address 0x60 vs the 0x67 that adafruit has for their MCP9600 CircuitPython ...
thanks. and agree about S2.
Using today's UF2 for the S2 and yesterday's Circuit Python libraries seem to have undone the SDA/SCL pull up regression. The board now recognizes the Adafruit AHT20. Still hasn't solved the original issue. The sparkfun board that works with the Feather S2 in Arduino code still does not register in Circuit Python. In the I2C scan code above, it still shows [] for that board. It also seems to want to reboot a lot now.
I'm reading the Espressif docs and see that the UART can be set to wake of the ESP32s2. Could CP has something set or unset that could be allowing UART noise, etc. to be interfering here?
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/system/sleep_modes.html
Oh, I never knew boards had to be added there... I just forked and did a PR to get the FeatherS2 added π Thanks for pointing this out!
Thanks @dhalbert, that matrix clearly shows I'm either dyslexic or an idiot. pulseio is included on the M0, pulsio just doesn't exist!
I would like to hold off on this PR for 6.1.0-beta.0. A number of de_DE builds are overflowing by small amounts. It would be nice to find some savings somewhere rather than radically shrink these builds, or do special de_DE builds.
We are only enabling the wakeups corresponding to the alarms being set. The API is straightforward.
I will try to duplicate this within a few days. We are somewhat swamped at the moment, sorry.
I would like to hold off on this PR for 6.1.0-beta.0. A number of de_DE builds are overflowing by small amounts. It would be nice to find some savings somewhere rather than radically shrink these builds, or do special de_DE builds.
This is not as complicated as I thought. I think I have the fixes I need.
Is it pretty simple to disable everything but the HID or at least the drive mount portion. I have few different custom controllers that I would like to attempt this with.
I wonder if most people that star CP are not also staring MP...
Will MP also lose search if...
CP has 2k MP has 11k. I donβt know if the search is only for the most stars.
I know this was asked for in micropython 5ish years ago, but it seems that it still hasnt been implemented. I was wondering if this would be possible to add? Im currently working on creating a calculator that can be plugged in and have programs modified. The menu system ended up using that functionality.
class Program(object):
def exec():
'''to be implemented in programs'''
pass
def run(self):
params = self.exec.__code__.co_varnames[1:self...
This code works fine when the MagTag boots cold.
`
import board
import busio
print(dir(board))
i2c = busio.I2C(board.SCL, board.SDA)
def printdevices():
i2c.try_lock()
# Find the I2C devices available.
devices = i2c.scan()
print("I2C devices:", len(devices))
for device in devices:
print(hex(device))
i2c.unlock()
print("I2C unlocked! ")
printdevices()
`
 version of the previous version or waiting for a "PPK2.1" would be better. I've just got some traction with Nordic via YouTube interaction so hopefully they'll be some clarity on the PPK2 behaviour.
Is there a reason for reference_voltage to be optional?
tested on hardware
>>> print(0x1000000)
16777216
>>> print(0x10000000000)
1099511627776
>>> print(0x10000000000000000000000)
309485009821345068724781056
print(0x1000000)
16777216
print(0x10000000000)
1099511627776
print(0x10000000000000000000000)
309485009821345068724781056
I investigated the filesystem access "angle" because I believe I see similar disruptions to the neopixel during UF2 bootloading -- the LEDs are mostly blinking yellow/orange, but occasionally a flicker of another color can be seen. This potentially points at a problem outside of CircuitPython, or in implementation code that is shared between CP and the UF2 bootloader. However, Kattni and N+P's scenarios don't seem to involve filesystem/flash access.
Final update from Espressif:
According to our design team ESP32-S2 no longer needs extra compensation as ESP32 does.
Yes. ESP32-S3 will share the same voltage limitation as ESP32-S2
@jepler Can you get an analogue view of the data? Perhaps the salae isn't showing some strange nastiness in the actual signal due to either thresholding or transient spikes?
https://gist.github.com/4abd21700ae7df90c7a788db7272703a I've created a function for wrapping text according to the width in pixels rather than the width in characters.
(though, if no font is passed in, it will also wrap according to width in characters)
@simple pulsar with respect to the neopixel problem I think the much longer data transfer is probably the smoking gun, and analog spikes are probably not it. As always, I could be wrong.
Yeah, I deleted that when I re-read and saw the length.
A close look would show what's going on though?
Yeah I may not have organized my comments in the best way, thanks for reading it again and I'm happy to hear you're coming to the same conclusion
Have you got a hires capture of the whole thing? My logic analyser is the cheapest one from Ikalogic range and has rather limited capture capabilities
I think it can save the whole trace but I didn't.
this is a saleae and I'm not very skilled at using it yet
Yay! Now running ParallelBus on an ESP32-S2. Speedy.
yes, you can also change the aref on some chips either internally or externally. many chips have default tat folks dont use
@slender iron I'll tag 6.2.0-beta.0 momentarily. Has all recent relevant PR's except for bus device, which I would like to see more testing on.
@lone axle I found routines to wrap text according to the number of characters but not the number of pixels in a particular font. Did I overlook something? Is this code maybe worth pulling into some lib or other?
@onyx hinge Ooooh, Neat. Correct though to the best of my knowledge we don't currently have that functionality anywhere. I am definitely in favor of bringing it into display_text! Here is where the wrap by characters function is at now: https://github.com/adafruit/Adafruit_CircuitPython_Display_Text/blob/master/adafruit_display_text/__init__.py
That is awesome because you could pass it display.width to get decent wrapping behavior across different screen sizes without having to tweak the code perhaps!
Automated website update for release 6.2.0-beta.0 by Blinka.
New boards:
- adafruit_feather_rp2040
- raspberry_pi_pico
- stm32f411ce_blackpill_with_flash
New languages:
- sv
- nl
- ko
- fr
- pl
- it_IT
- de_DE
- en_x_pirate
- zh_Latn_pinyin
- hi
- pt_BR
- es
- en_US
- fil
- ID
- cs
- el
- ja
needs to fix the new language detection
Link to the QT Py Haxpress build from the regular QT Py page.
I'm always clicking the wrong one, and have to go back to the main boards list, where
the sorting/order is unknown so the haxpress version isn't next to the regular one.
I tried to make this generic (relative URL, etc), since I don't know if it's used anywhere other than https://circuitpython.org/board/qtpy_m0/ - but this was a bit of a usability papercut for me as I inexplicably keep upgrading the version I have on the board ...
@lone axle @onyx hinge Are you taking into account proportionally spaced fonts?