Thank you! By number of files this was a lot of work. I spotted one mistaken change, though
#circuitpython-dev
1 messages Β· Page 44 of 1
that is codespell's mistake, I think!
@dhalbert @tannewt quick question - since this board seems to have a metric π© ton of SPI and I2C definitions, would it be safer to not define them as specific numbered ports (
i2c0,spi0, etc.), and just let the user configure those when needed? Since there's no extra hardware that needs management, I see no point in enforcing a specific port order on any of the pins.
This board is basically a Pi Pico clone, obviously, so we'd follow that lead. It's up to the user to check the pin map...
well, maybe not codespell, not sure how that happened. Just flailing fingers at some point. Tnx!
@tulip sleet thanks for all the help on my PRs (M5Paper and the RP2040-Plus). Quick question - the RP2040-Plus has two flash variants, but as far as I can see they both use the same USB_PID - however this is causing obvious build issues. What shall we do here?
(also, apologies for bringing the discussion here, but I suspect it will be quicker than the back-and-forth on the PRs themselves)
I was guessing it was from global search and replace of ure to re, which resulted in sure changing to sre.
fixed! & made some additional updates
@dhalbert in that case this PR is ready to merge, as soon as we resolve the PID issue - it looks like Waveshare used the same PID for both the 4M and 16M models, which obviously is causing issues here.
sorry, I was afk, I'll answer in the issue, to make pointing to something easier
No trouble π I'm in a boring AF meeting anyway
I think that at least for touch, the C code could be implemented much better than the naive python code would do it. I still have https://github.com/adafruit/circuitpython/issues/6445 on my todo list somewhere, but I doubt I will be able to look at it this year.
The idea is simple: measuring capacitance for touch requires a certain delay β that makes checking all the pads one by one with python code individually rather slow. But many platforms that have support for touch allow you to initi...
I wish they had asked for separate PID's. But add an exception here to make the duplicate test not fail.
https://github.com/adafruit/circuitpython/blob/main/tools/ci_check_duplicate_usb_vid_pid.py
Added the exception, let's see what the CI says
pre-commit hates spaces :grin:
Can you replace your sensor with just a potentiometer?
@jepler OK, everything passing now except for the docs build, which you fixed and is in the 8.2.x->main merge.
Yes, I tried that also. The pin read 2819 through the full range of the potentiometer as well.
Can you try
pin = analogio.AnalogIn(microcontroller.pin.GPIO32)?
Do any of the exposed ADC1 pins give a value?
None of the analog pins that I tried give any value except 2819.
I also tried microcontroller.pin.GPIO32 and got the same result.
I have also tried 3 different identical boards with the same result.
The analog pins work on MicroPython just fine.
Can include #8319 now.
ADC2 pins work for me on a HUZZAH32 breakout (similar board, without on-board USB-serial converter). ADC1 pins are stuck at 2819. Try pin IO14, for instance, for now, while we debug the ADC1 issue.
This pinout shows which pins use ADC1 and which use ADC2:
https://cdn-learn.adafruit.com/assets/assets/000/112/292/original/adafruit_products_Adafruit_ESP32_Huzzah_Breakout_Pinout.png?1654548847
I tried ADC2 but, if I recall correctly, I get an error that the board's wlan is in use.
I did a non-exhaustive search of which pins work for ADC on a no-name brand of ESP32 board using the same ESP-WROOM-32 module that's in the DOIT ESP32 board, running CircuitPython 8.2.3 for the DOIT ESP32 board. My sensor was a 10k pot hooked up to Gnd, 3v3, and the pin in question. The Dxx numbers in the DOIT board def are the same as IOxx numbers of the ESP32 chips)
Works fine for ADC reads:
- D4
- D12
- D14
- D25
- D27
- D34
- D35
Does not work. Allows creating of `Analog...
This appears to be the pinout of the DOIT board if that's helpful.
I will look and see what's different about our analog-in impl vs MicroPython and/or Arduino.
I did a non-exhaustive search of which pins work for ADC on a no-name brand of ESP32 board using the same ESP-WROOM-32 module that's in the DOIT ESP32 board, running CircuitPython 8.2.3 for the DOIT ESP32 board. My sensor was a 10k pot hooked up to Gnd, 3v3, and the pin in question. The Dxx numbers in the DOIT board def are the same as IOxx numbers of the ESP32 chips)
Works fine for ADC reads:
* D4 * D12 * D14 * D25 * D27...
I tried ADC2 but, if I recall correctly, I get an error that the board's wlan is in use.
Should work in Circuitpython before wifi is imported. 'wifi.radio.enabled = False(thenTrye`) may be enough to wrap ADC2 reads interspersed with wifi use.
@tulip sleet What's the plan on a new 8.x release? The Metro S3 will be in the shop tomorrow or Thursday. And we don't have a release for it.
For some reason I thought we did, but cp dot org isn't showing it.
Should be in the shop by then. No guarantees.
we are fixing various things. I talked about a release with Jeff. I can make a release today, but was trying to fix a few more things. But shop presence is a reason to take a milestone now. @onyx hinge I could just make a release now; would be a short-term thing I can do without embarking on anything else. I was trying to debug ESP32 ADC1 issue, but not close on that
I will start on release notes
I mean, I can get artifacts off of my PR for now
But we need it before it goes live, I would think.
actually I was more worried about certificates -- I forgot I wanted to work on that
throw a release together like the matrixportal s3. if there are bugs i'll find some of them.
while i don't like making more work for devs, finding bugs is just part of the process with new releases.
I'm using the web interface to program the ESP32, so wifi must be enabled. The entire purpose of using this board is to make use of the wifi to send sensor data via MQTT messages, so even if the analogio works without wifi enabled, it still doesn't serve the purpose I was intending. Thank you though.
@tulip sleet I just got back from lunch & errands -- is there anything more you wanted me to approve for that 8.2.x release you're talking about?
no, though I did want to try an updated roots.pem. I will make the release notes first, and then see if that is a rat-hole or is quick.
i can't even imagine the stuff you're all going through for the 9.0 merge. good luck. π«‘
The failing doc build should not block merging this PR.
Can include #8319 now.
done
@dhalbert @n0rt0nthec4t Same problem here on pico with CP 8.2.3
import usb_midi
import usb_cdc
import usb_hid
import storage
usb_cdc.disable() # Disable both serial devices.
usb_midi.disable() # Disable mini
usb_hid.enable((usb_hid.Device.KEYBOARD, )) # Enable just KEYBOARD
storage.disable_usb_drive()
storage.disable_usb_drive() - with this line commented HID KEYBOARD shows and works properly - tested on WIN7 64bit
So how to disable storage with us...
if you remove the usb_hid.enable() line entirely, but leave all the rest, does it work?
I have a volume control that is built with a Trinket M0, with code similar to the above. I upgraded it to 8.2.3, and it is still working properly. It does not disable anything in HID, and it does not disable MIDI, but it does do this:
storage.disable_usb_drive()
usb_cdc.enable(console=False)
Hi, I have an idea, and I could drop that "in the weed" next Monday... but maybe I can start a bit of brainstorming here to test the water.
For I2C sensor and all the libraries, we do have one or multiple "simpletest" python file to demonstrate basic use of the library (and hardware). But we have no such thing for board.
If I get a new board, I would like a quick start piece of code that use all the board specifics such as: button, LED, NeoPixel or DotStar, I2C, I2S, buzzer, ... Each contributor of a board could also provide a test code.py that does basic things like blink LED, monitor button, run a rainbow. With discotool, one could download automatically all the library needed. Both together could be a quick human test for regression.
For library, the simpletest are in the library repo, but for the board code.py demo need to be somewhere else... and that could be near to the board definition or with similar structure in adafruit/circuitpython repo. Alternatively this could be in circuitpython.org, or at least have an easy way to download both the firmware and that quick start demo code.
So somebody submitting a new board definition could simultaneously provide that short piece of code that demonstrate how to use the board build-in things.
What do you think?
I just tried D34 and D35, and both report nothing but 2819.
This is what is in https://learn.adafruit.com/circuitpython-essentials/, but the code examples are not per board.
The trouble with a per-board file is the the supplied code.py will get out of date, and maintaining hundreds of these could be a nightmare. So it's factored by function, not by board.
there is templating done in the learn guides per board, there are general pages that get more specific when inserted into a particular board guide
Yes and no, and I frequently return there to build that basic code.
But I have a board here with button A, B and C, and I had to test to know it I needed to use Pull Up or Pull Down. So my expectation is to have a code that work and does the right thing.
On some board you have to change a pin to give power to some component, until you figure out you believe your board is broken.
Of course it will be hard to maintain, but how frequently do we change basic stuff like Neopixel, button, led, ...
Yeah, board guide are great, but they cover only the Adafruit board... that is not the majority of CP usage.
for adafruit boards, that info is in the board guides. of course we don't have board guides for non-adafruit boards (except for Pi Pico, etc.)
i would argue, that just running a per-board demo code.py, is a good way to ensure the port for that board isnt broken
a good way to test everything the board has
so, that file would get regular testing and be fixed rapidly
Board manufactures sometimes do provide sample code, I suspect hosting that code in the repo or circuitpython.org could present a support problem (expectations of Adafruit supporting 3rd party code). I know there's a link in the board descriptions back to the manufacturer, but perhaps some of what your hoping to gain could be achieved with a formal link to manufacturer provided sample code.
we have relied on the mfrs to make their own board guides
for example, the rpi-zero port, booted to a prompt, but all attempts to run python, even just help() at the repl crashed
yes, we don't want to support other people's boards in an official way
so it would have needed a demo code.py (although in this case, just a print("hello world"); would have done) to see that the port was alive or not
but a broader board specific code.py would help with confirming every part of the port is still working
I'm not saying this is a bad idea, but we can't maintain it, and putting it in adafruit/circuitpython is probably not the right place for that. A third-party boards wiki...
Board learn guide are not perfect. I wanted to do sound (I2S) with my Feather RP 2040 USB Host, but there was nothing related to that. However, in the learn guide for the Feather RP DVI board, the wiring, schematics, sample code were provided. Maybe there need to be some templating to put all the Feather RP 2040 at the same level.
rp2040 i2s is something that should work on any rp2040 board with at least 3 consecutive gpio, and a free pio
Yes it could be another place, but so a board maker that want to be perfect need to PR to 3 repo, circuitpython, circuitpython-org and a 3rd one...
so that seems like a template you can just #include into every compatible board
it's fine to bring this up on In the Weeds, we could brainstorm about it
I mean "learn guide template" or whatever trick is used to automatically generate a lot of documentation for new board.
yeah, i meant #include it into the guide for that board
At least, the place where I spend a lot of "extra" time is when I pick a board and want to try to do something, is that I have to rediscover the board specifics. First I have to remember how to update the firmware (and so I avoid as much as I can the board with special trick, that do not support double click or have not boot button). Once I have up to date, I have to find some basic code to start... more than just hello world.
Many board come with a demo firmware that is used for testing the board, but that is minimal and arduino, not CP + a beefy code.py. Notice that I remember Trinked M0 and Gemma M0 that were distributed with CP, library and demo code.
One could order the board, look at code.py and start customising right away. No download, not documentation, just read the code, and investigate the possibilities.
they were, but the stock rapidly aged, and we were shipping boards with CircuitPython 3.x.x. when we were on 6.x.x.
so that was a different support issue
Yeah, I know. π¦
But imagine the next alpha or beta release, where you just have to call and say: "Please take your exotic hardware, try the simpletest_code.py and check that everything continue to work."
@thorny jay there probably could be some generic code ( common to all boards) that included the pin finder code, i2c scan, detect presence of various other features
My tests were with no WiFi so if that's related that would explain why I could read D34,35
D34 and D35 are ADC1, so wifi shouldn't matter.
Yes of course, a lot can be automated, generic or generated... like:
- Do we have an board.LED => put a 10 second blink.
- Do we have a board.NEOPIXEL => put a 10 second R => G => B => Rainbow
- Do we have a board.BUTTON => scan and do something if pressed.
...
But one of the idea is about the specific of a board. The thing that you have to find in the documentation.
I like the "_INVERTED" I have seen, it give an hint that the LED(?) is acting reverse way.
The other great trick is code that work on multiple board, with detection. Tod was talking about that for his sound stuff, were he has code that work on PWM or I2S or ??? and he include the right file or detect somehow.
detection is very handy, though no help with unidirectional SPI displays
I2C gets tricky if many sensors use same address
thanks for your comments!
ok - so to summarize:
the idea in itself is good -
only not implementable at the current CP state as there are to much edge-cases that can create big trouble...
as i originally came from the need for touchio - i will follow https://github.com/adafruit/circuitpython/issues/6445 more closely...
thats basically what device-tree is for
which gives me an idea, put some dts in the board specific code, that describes the hardware
For display, if there is a board.DISPLAY that is all you need to know. I am mostly focussing on what is on the board, not things you attach later.
then just query it, and poke every bit of hardware you can find
then a single code.py can query the DT, and poke everything, on every board
what is device-tree
that is how linux on arm deals with detecting and configuring hw blocks
what about a board that has 4 different video output ports, some need config, and only a max of 3 can be active at once
On Raspberry Pi, it is a way to load the "driver" for various piece of hardware, like an audio board.
gotcha, not existing in CP-land currently
We are happy with one video output... that is most of the time the maximum. We talk about microcontroler, right? π
Also I can verify that D34 and D35 work with digitalio.
i'm thinking about the broadcom ports, pi-zero(2), pi4
the pi4 has dual hdmi, composite, dsi, and dpi
It is a bit niche... π
currently, the broadcom port only has 1 dumb framebuffer, and it talks to the firmware to allocate it
but the bcm283{5,6,7} all have 6 video outputs
dsi0/dsi1, dpi, smi, hdmi, composite
pi-zero(2) can only use dpi/composite/hdmi
pi1/pi2/pi3 can use dpi/composite/hdmi/dsi1
composite and hdmi conflict, so you have to pick one
a max of 3 can be active at once
dpi can drive a number of the tft's that have been shown on the adafruit streams lately, or converted to vga
broadcom port is a bit alpha (or beta). Not sure a lot of people use CP barebone on Pi SBC (I tried, but I would use Blinka). Also natively you don't have much on the Pi, no button, one LED, audio and video.
But if you want to write a simpletest_code.py that demonstrate everything already possible and working on the Pi, that's great.
i need to finish adding 2d and 3d support first, heh
an open source start.elf, demoing both the 2d and 3d cores at the same time
-rwxr-xr-x 1 root root 2.0M Sep 7 00:52 start.elf
entire program and image data is all in an open source start.elf
cpu is running at 216mhz on an rpi1
cpu usage is very low, due to hw acceleration
this is a baremetal C demo, that uses <1% cpu
fully hardware accelerated
in theory, it should be possible to port all of that to circuitpython
Automated website update for release 8.2.4 by Blinka.
New boards:
- adafruit_metro_esp32s3
- pajenicko_picopad
Stuck job, will merge anyway. Thanks!
Here is a roots.pem that I generated a couple of weeks ago using the procedure described in https://github.com/arduino/nina-fw/blob/master/README.md#build-a-new-certificate-list-based-on-the-google-android-root-ca-list.
When I substitute this one for the one in lib/certificates/data/roots.pem, talking to github works again.
But I was unable to come up with an Adafruit IO example that breaks on the...
I think I'm misunderstanding how the options in mpconfigboard.mk work. I've turned off a large number of optional modules (RE, ULAB, etc) but when I build CP and then display gc.mem_free() there's usually no impact. I turned off 11 modules and mem_free reported 64 additional bytes available
modules would affect flash, but wouldnβt affect RAM unless imported
Ah, that explains it, thanks!
@wraith crow ```Successfully created esp32s3 image.
1484320 bytes used, 612832 bytes free in flash firmware space out of 2097152 bytes (2048.0kB).
4186 bytes used, 4006 bytes free in 'RTC Fast Memory' out of 8192 bytes (8.0kB).
0 bytes used, 8192 bytes free in 'RTC Slow Memory' out of 8192 bytes (8.0kB).
16383 bytes used, 16385 bytes free in 'Internal SRAM 0' out of 32768 bytes (32.0kB).
232780 bytes used, 193204 bytes free in 'Internal SRAM 1' out of 425984 bytes (416.0kB).
0 bytes used, 65536 bytes free in 'Internal SRAM 2' out of 65536 bytes (64.0kB).
This might help: I wrote a library to mix multiple keypad scanner instances (or compatible) into a single event queue, with this example for using it with the reverse TFT feather:
When we merge a PR, firmware are uploaded to S3. Before that, artifacts are available.
The files have names like adafruit-circuitpython-8086_commander-en_GB-20230803-95c0867.uf2. This is not all that helpful. At the moment, when we are making both main and 8.2.x PR's, it would be nice if the names included the nearest tag and possibly the PR number.
Seconded. PR would be particularly efficient for bisects.
@silver tapir [I think that's who I mean to mention] The other day I thought I sent these messages/links to the channel but they went to a different discord by accident ... the context was that "milk v" linux board
https://community.milkv.io/t/baremetal-rtos-with-milk-v-duo/341 Someone has asked if there's bare metal / RTOS support and there has been no response
"bare metal" is the key word if you want to run circuitpython/micropython direclty on the hardware, rather than running within the linux OS
In the Pico W build files mpconfigboard.mk has a line that seems to set the firmware size to 1536*1024 and there is a link.ld file that sets the firmware_size to 1532K. Shouldn't these both be the same (1532 or 1536)?
The build results indicates a Flash Region size of 1532K.....
@wraith crow the other 4kB is the nvm space
or I may be confused
let's just say the difference of 4kB there is something I thought had to do with the 4kB NVM area
I've been building the Pico W with the latest main branch bits and this evening was getting the "Sending request failed" message with one of my test programs. After building with the roots.pem file Dan posted the test program is working again.
That being said, my test program was running fine when I built from main last night so I'm thinking the error only occurs when you hit a particular server somewhere in your path.
I'll keep using the new roots.pem and if I hit any failures with it ...
I figured it might be something like that, but wanted to mention it just in case it was a typo π
The change to nina-fw that we think introduced this problem was initially done in the 8.2.x branch. However, it probably started affecting main today when we merged #8317.
After nina-fw is updated, the fix in CircuitPython will probably initially be made in 8.2.x and merged into main subsequent to that, though it depends on how Dan and/or Scott want to handle it.
New boards, including Adafruit Metro ESP32-S3, and some minor fixes
https://blog.adafruit.com/2023/08/22/circuitpython-8-2-4-released/
This is a speculative fix for the latest build failure on RTD: https://readthedocs.org/projects/circuitpython/builds/21689508/ which appears to be due to a change in RTD's "conf.py.tmpl": https://github.com/readthedocs/readthedocs.org/commit/2066e3486a25bbd76431e1f8c20be3da0043f03a
failure message says in part:
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/circuitpython/envs/latest/lib/python3.11/site-packages/sphinx/config.py", line 358...
@onyx hinge I will cancel the PR build (not the merge build)
I do not know why it's building all boards, I noticed that though
I've spent several days trying to figure out if this board makes sense with a Pico W and if so how it should be configured. I've built the following configurations:
- DVI and WiFi enabled and activated upon boot -> WiFi doesn't function and less than 50K working RAM
- WiFi enabled and activated, DVI available but not activated -> less than 50K working RAM
- WiFi/Cyw43 not included, DVI enabled and activated upon boot -> ~90K Working RAM
I really wanted option 2 to work but with l...
Since finding the adafruit_requests bug I reverted the MatrixPortal S3 down to 8.2.0. I realize there are some bug fixes for it since then. Kind of stuck on this one for a little bit for multiple reasons.
Was able to get at least 2 panels working. Could not get 3 or 4 working using any setup of across, down, or serpentine. Possibly due to bad cable as panels 3 & 4 were artifacting heavily. Attempted to DIY a longer cable with 5 feet of ribbon cable from digikey and ended up breaking the...
Tagging @PaintYourDragon, since this might be Protomatter-related.
CircuitPython version
Adafruit CircuitPython 8.2.0-87-ge08ad22ef on 2023-08-22; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
N/A
Behavior
It should be 8.2.4-...
Description
No response
Additional information
No response
8.2.x was split off from main at 8.2.0, so the tag would not advance.
I am going to tag with a 9.0.0 tag soon. This does not mean we are going to make a 9.0.0 release. We will wait until the .mpy version stabilizes. It is changing at least twice as we merge from MicroPython. The v1.19.1 merge already made one change.
So far I have found 0 breaking changes (other than the need to regen all .mpy's).
.mpy sizes reduced a good bit:
mpy-cross-8.1.0: 73.3kb
mpy-cross-8.2.0-87-ge08ad22ef (current master): 68.0kb
Speed seems a bit up, but I still haven't made benchmarks.
NEWBIE QUESTION - My new esp32-s2 mini does not have the sda or scl broken out - i have been beating my head against the wall all morning - getting the sda and scl set in circuit python so I can talk i2s
i2c = I2C(sda=Pin(11), scl=Pin(12)) doesn work
oops wrong place - excuse me please...
[adafruit/circuitpython] New tag created: 9.0.0-alpha.0
[adafruit/circuitpython] New tag created: v1.20.0
[adafruit/circuitpython] New tag created: 9.0.0-alpha.1
If you do git pull --tags from adafruit/circuitpython now, you should get a
9.0.0-alpha.0 tag (first PR after 8.2.0 split)
and a
9.0.0-alpha.1 tag (MicroPython v1.19.1)
pushing a new MicroPython tag caused the CI to try to run the Micropython jobs π€¦
And it also causes fetch errors. I wondered why I hadn't seen that before
From https://github.com/adafruit/circuitpython
* branch HEAD -> FETCH_HEAD
! [rejected] v1.19 -> v1.19 (would clobber existing tag)
! [rejected] v1.19.1 -> v1.19.1 (would clobber existing tag)
db29125a994dfe4f746d44f497db260b46155166 refs/tags/v1.19.1
9b486340da22931cde82872f79e1c34db959548b refs/tags/v1.19.1^{}
jepler@bert:~/src/circuitpython$ git ls-remote origin | grep v1.19.1
9b486340da22931cde82872f79e1c34db959548b refs/tags/v1.19.1
```the tags are different in some way that I am not sure I understand so I won't try to explain
i don't understand those errors, because I think they are at the same commit.
I think the "real" one is what man git-tag says is an "annotated tag" and the non-real one is a "lightweight tag"
I made the 9.0.0-alpha.* tags be "annotated" tags, so I could add comments. I think that may be what triggered the builds
is the local one lightweight or annotated?
but when did one annotated and one lightweight get created?
my local one matches the micropython one, it is an annotated tag. git show of it begins tag v1.19.1 Tagger: Damien George <damien@micropython.org> Date: Fri Jun 17 12:58:09 2022 +1000
so they are both annotated, but for some reason it is not comparing them as identical (or isn't even bothering to check)
no, I'm saying the micropython v1.19.1 is annotated and the circuitpython one is not.
aha ok, well feel free to replace the lightweight one, and be prepared to cancel jobs π
To github.com:adafruit/circuitpython
+ d7919ea71e...c548cdcb58 v1.19 -> v1.19 (forced update)
+ 9b486340da...db29125a99 v1.19.1 -> v1.19.1 (forced update)
i never labeled v1.19 or v1.19.1 myself, so somehow the annotated tags became lightweight
this should make the tags in circuitpython be annotated tags that match micropython
what did you do to make adafruit/circuitpython have the v1.19.1 tag?
i did a gh repo clone adafruit/circuitpython, which picked up upstream (I didn't mean to do that), and then I made my 9.0.0... tags and then did push --tags
it pushed the v1.19 tags
did you intend to create the v1.19 and v1.19.1 tags in adafruit?
or did it just happen?
i.e., should my fix be to try to "make them truly match micropython" or should they just be deleted?
we have already had all the mpy version tags anyway, do git tags and you'll see them
so I think it's fine to have them
https://github.com/adafruit/circuitpython/tags?after=7.2.3
OK. I did the command above non-dry-run and now git fetch --tags from adafruit doesn't show the errors. Off to cancel the CI jobs...
if you remove the
usb_hid.enable()line entirely, but leave all the rest, does it work?
@dhalbert No change. No hid device on device manager.
Host computer is a PC running Ubuntu 22.04.
Look's like Host is not a problem here.
Any ideas?
@microdev1 Want to get this ready once more and we'll merge it now that 8.2.0 is out? Thanks!
Hey, I can pick this up sometime around mid-september.
This can be merged now that 8.2.0 is out.
I deleted the jobs completely, since they were just noise
ah, thanks. I didn't think about even doing that
@onyx hinge @slender iron I have been mile-stoning real bugs as 8.2.x if they seem worth fixing in the short run, since 9.0.0 will be a while. That is, 8.2.x is no longer just "absolutely must fix soon". We can always move them forward later.
Noted! that makes sense.
while we're thinking about other keypad types .. I'm reminded of the resistor ladder kind where each key produces a distinct voltage. It'd be neat to support those.
I have seen that twice in Show and Tell... and that was mind blowing.
I did not fully understand the details except that combining a resistor for the row and a resistor for the column you get a unique value. But how to practically do that and find the right resistor (after using his software to compute things)... I still don't totally understand the practicallity.
treat it the same as an r2r DAC
for example, powers of 2, each resistor is double the last
I think maybe @thorny jay is talking about http://www.rau-deaver.org/1-wire_keyboard.html (which I couldn't get to run on my Linux but no matter); it uses just (# rows) + (# cols) + 1 resistors to allow detection of single(?) keypresses among (# rows) Γ (# cols) switches, which is likewise beyond my understanding..
I can see that pressing some particular key forms a resistive divider and so you can calculate what the nominal voltage is for any particular key .. but choosing the resistor values seems tricky.
the trick i was thinking of, only needs 2 wires and an ADC, let me see if i can find examples...
and the links got deleted, lol
http://www.ignorantofthings.com/2018/07/the-perfect-multi-button-input-resistor.html
lets try this?
with an image maybe? ....
if no buttons are pressed, R1 acts as a pullup, and you get 100% on the ADC
ah, this design wont allow multiple presses, there is a clear priority towards the left
but this design, i think?
yeah, http://www.whatimade.today/reading-multiple-bits-using-one-arduino-pin/ mentions r2r dac right below the schematic
its also simpler then i was expecting, its using the resistors in series to get a different value for each switch
so they are all using the same resistor
the rau-deaver program seems to use three resistor values, one for the pull-up, one for the column-chain, and one for the row-chain. The values are approximately X, X/C and X/R/C where X is the A/D max input impedance.
oh, chaining, i didnt notice that in your previous screenshot
i assumed it was a normal scanned matrix
also all but the smallest matrices run into overlapping A/D ranges. It's very cool that this tool checks over temperature range, resistor tolerance & ADC tolerance!
neat
it wouldn't be at all workable for a gamepad, it seems to me
where you really need to be able to press up + left + a + b
well, they did it anyways
π€£ π
ok, not a matrix
but I still hate them for not being able to just use the keypad module
to be fair they probably weren't thinking about the keypad module at the time
for sure, it didn't exist
does anyone know offhand how to build CircuitPython for ESP32-S3 so that the console is on the UART and the special JTAG peripheral is exposed instead of tinyusb?
I got picow-ap working alongside sta and you can indiviually start / stop both.
Pr incoming.
Only one tini tiny problemo ramaining which I can't fix..
If you stop the ap it won't start back up correctly.
So you only get to turn it on and then off once.
- AP can now be started / stopped seperately from STA.
- AP and STA can work at the same time.
- AP can now be made OPEN (no password).
Known issues:
- If the AP is started and then stopped it cannot be started back up again.
It does start, but CP has no idea it's up (CYW43_LINK_DOWN & no IPs).
Mitigation: Add check instart_apand a proper error message.
But it works on WinCE if it is connected from boot time.
I spent a day on that. I didn't manage to do it. I managed to get it booting without CIRCUITPY_USB, but that's it.
It should be possible to make s3 act like c3 (serial + jtag).
I have lost those branches though.. It was a while ago.
If you notice, during boot, it starts in "C3" mode and then switches to the usb + serial mode.
Can you adjust the shared-bindings docs to match? authored I think would be the main one.
I saw the update by @makermelissa for swapping the ADDRA and ADDRD pins. I swapped them manually in software last night and that didn't help. There are also a couple other updates that might help fix this bug in 8.2.3 or 8.2.4
Since I'm still having hard faults, by reverting to 8.2.0 to cut the adafruit_requests bug out is of no help since 8.2.0 is worse than 8.2.3 for the matrixportal s3 running matrix panel code. Can't even get all the panels up and working so reverting CP was a poin...
Hello,
I would like to build CircuitPython for a custom RP2040 board I constructed. Using MacOS, so this would seem to be the right place for docs: https://learn.adafruit.com/building-circuitpython/macos however, it refers to the Linux setup for the toolchain: https://learn.adafruit.com/building-circuitpython/macos which does not have anything for the RP2040 as far as I can tell.
Can someone point me in the right direction here? Or is there a better way to go about this? Maybe there is an easier way to change board definitions around (memory and GPIO available) than rebuilding things from scratch.
Thx!
Sure, but I don't see anything in need of updating.
The docs incorrectly stated that picow could do OPEN already.
But that now is correct.
However there is no notes regarding the AP not working.
Adding one.
Started modifying the code a little in an attempt to narrow down the bug. Still hard faults with this new code. Attempting to bisect a little today.
Adafruit CircuitPython 8.2.4 on 2023-08-22; Adafruit MatrixPortal S3 with ESP32S3
Board ID:adafruit_matrixportal_s3
import board
import displayio
import rgbmatrix
import framebufferio
import terminalio
from adafruit_display_text import label
panel_bit_depth = 1
panel_base_width = 64
panel_base_height = 32
pa...
Building is the way to go if you're customising board defs. Are you on MacOS or Linux?
I'm on MacOS
Ok, great. I'm not sure I understand where your issue lies. Can you tell me where you're at in the process, or have you not started creating your environment yet?
I've started a bit, but in the Linux section there's nothing about building for the RP2040
Admittedly, this is kind of on the edge of my competence.
It references this for ARM processors, but perhaps there is nothing needed in that realm for the RP2040?
Give me a moment.
I would start with getting the PICO-SDK working on your system first, using the Chapter 9.1 of Getting Started with Pico PDF: https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf Since CircuitPython uses the PICO SDK, you'll then only need to deal with whatever extra CircuitPython needs if you know you can compile a "hello world" already
Is the SDK necessary to build for RP2040 though? I don't remember.
I swear I've done it and don't recall installing the Pico SDK, but I may be conflating.
You are correct, the CircuitPython make fetch-port-submodules will fetch its own version of the pico-sdk but it doesn't fetch all the prerequisites the pico-sdk needs like cmake et al
So get the SDK working and it will have the prereqs available when I build in CircuitPython?
@cunning sundial How customised are you making these board definitions?
Different GPIO pins, different memory size. So I'd think/hope it's a fairly minor difference.
I don't think you need to do the SDK separately.
that's a good point. maybe just use Pico image to start
From command line
I have gotten my board to run using the Pico image
cd into the circuitpython/ports/raspberrypi directory.
I think that's the right path
then run make fetch-port-submodules
OK, what does that do?
One quesion first, did you run these commands, or some form of them? brew update brew install git git-lfs python3 gettext uncrustify cmake brew link gettext --force
From the page you linked.
I did
Ok.
So the make fetch-port-submodules grabs everything needed to work with the individual port. There's a way to grab everything for CircuitPython, but it takes ages, and if you're building for a specific port, you don't need everything. What that will do is initialise all the submodules that are required for the RPi port of CircuitPython. When you git clone the repository, it does not initialise the submodules automatically, it's a Git thing, not a CircuitPython thing.
Basically, there are links to other repos and items that don't get pulled in with the clone. That actually puts that information into the appropriate directories.
"links"
This is not a literal explanation π
Once you run that command, you should have everything you need to build.
I think.
For what it's worth, I'm not a core developer, but I do build CP from time to time, and I'm running MacOS. So we'll be able to go through this together if needed.
(I work on CP on the Python side of things.)
Well that is awesome of you to offer. TBH, I feel I'm a bit over my head here.
Once you get the environment going, it's quite simple.
Rephrase: it's quite straightforward.
ha
It might not be simple.
right
This is the difficult part.
It is frustrating that this sort of thing starts out with the most difficult part!
It's true! Though it also means getting it out of the way. But, if we weren't here to help, it might mean you don't end up following through. So I understand entirely.
Well that is very cool of you! Anyway, let me do a bit more research/bumbling around and I'll likely ping you in a day or two. Sound good?
Sure! I am around during the week, during business hours and early evening, Eastern timezone. You're always welcome to ping me; I will reply as soon as I'm back around if I'm not available.
Awesome, thanks so much!
There's also a Building.md file in root of the circuitpython repository that has build info. But the make fetch-port-submodules is new, so I'm not sure where we documented that.
So, if anything isn't working right, best to ping someone here because we might have missed documenting a step. π
Sounds good!
Basically, don't bang your head against anything for too long. It might not be a you-problem. π
Advice I need to take more often. π
@DJDevon3 Just curious, did you try building the MatrixPortal S3 using the roots.pem file that Dan posted above?
any qstr of >= 3 chars long is a candidate for use; the input byte value (1) is used to indicate a fixed-length qstr number follows.
I did several builds for trinket m0:
lang after before change (- = more free space)
en_US 3132 2996 -134
fr 2136 2060 -76
ja 1916 1724 -232
ru 2196 2000 -196
A cutoff of length>2 is slightly better for ja and ru and worse for others. This has to do with the relative frequency of latin characters...
It will hard fault if tile does not =1. Try =0 or =2 and it hard faults. Regardless if I use 64x32 or 128x32
Adafruit_32px_RGB_Matrix_Logo.zip
# SPDX-FileCopyrightText: 2022 DJDevon3 for Adafruit Industries
#
# SPDX-License-Identifier: MIT
# Used with Adafruit Feather ESP32-S3
# Coded for Circuit Python & 8.0.0-beta.1 libraries
import time
from math import sin
import board
imp...
No, building circuit python isn't something I've done in a long time. :/ I'm not good with make builds.
Setting tile=0 in the matrix initiation is at least 1 reliable way to trigger the hard fault on the MatrixPortal S3.
This is using the latest bits from main so it has the 1.19.1 Micropython merge included.
Is there a 9.0 alpha bundle? I'm getting
Traceback (most recent call last):
File "code.py", line 7, in <module>
ValueError: incompatible .mpy file
``` with 9.0.0-alpha.1-8-gaf91625fb-dirty
CircuitPython version
Adafruit CircuitPython 8.2.4 on 2023-08-22; BPI-PicoW-S3 with ESP32S3
Code/REPL
import board
import busio
import sdcardio
import storage
import audiobusio
import digitalio
import keypad
import gc
from adafruit_pn532.spi import PN532_SPI
import time
#########
# Buttons
#########
keys = keypad.Keys(
[board.GP13, board.GP14, board.GP15, board.GP16, board.GP17],
value_when_pressed=False,
pull=True
)
...
how to get over py Traceback (most recent call last): File "code.py", line 7, in <module> ValueError: incompatible .mpy file line 7 is just import adafruit_requests
as far as i know the adafruit_requests lib with 8.2.3 is the latest in the requests repo too.
unsure what is incompatible with the mpy
oh is it looking for a .py for alpha builds?
yup that's what it is. added the adafruit_requests.py and it works
The .mpy format changed with the latest MP merge
remove your .mpy files. use .py files, for instance by using circup install --py ...
@dhalbert @RetiredWizard Unsure if this can be closed now or not. Up to you.
yeah I figured it out. I don't use circup. i'm a drag & dropper or in the case of a library file typically use the raw file on github to copy/paste.
If you can roll that pem into an 8.2.5 release that would be very welcomed and would at least close that immediate issue for sure. Putting it off until 9.0 is inadvisable (my opinion) as most SSL API's with adafruit_requests from 8.2.2 to 8.2.4 are mostly broken even on the feather s2, feather s3, etc...
I cannot continue my work porting API examples from secrets.py to settings.toml until this one is fixed.
I can do it exclusively with using the 9.0 alpha build though. Would that be the recommended thing to do now just run 9.0 alpha for the purpose of porting requests examples to 9.0?
That doesn't solve the issue of others using 8.2.2 to 8.2.4 getting left in the dust with broken requests though. :/
makes no difference for me
CircuitPython Build for Custom RP2040 Board
I've tested this on both a Zero W and a Zero 2W and it looks like it fixes #8044 for the Zero. The Zero 2W still has issues with USB activity causing hangs but if you use a terminal over the RX/TX pins, the Zero 2W has been relatively stable. During my testing I didn't see any negative impact from this PR on either Zero or the Zero 2W.
CircuitPython version
Adafruit CircuitPython 8.2.3 on 2023-08-11; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
def startHotPoint():
print("wifi hot point starting...")
ip=ipaddress.IPv4Address(HOT_POINT_IP)
mask=ipaddress.IPv4Address("255.255.255.0")
#gateway=wifi.radio.ipv4_gateway
gateway=ipaddress.IPv4Address("192.168.100.1")
wifi.radio.set_ipv4_address_ap(ip, mask, gateway)
wifi.radio.start_ap(HOT_POINT_SSID,HO...
i guess this should rather be asked/PR'ed against MicroPy, but... can somebody point me to {some PR for another processor as reference/list of things i would need to do} to get it running on another MCU?
i have a STM32H750 and feel it could be a fun learning exercise (and hopefully not too hard being some STMs supported already)
I wanted to port w801 which is a fun undocumented chinese mcu adventure, but failed miserably.
Silabs recent port: https://github.com/adafruit/circuitpython/pull/7833
There is already a board with a STM32H743 MCU supported. You can probably use a lot (if not all) from that
@spare jacinth I don't have sufficient knowledge/experience to be helpful but if you want a family of microcontrollers supported in circuitpython, you would start with us .. we don't share our "ports" with micropython.
i was expecting the MCU-/family- specific code to be pretty much the same on both repos, and since they already support STM32 (eg pyboard) i thought the ports on Circuit were "imported" from them, at least partially
i really dont mind PR either repo (tho i usually use Circuit just for the sake of being easier to work with, having the drive showing up)
i simply thought that was the way to go
The majority of the port-specific code is to control peripherals, and our philosophy about it (the shared-bindings/common-hal split that we have) is different enough that it has not proved "worth" sharing. (though I wasn't around for the decision to do it this way and there's probably a lot of context I am unaware of or oversimplifying) for instance rp2040 has 7680 lines in common-hal, compared to 378 in supervisor + 565 in the top level directory.
TIL, didnt know the code was significantly different
will look at the linked PR and/or existing code and see if i can get it working π
I think you'll want to re-implement the displayio stuff in shared-modules in a port specific directory. You'll be the first to do this. I suspect we'll want to try this on the higher end imx rt too because they have basic 2d dma sorts of things.
bcm soc's also has a 2d mode in the dma block
which lets you have differing strides for src&dst
i'm also wondering what your thoughts are on my stack pr for the zero
Do you have a display active?
A display? You mean displayio?
No that was a naked RP2040 USB Host, I was powering it from a power brick (or my PC) and it had an I2S amp and speaker. Also the midi keyboard connected (it was sensible to the sequence of powering, maybe the keyboard was drawing too much or too fast).
I can redo the setup, maybe try a 9.x release if it matters.
You seem to mostly work on that imx board, and I only have the Feather well 3 of them.
Will look today. Haven't gotten to email yet
@lone axle re your in the weeds, an number of those libraries are mine that I haven't completed. I'm happy to go over the list to get them finished up
Ya, displayio of some sort. I tested a usb host feather and it was slow until I disabled the display. I didn't actually setup i2s out though...
Wait you made a piano demo... was it pwm? No I took your code and only changed the I2S because the amp I have is from Adafruit and does not require a library.
the demo I had was i2s on imx
my test on rp2040 didn't use i2s
@silver tapir looks like the milk-v SoC has a DWC2 USB on it and should be supported by tinyusb
I can remove the audio and print(f) debug.
@silver tapir I'd suggest getting tinyusb going first
I'll test that as soon as I get a some boards that are slowly getting to CR.
it looks like the board uses nand flash which we don't have support for in CP yet
all of our boards use spi nor
or internal nor
Actually I think I tested without the sound, because it was way too loud and I did not knew about Tod audiomixer to reduce the level. So maybe I2S init was done, but no note were playing.
CircuitPython will only pick one major and one minor version of MicroPython per major version of CircuitPython? This would be to enable consistency of native modules. Native modules must be promoted to CircuitPython major versions.
We don't have a specific plan to support native modules.
Until then, we welcome any native code additions as a new module in the core CP repo instead. That way it can be maintained by others and doesn't rely on the native module mechanics from MP.
@microdev1 Would you mind doing a merge to resolve the conflicts? Thanks!
This looks fine to me. Do you have more changes you want to add before merging?
I think you've updated the broadcom-peripherals library on your fork. Please PR those changes to the adafruit version first and then point this PR to it. (Sorry it is annoying.) IIRC tinyusb also uses the peripheral library for its testing.
@buoyant lagoon βοΈ
I tested this on a raspberry pi Zero 2W both with and without the parameter defined in the boards/raspberrypi_zero2w/mpconfigboard.h file.
Pretty sure you have a Pico W too. π
I have many... did you find a way to connect your sequencer to something making sound with synthio? Or even doing it directly on the Pico?
Have not touched it in many months. I blame Adafruit for releasing new shiny things every weekπ€© that immediately divert my attention. A convenient excuse.
hmmm, odd
https://github.com/cleverca22/broadcom-peripherals/tree/move-stack
i only made 1 commit, but github says its 41 commits ahead of upstream
maybe other people have been forgetting to PR their changes?
Not syncing a fork or pushing before sync does that.
gitk says otherwise
Iβll look later. Away from my desk for an hour or two
Welp.
Running in safe mode! Not running saved code.
You are in safe mode because:
Internal watchdog timer expired.
Press reset to exit safe mode.```
Completely different code this time, same board.
S3?
Yes.
This time I'm trying to run an I2S pin identifying script.
Last time was an SD card demo.
The script runs fine until it instantiates I2S.
Except initialising it in the REPL is not failing.
Trying an actual I2S demo.
This is running fine.
.....
@crimson ferry This is the script. Why would it be failing but I can run a tone demo, and even do deinit() in the loop in the tone demo and not get safe mode? (It errors because I deinitialised it, but no safe mode. ```py
import board
import audiobusio
from microcontroller import Pin
def is_hardware_i2s(bit_clock, word_select, data):
try:
p = audiobusio.I2SOut(bit_clock, word_select, data)
p.deinit()
return True
except ValueError:
return False
def get_unique_pins():
exclude = [
getattr(board, p)
for p in [
# This is not an exhaustive list of unexposed pins. Your results
# may include other pins that you cannot easily connect to.
"NEOPIXEL",
"DOTSTAR_CLOCK",
"DOTSTAR_DATA",
"APA102_SCK",
"APA102_MOSI",
"LED",
"SWITCH",
"BUTTON",
]
if p in dir(board)
]
pins = [
pin
for pin in [getattr(board, p) for p in dir(board)]
if isinstance(pin, Pin) and pin not in exclude
]
unique = []
for p in pins:
if p not in unique:
unique.append(p)
return unique
for bit_clock_pin in get_unique_pins():
for word_select_pin in get_unique_pins():
for data_pin in get_unique_pins():
if bit_clock_pin is word_select_pin or bit_clock_pin is data_pin or word_select_pin
is data_pin:
continue
if is_hardware_i2s(bit_clock_pin, word_select_pin, data_pin):
print("Bit clock pin:", bit_clock_pin, "\t Word select pin:", word_select_pin,
"\t Data pin:", data_pin)
else:
pass```
I got it to run for 8 pin pairs this time, and then safe mode again.
More to add to the issue I already filed I guess.
I tried running an I2S pin identifying script and ended up in the same safe mode. Running the I2S tone demo does not result in safe mode. I can get the pin script to print 8.5 lines of pin combinations before it resets into safe mode.
I don't know enough about what's going on here to know if it's related, but I'm including it here anyway.
Script below.
import board
import audiobusio
from microcontroller import Pin
def is_hardware_i2s(bit_clock, word_select, data):
...
Why are you changing the block size? I'm worried other code may break if it isn't 512 bytes.
The first line needs the """ removed so that the comment includes the added line. The ... should still be after it because it signifies the empty part of the Python function. The "stub" bit.
@idle owl sorry, not sure, just that S3 seems to have some quirks, hopefully some get ironed out with the new esp-idf
Thanks for replying. The frustration is that this is standard guide code, and I'm having to include warnings on these pages with links to that issue saying "sorry, it doesn't work, follow the issue here". Bleh.
It has not had issues on previous S3 boards.
The Metro, on the other hand....
FWIW tried running it on my S3 board (8MB of RAM) and it crashed too, so error should not be on that side π
Hmm ok
I could be wrong but seems like backporting has backported some bugs too. Will be ironed out in time. In the mean time warnings for all affected learn guides sounds like a lot of work.
but i have no idea what it could be
A lot of hard faults out there now too. The stability of the s2 and s3 will likely break more the closer we get to 9.0. I think everyone kind of expected that to happen eventually. Guess weβre closer to that point than previously thought.
my fw is 8.2.something btw
Iβm not complaining. Canβt wait for 9.0. Itβs going to get messy before it gets better with the merge and a lot of new moving parts.
@tannewt shall I remove the commented out init sequence for the EPD? The IT8951E driver is quite complex (and the M5Paper has some weirdness about bringing up the SPI bus, apparently at init it needs to be low speed, around 1MHz, then later ramped up to 10-20MHz), and I'm not sure I'll have the time to port it. Also, since apparently the REPL is pushed to the main display (based on the Waveshare ESP32-S2-Pico-LCD I got, which does so), I'm not sure if it's wise to have the display assigned to...
Totally fine to leave it out until you have time to add it. Folks can always do it from user Python code too.
Information about the board:
https://hackaday.io/project/186921-game-22
Hardware design repository:
https://github.com/python-ugame/ugame-22
Is it possible to use PicoDVI from user code? Or does the wifi init stuff prevent it?
@microdev1 Want to get this ready once more and we'll merge it now that 8.2.0 is out? Thanks!
Hey, I can pick this up sometime around mid-september.
I'm working on it already so check in with me if you want to assist. Thanks for the huge head start on it!
Does this require a specific version of the pico sdk and/or the CYW firmware?
Probably a duplicate of #8288
@idle owl I'll try and look at that issue tomorrow. (Maybe during my stream)
Is there a 9.0 alpha bundle? I'm getting
Use the .py files for now. We don't want to may a mpy bundle until 1.20 is merged because it changes the mpy format again.
@tannewt I just try and I can run the more minimal code of this issue without error on my board (I'm in 8.2.4, Her test was at in 8.2.0-75)
In that case, if you don't mind, let's leave the commented out code as-is, it might be a good future pointer for anyone who wants to implement it.
Which means it's ready to merge π
Last I tried stuff were far more broken.
For example, you needed to stop both STA and AP to stop STA.
That is no longer the case.
I just retried everything now that picosdk was updated.
I have never touched the cyw firmware, nor do I know how.
Is it possible to use PicoDVI from user code? Or does the wifi init stuff prevent it?
With option 2, you can bring up the PicoDVI HDMI output with user code. The REPL was displayed fine, but you're left with something like 45K of RAM memory free, which didn't seem to be enough to use the screen for anything else.
Thank you for the clarification. Already started transitioning the libraries on my 9.0 alpha boards to all py libraries and thus far everything is working as expected including the MatrixPortal S3.
Updated to
Adafruit CircuitPython 9.0.0-alpha.1-8-gaf91625fb-dirty on 2023-08-23; Adafruit MatrixPortal S3 with ESP32S3
Board ID:adafruit_matrixportal_s3
Working code:
# SPDX-FileCopyrightText: 2023 DJDevon3
#
# SPDX-License-Identifier: MIT
# Used with Adafruit MatrixPortal S3
# Coded for Circuit Python 9.0 alpha
import time
from math import sin
import board
import displayio
import rgbmatrix
import framebufferio
import adafruit_imageload
import terminalio...
Why are you changing the block size? I'm worried other code may break if it isn't 512 bytes.
When I found this bug, I was experimenting with a board which has an additional external SPI flash memory (on SPI lines shared with other peripherals): I wanted to have a filesystem backed by that flash chip. I wrote a minimal class that implements the BlockDevice protocol on top of the SPI flash, and since the erase block for that flash chip is 4k, the simplest approach was to use a block size o...
apparently i need to use backticks and python in github otherwise it displays all shouty here
I am working on this now!
For a totally unrelated project, and in a very early coarse state
This uses a format where a bounding-box is drawn around each font, and the bounding-box and offset is automatically detected and encoded into the font to save space
It is also fast, as it uses a searchable index, which is very small, and can fit in RAM of most MCUs.
The individual characters from the font can be fetched by a few read().
Once packed, unifont-15.0.06.bin is 1.6M, which is 25% smaller than http://unifoundry.com/pub/unifont/unifont-15.0.01/unifont-15.0.01.bmp while also supporting skipping the lesser frequent glyphs, thanks to the index.
It is a python implementation, but should be fast enough for most MCUs thanks to the index.
It is not a full font rendering engine with support all the complexity of text (like what https://libs.suckless.org/libgrapheme/ does for instance), but can be used as part of one, as a font conversion and storage format.
It currently takes input as a .bdf file.
it looks like you already have a fairly good font resource infrastructure π
https://github.com/tannewt/circuitpython/tree/b06e4aeb60d49f511e056e7541d781a19965dffe/tools
Well, I could have been using that instead of reinventing the wheel ^_^'
anybody knows what this means?
Slcp parse warnings for /home/runner/work/circuitpython/circuitpython/ports/silabs/circuitpython_efr32.slcp
Referenced SDK Extension 'cp_efr32:1.0.0' could not be found.
I'm getting that error on a completely unrelated pull request
funnily, only for en_US
if we're not interested in taking a change that enables changing FF_MAX_SS then we should instead MP_STATIC_ASSERT it.
It seems the internet canβt can not be shareοΌwhen I connect the esp32-s3 to my routerοΌ
and start_apοΌand my phone connect the apοΌbut my phone can not visit the internetγ
@slender iron updated the PR to use the merge commit
the point about flash chip sizes is an interesting one. right now we have several different implementations that do read-modify-write for exactly this reason. these have even proven to be buggy in the past (a recent stm32 issue I recall) could we drop those in favor of the implementation in oofatfs and have less code to write for ourselves?
Also, doing read-modify-write to have 512-bytes logical blocks on top of 4kB erase blocks comes with the cost of up to 8x the flash wear for sequential block writes, which are common. Unless one switches to littlefs or another filesystem designed to limit wear.
The AP is a low-level wifi connection with rudimentary DHCP. An AP is not a router. Any protocols or functions needed on top of basic connectivity need to be written (or imported from a library): sockets, requests, etc.
Does anyone use the Chinese translation? how can i check how many downloads?
Usually dan pulls the download numbers. He just sent me some since he is out. Let me look
the numbers I have are by board. let me see if I can figure out how to get them by language
oh, yeah maybe just most popular bought board then if too much work
pico is most popular by a lot
# board _col1
1 raspberry_pi_pico 3074
2 raspberry_pi_pico_w 1715
3 circuitplayground_express 603
4 waveshare_rp2040_zero 600
5 arduino_nano_rp2040_connect 594
6 matrixportal_m4 576
7 adafruit_feather_rp2040 560
8 seeeduino_xiao 512
9 lolin_s2_mini 482
10 doit_esp32_devkit_v1 465
11 adafruit_macropad_rp2040 464
12 adafruit_qtpy_rp2040 449
13 cytron_maker_pi_rp2040 437
14 pyportal 425
15 circuitplayground_bluefruit 421
16 adafruit_kb2040 405
17 seeeduino_xiao_rp2040 375
18 waveshare_rp2040_lcd_1_28 374
19 vcc_gnd_yd_rp2040 362
20 trinket_m0 351
21 feather_m4_express 349
22 feather_nrf52840_express 334
23 seeeduino_wio_terminal 328
24 adafruit_feather_esp32s3_tft 327
25 adafruit_feather_esp32s3_4mbflash_2mbpsram 327
26 ssci_isp1807_dev_board 322
27 metro_m4_airlift_lite 322
28 adafruit_feather_esp32s2_tft 321
29 pyportal_titano 318
30 adafruit_qtpy_esp32s2 317
31 pimoroni_picolipo_4mb 317
32 yd_esp32_s3_n16r8 306
33 pimoroni_picolipo_16mb 306
34 adafruit_feather_esp32s2 305
35 elecfreaks_picoed 304
36 Seeed_XIAO_nRF52840_Sense 302
37 grandcentral_m4_express 301
38 challenger_rp2040_wifi 301
39 pyportal_pynt 300
40 challenger_nb_rp2040_wifi 293
41 gemma_m0 292
42 wiznet_w5500_evb_pico 291
43 boardsource_blok 290
44 aramcon2_badge 289
45 neopixel_trinkey_m0 288
46 pygamer 285
47 qtpy_m0_haxpress 284
48 clue_nrf52840_express 281
49 feather_m0_express 281
50 qtpy_m0 279
51 sparkfun_pro_micro_rp2040 278
52 makerdiary_m60_keyboard 276
53 feather_m4_can 275
54 arduino_nano_33_ble 273
55 itsybitsy_m0_express 270
56 metro_m0_express 269
57 pimoroni_pico_dv_base 269
58 pimoroni_keybow2040 267
59 pybadge 265
60 pycubed 265
61 spresense 263
62 TG-Watch 263
63 pillbug 262
64 weact_studio_pico 262
65 pimoroni_picosystem 261
66 challenger_rp2040_lora 260
67 0xcb_helios 258
68 feather_bluefruit_sense 256
69 seeed_xiao_esp32c3 255
70 nfc_copy_cat 254
71 seeeduino_xiao_kb 254
72 challenger_rp2040_wifi_ble 253
73 pimoroni_plasma2040 252
74 itsybitsy_m4_express 251
75 pimoroni_tiny2040 250
76 wiznet_w5100s_evb_pico 249
77 trellis_m4_express 248
78 pimoroni_servo2040 247
79 adafruit_magtag_2.9_grayscale 247
80 pyruler 246
81 adafruit_qtpy_esp32s3_nopsram 242
82 sparkfun_samd21_mini 241
83 pimoroni_interstate75 240
84 solderparty_rp2040_stamp 240
85 meowbit_v121 240
86 winterbloom_big_honking_button 240
87 pewpew_m4 239
88 particle_xenon 239
89 hallowing_m4_express 238
90 bastble 237
91 capablerobot_usbhub 234
92 espressif_esp32s3_devkitc_1_n8r8 232
93 mini_sam_m4 231
94 cytron_maker_nano_rp2040 226
95 pca10100 226
96 espressif_esp32s3_devkitc_1_n8 224
97 espressif_esp32s3_devkitc_1_n8r2 223
98 edgebadge 216
99 adafruit_itsybitsy_rp2040 215
100 xinabox_cc03 215
For all versions of 8.2.x
By language:
# language _col1
1 en_US 32018
2 en_GB 3853
3 ja 2821
4 de_DE 2420
5 es 1947
6 it_IT 1901
7 fr 1892
8 pt_BR 1806
9 zh_Latn_pinyin 1805
10 sv 1761
11 ru 1682
12 nl 1671
13 pl 1606
14 fil 1560
15 tr 1512
16 ID 1506
17 en_x_pirate 1504
18 en_us 1
Thank you, very helpful.
I'm sure it is not very good, but I guess anything is better then nothing.
I wonder how much of that is just bots and automatic download scripts
I'd assume all of the pirate downloads are
so I'd subtract that number
sounds about right
if we're not interested in taking a change that enables changing FF_MAX_SS then we should instead MP_STATIC_ASSERT it.
I'm fine taking the change in but wanted to warn against it being untested.
the point about flash chip sizes is an interesting one. right now we have several different implementations that do read-modify-write for exactly this reason. these have even proven to be buggy in the past (a recent stm32 issue I recall) could we drop those in favor of the implementation in ...
I think you want to point to https://github.com/adafruit/broadcom-peripherals/commit/ec1043800fc987f7067fc07615193439843695d6 since it is derived from the merge commit. (That repo is a little weird.)
Download counts by version: ```
version _col1
1 7.3.3 97156
2 8.0.5 56732
3 8.1.0-beta.0 45995
4 7.2.5 44781
5 7.1.1 44181
6 8.0.0 42949
7 8.0.3 38863
8 7.3.2 36336
9 7.0.0 34536
10 7.3.0 34219
11 8.0.0-beta.6 33827
12 8.1.0 32730
13 8.0.0-alpha.1 32711
14 7.2.0-alpha.1 31051
15 8.0.0-beta.0 30514
16 8.1.0-beta.1 28751
17 8.0.0-beta.4 28543
18 7.3.1 27551
19 8.0.4 27247
20 8.2.0 26498
21 8.0.2 25803
22 7.1.0 25689
23 6.3.0 25523
24 7.2.0 23974
25 7.3.0-beta.1 22094
26 6.2.0 21991
27 7.3.0-beta.2 21708
28 8.0.0-beta.5 19358
29 7.0.0-alpha.3 19130
30 8.0.0-beta.1 18837
31 6.1.0 18818
32 8.0.0-beta.3 17867
33 8.0.0-rc.2 17484
34 8.1.0-beta.2 17333
35 8.0.0-rc.1 16783
36 7.0.0-beta.0 16733
37 7.0.0-alpha.6 16447
38 7.1.0-beta.0 16410
39 6.0.0 15506
40 7.0.0-alpha.5 15501
41 7.0.0-alpha.4 14991
42 7.0.0-rc.1 14436
43 6.1.0-beta.2 14070
44 20220829-371e544 14039
45 20220829-142c3a4 13772
46 6.2.0-beta.2 13535
47 7.2.0-alpha.2 13468
48 7.2.3 13459
49 6.2.0-beta.4 13436
50 6.2.0-rc.0 13262
51 7.1.0-beta.1 13107
52 8.2.2 12921
53 8.2.0-beta.0 12782
54 6.3.0-rc.0 12615
55 6.0.1 12492
56 8.0.0-beta.2 11916
57 7.1.0-beta.3 11336
58 8.2.3 11311
59 6.2.0-beta.3 11246
60 6.1.0-beta.1 11172
61 7.3.0-beta.0 11135
62 6.2.0-beta.1 11034
63 6.0.0-rc.0 11013
64 8.2.0-beta.1 10134
65 6.1.0-rc.0 9353
66 7.2.4 9267
67 6.1.0-rc.1 9113
68 6.1.0-beta.3 8937
69 6.0.0-rc.1 8892
70 8.2.0-rc.1 8830
71 5.3.0 8439
72 7.2.0-rc.0 8388
73 5.3.1 8279
74 6.0.0-rc.2 8224
75 8.2.1 8088
76 5.4.0-beta.1 7911
77 7.1.0-beta.2 7150
78 6.0.0-alpha.3 6840
79 6.2.0-beta.0 6783
80 6.0.0-beta.2 6658
81 6.0.0-alpha.2 6326
82 8.1.0-rc.0 6116
83 5.4.0-beta.0 5962
84 6.0.0-alpha.1 5896
85 7.1.0-rc.1 5765
86 6.0.0-beta.0 5694
87 5.3.0-rc.0 5333
88 5.1.0-rc.0 5332
89 5.2.0 4934
90 7.0.0-rc.3 4890
91 7.1.0-rc.0 4701
92 8.2.4 4452
93 6.0.0-beta.1 4390
94 7.3.0-rc.0 4373
95 8.2.0-rc.0 4338
96 5.0.0 4086
97 5.1.0 3943
98 7.2.1 3933
99 5.0.0-rc.1 3297
100 7.3.0-rc.1 2994
I'm trying to get at whether a board def is valuable. If you can do PicoDVI from a normal Pico W build, then I'm not sure we want a compromised board def here.
Would you mind adding more comments to this code? It is complex code and should have some comments to explain it. A significant change like this should impact comments but they are missing as-is.
My boards donβt make the top 100 π
Iβve also not sold more than 100 of any board except the CP Sapling Rev B in which over 150 were sold but I donβt think ever used
@ornate breach cp_sapling_m0_spiflash is 135. sapling_m0 is 74. cast away and bread are 103
(those are counts not position)
Not terrible
The pico numbers always surprise me
I think you're right, it's probably not worth supporting a Pico W version of this if WiFi doesn't function. Let me build up the board without the DV init in the board.c (option 2) and try to do something useful with the display again.
I believe the PiCowbell DVI is in the exact same boat except that it doesn't have the other features (SD card, Audio DAC) that a custom firmware helps with.
that might explain why i had an extra 40 commits in my original pr
hi, the guide(s) I found for developing built-in CircuitPython modules are dramatically outdated. Is there an up-to-date guide I might have missed? thanks!
The extending guide is out of date because the build system changed. The building-circuitpython guide is up to date afaik.
thanks! it doesn't mention built-in modules though.
how far have you gotten?
I think the best bet is to look at a pull request for a recently merged new module
I've gotten as far as building / linking a new built-in module, but the "MP_REGISTER_MODULE" approach appears undocumented.
and the build system complains about the switch for my built-in module. Something like "build-bws/genhdr/moduledefs.h:249:6: error: "CIRCUITPY_XXX" is not defined, evaluates to 0 [-Werror=undef]
" (where XXX is my module)
they are usually defined in py/circuitpy_
despite CIRCUITPY_XXX begin defined in mkconfigboard.mk
thanks I'll look into this.
all CIRCUITPY_ are in py/circuitpy* as well. The .mk sets them on the command line and the .h defines more that are .h only.
OK so even though my built-in module is port-specific and can't possibly generalize to other ports, I should still implement it globally?
yup
got it β thanks
I think the espcamera is an example of a module that is only implemented in one port
is31fl3741 is also only implemented in one port (though works on others if someone wants to turn it on)
is shared-modules still relevant at all? In the linked example above I only see additions to shared-bindings and common-hal
@slender iron can I message you quickly about a touch version of keypad?
thanks @slender iron @stuck elbow
Depends what you are doing. shared-module is used for port agnostic implementations while common-hal under a port would be for the implementation for that port
thanks, this confirms what I understand now. I think that the guides on extending CircuitPython should be clearly marked as outdated as they mislead developers at this point.
best to ask here. I'm starting to stream now though
it's possibly sensitive, I will do it some other day then
what other place besides the extending guide?
this is timestamped 2023 but it's as outdated as the extending guide: https://cdn-learn.adafruit.com/downloads/pdf/extending-circuitpython.pdf
I think there's a fairly high correlation between unit price and list position.
I don't know how the last updated time is computed. The warning is in that PDF still
I did some more testing with the full WiFi build, but with DVI output not initialized in board.c.
I didn't have any luck using any of the display helper libraries (adafruit_turtle, adafruit_display_text, adafruit_imageload), they all ran out of memory, however I was able to use the native displayio functions to display a bitmap image or draw pixels.
There's also a reset bug, the board will ctrl-D reset fine until display = framebufferio.FramebufferDisplay(fb) is executed, once the f...
the convo in #live-broadcast-chat gave me an idea, about timing exploits
when doing "foo" not in ["bar","baz"], how exactly does that get compiled?
py/compile.c
STATIC void compile_comparison(compiler_t *comp, mp_parse_node_struct_t *pns) {
if (kind == PN_comp_op_not_in) {
EMIT_ARG(binary_op, MP_BINARY_OP_NOT_IN);
void mp_emit_bc_binary_op(emit_t *emit, mp_binary_op_t op) {
bool invert = false;
if (op == MP_BINARY_OP_NOT_IN) {
invert = true;
op = MP_BINARY_OP_IN;
} else if (op == MP_BINARY_OP_IS_NOT) {
invert = true;
op = MP_BINARY_OP_IS;
}
emit_write_bytecode_byte(emit, -1, MP_BC_BINARY_OP_MULTI + op);
if (invert) {
emit_write_bytecode_byte(emit, 0, MP_BC_UNARY_OP_MULTI + MP_UNARY_OP_NOT);
}
}
i tracked it down to here, but then i get lost and cant find the c backing it
ENTRY(MP_BC_BINARY_OP_MULTI): {
MARK_EXC_IP_SELECTIVE();
mp_obj_t rhs = POP();
mp_obj_t lhs = TOP();
SET_TOP(mp_binary_op(ip[-1] - MP_BC_BINARY_OP_MULTI, lhs, rhs));
ah and on closer look, i can make sense of this more
compile will do MP_BINARY_OP_NOT_IN + MP_BC_BINARY_OP_MULTI
and then vm.c undoes it, op - MP_BC_BINARY_OP_MULTI
so its calling mp_binary_op(MP_BINARY_OP_NOT_IN, ...)
to be more exact, its if username not in db_obj['users'].keys(): where db_obj was decoded from json
not sure if .keys() is returning a set, list, or dict
I was able to reproduce this on a Metro M0 Express. But it may be a Thonny issue, as there is a stack trace in the Thonny backend log. Using a terminal emulator such as TeraTerm to connect to the board shows the correct responses. I have opened an issue with Thonny as well (https://github.com/thonny/thonny/issues/2914).
circuitpython is really not supposed to be exposed to the internet
yeah
i'm still curious as to what the answer is
where exactly is the C code that implements that not in operator
in the dict implementation, I would think
557 STATIC mp_obj_t dict_keys(mp_obj_t self_in) {
558 return dict_view(self_in, MP_DICT_VIEW_KEYS);
559 }
i think that is the .keys() method
STATIC const mp_obj_type_t mp_type_dict_view = {
{ &mp_type_type },
.flags = MP_TYPE_FLAG_EXTENDED,
.name = MP_QSTR_dict_view,
.print = dict_view_print,
MP_TYPE_EXTENDED_FIELDS(
.binary_op = dict_view_binary_op,
.getiter = dict_view_getiter,
),
};
STATIC mp_obj_t mp_obj_new_dict_view(mp_obj_t dict, mp_dict_view_kind_t kind) {
mp_obj_dict_view_t *o = m_new_obj(mp_obj_dict_view_t);
o->base.type = &mp_type_dict_view;
o->dict = dict;
o->kind = kind;
return MP_OBJ_FROM_PTR(o);
}
STATIC mp_obj_t dict_view_binary_op(mp_binary_op_t op, mp_obj_t lhs_in, mp_obj_t rhs_in) {
ah, thats why i had trouble finding it
dict.keys() is a special type of object, a dict-view
which has its own implementation of binary-op
so it can share the backing dict, rather then making a copy of the keys
case MP_BINARY_OP_CONTAINS: {
mp_map_elem_t *elem = mp_map_lookup(&o->map, rhs_in, MP_MAP_LOOKUP);
so i think its ultimately going here
which is basically just dict[key] != null
what exactly is a qstr in the context of (circuit)python?
iirc it's an int
an index to the table of interned strings
but what happens if you decode a json file from the cpy drive, do those keys get interned?
no, only literals
ahh
so this case will have no qstr's
would the json decoder produce an ordered dict?
// if the map is an ordered array then we must do a brute force linear search
if (map->is_ordered) {
no idea
mp_obj_t mp_obj_dict_make_new(const mp_obj_type_t *type, size_t n_args, size_t n_kw, const mp_obj_t *args) {
mp_map_init_fixed_table(&kwargs, n_kw, args + n_args);
}
void mp_obj_dict_init(mp_obj_dict_t *dict, size_t n_args) {
dict->base.type = &mp_type_dict;
mp_map_init(&dict->map, n_args);
}
void mp_map_init(mp_map_t *map, size_t n) {
map->is_ordered = 0;
}
void mp_map_init_fixed_table(mp_map_t *map, size_t n, const mp_obj_t *table) {
map->is_ordered = 1;
}
looks like a dict can be both
is the json decoder implemented in c or python?
no json in shared-bindings
in which file?
ah
the json library is builtin, it doesn't use ordered dict
so i can ignore that half of the code...
do you know where are the bindings for it?
looks like its a hashmap
so the timing attack i had theorized, doesnt exist in that exact case
I'm sure you can dos it with a long string
i was thinking more along the lines of information leakage, then DoS
as an example, lets say the dict contained "admin"
i was thinking, a search for "admiX" would take longer then a search for "adXX"
because strcmp() would compare more characters
but because its a hashmap, the number of matching bytes means nothing
[u]json comes from MP, so it's where the MP things are when we haven't moved them to shared bindings I think ? which is... er...
it will still take longer if there are collisions
ah, that's extmod then
right extmod/modujson.c
thanks
but that time will be based on the hash collision, so you would have to reverse the hash to get the leaked data
I forgot about it
that's more effort than I was willing to spend
i searched shared_bindings because i misread this msg ^
and thats why i never found anything
the json is using next = mp_obj_new_dict(0);
which then goes thru
mp_obj_dict_init(o, n_args);
map->is_ordered = 0;
yep, i can confirm, non-ordered
there is however a btree module for implementing databases that suffers from a similar timing attack
the original bug that made me think of this, was the signature checking on the bcm2835
its using an hmac-sha1, so it generates the expected signature in a 20 byte buffer
and then memcmp()'s against the real signature
if the 1st byte is wrong, it doesnt bother checking the other 19 bytes
so, you can brute-force the signature, by just doing 256*20 guesses
rather then the intended 256^20 guesses
bcm2836 fixed that bug
Is there a helper utility of any sort that allows mpy-cross to operate on a directory instead of a single file?
could always use bash
for file in **/*.py; do echo mpy-cross $file ; done
that will loop over each file, and run echo mpy-cross on it
adjust until the args look right, then remove echo
as long as they don't have spaces in the names
for file in **/*.py; do echo mpy-cross "$file" ; done
now spaces are handled
Thank you. I think this is the thing I was thinking of. https://github.com/micropython/micropython/blob/master/tools/mpy_cross_all.py That is basically the approach someone suggested earlier on in this thread I found discussing it too. https://github.com/micropython/micropython/issues/3040
Hello all, I am new to this board. I am planning to venture to get bluetooth on raspberry pi pico w working with circuit python. At this time it is a naive, foolhearted thought. However, I have prior expertise in embedded devices so still within my reach of a project. Wanted to check here if there is anyone working on this topic already that I can collaborate with? Any pointer that can get me started?
Nobody is working on it right now - there is an issue open here: https://github.com/adafruit/circuitpython/issues/7693 and if you do decide to work on it, you may want to post on that thread
SPI flash question and quad_enable ("QE bit"): Is it possible to interrogate what CircuitPython thinks about the flash chip it's using? I'm working with a 16MB flash chip in an RP2040 circuit that purports to be quad enabled but flash writes to it (via cp file CIRCUITPY) are about 2x slower. Could it be a mislabeled part that doesn't actually support Quad SPI?
you probably want to look at the XIP config registers
Is this a custom build?
default is INTERNAL_FLASH_FILESYSTEM = 1
can try QSPI_FLASH_FILESYSTEM = 1 perhaps?
page 569, section 4.10 SSI
if you read some of those registers, youll have the QSPI clock divisor, and the bus width and read mode
which will tell you the exact speed of reading
writing is slower, always in 1bit width
to write to flash, you first have to stop both cores from executing in flash
turn xip off
do a regular spi write
turn xip back on
resume normal operation
I was going to attempt to add a bigger external qspi chip to the NRF52840 at one time and that's what I came up with for the mpconfigport.mk. I never did actually attempt the modification though because at the time, and for a long time, they were out of stock and I was really hesitant to hardware modify my 1 and only bluefruit sense board.
sorry if I wasn't clear: I have two fairly duplicate circuits: an official Pico and what is effectively a clone, both running 8.2.4 Pico CircuitPython. The clone shows flash writes to be 2x slower
same build?
No idea how much of a difference it would be for an RP2040 vs an NRF52 build, maybe it will help, dunno, worth a shot though.
the read performance depends on what boot2 is included in the binary
I would think it would just fail if the QSPI flash only used 2 lines. Maybe the clone uses a clone QSPI that is just slower under the cap.
I don't think CP exposes any of the info about the QSPI flash to the user. Though i've never looked too closely
oh yeah, the write performance of the qspi chip would matter too
same binary. thanks I've already been poking through the RP2040 datasheets. I was hoping there were some secret supervisor settings. I'm going to try poking at both boards with the Arduino SPIFlash flash_info to see if the JEDEC data reports anything different from the chip marking
ah, found an example
lets assume worst case, a dumb fat fs, with 512 byte blocks, and 4kb erase blocks
so every 512 byte write, involves a 4kb erase (45ms to 400ms)
and and 8 x 512 byte writes (0.4 to 3ms per page, 256 bytes per page, so 4.8 to 48ms)
best case, lets assume circuitpython can inteligently batch it into 4kb chunks
so thats between 2 and 20 writes per second, at 4096 bytes each
which is between 9142 and 82,248 bytes per second
these numbers ignore the spi bus itself, and getting the data into the buffers
@devout jolt what kind of figures are you seeing on both boards?
I don't have exact numbers, just doing time cp file CIRCUITPY, but on Pico copying about 1MB was 30 secs and on the clone it was 51 secs
34,952
20,560
bytes/sec for both
id say thats within the bounds for the page erase time
you would need to write some specialized code, to measure the flash performance, to get a better answer
https://github.com/raspberrypi/pico-examples/blob/master/flash/program/flash_program.c
this is an example program, that will erase and program areas
wonder if these are de-rated winbond parts haha
Pico has W25Q16JFUXIQ (2MB) and the clone has W25Q128JVSQ (16MB)
the datasheets show them to have identical timings
but how close to typical timing is it actually?
the perpetual question
let me take a stab at what i said above ^
so, ive got a https://www.sparkfun.com/products/retired/17717 i'm going to test on first
somebody forgot to label the 2 buttons
hey it's an RP2040-based design, so they're just following the RaspberryPi house standard of not labelling their board π«
but pico at least has 1 button, so there is no question on which is bootsel
fetching the compilers now...
but which pins are GND pins? Which pin is GP15?
thats all labeled
not where it's useful haha
yeah, they kinda messed up, putting it on the wrong side
oh, and since this board has 16mb, and i also have a pico
this is a good comparison to your case
i can also share my code with you, and then you can see what figures your board reports
now comes the harder part, which is in none of the examples
how much time passed between 2 points? lol
ah there, time_us_32()
pico_set_binary_type(benchmark no_flash) isnt doing its job
ah, i didnt erase it like i thought
basics are working
[root@amd-nixos:~]# cat /home/clever/apps/rpi/pico/pico-examples/build/benchmark/benchmark.uf2 > /dev/sdc
[root@amd-nixos:~]# cat /dev/ttyACM0
usb host detected!
single erase took 5,708,953
[Sat Aug 26 21:34:58 2023] usb 1-12.1: USB disconnect, device number 99
@devout jolt the uf2 file is configured to run from ram, so it loads faster and has zero impact on spi perf
it will erase a PICO_FLASH_SIZE_BYTES sized chunk (board config) of the spi chip
and then report how many uSec it took
then reset the rp2040, and with it erased, it goes into bootloader for another round
and its running the ROM_FUNC_FLASH_RANGE_ERASE function from the boot rom
so the entire erase is one atomic operation, no turning XIP back on every page
src/rp2_common/hardware_flash/include/hardware/flash.h:#define FLASH_BLOCK_SIZE (1u << 16)
and i think its erasing 64kb at once
yep, and it is using the 64kb "block erase d8" command
and that should take between 150 and 2000ms
[root@amd-nixos:~]# cat /dev/ttyACM0
usb host detected!
2 mb erase done in 32 blocks of 64 kb
171293 uSec per block
datasheet claims 150ms typ
i measured 171ms
with a sample-size of 1
Thanks Iβll try that when I get back to my bench
the current source, but its only measuring one thing
165738 uSec per block
on a second pass, it ran ~6ms faster
usb host detected!
single erase took 5332563
2 mb erase done in 32 blocks of 64 kb
166642 uSec per block
single erase took 5349178
2 mb erase done in 32 blocks of 64 kb
167161 uSec per block
single erase took 5279080
2 mb erase done in 32 blocks of 64 kb
164971 uSec per block
single erase took 5308220
2 mb erase done in 32 blocks of 64 kb
165881 uSec per block
single erase took 5259088
2 mb erase done in 32 blocks of 64 kb
164346 uSec per block
single erase took 5272410
2 mb erase done in 32 blocks of 64 kb
164762 uSec per block
single erase took 5262908
2 mb erase done in 32 blocks of 64 kb
164465 uSec per block
single erase took 5351905
2 mb erase done in 32 blocks of 64 kb
single erase took 5281835
2 mb erase done in 32 blocks of 64 kb
165057 uSec per block
single erase took 5296881
2 mb erase done in 32 blocks of 64 kb
165527 uSec per block
modified it to run 10 times
no clue why one report is missing a line
gist updated
single erase took 51991982 mb erase done in 32 blocks of 64 kb162474 uSec per blocksingle erase took 52690792 mb erase done in 32 blocks of 64 kb164658 uSec per block
i'm surprised at how easily the usb link corrupts
single 256 byte write, 598 uSec
single 256 byte write, 598 uSec
single 256 byte write, 598 uSecsingle 256 byte write, 598 uSecsingle 256 byte write, 598 uSec
single 256 byte write, 598 uSecsingle 256 byte write, 598 uSec
single 256 byte write, 598 uSec
single 256 byte write, 598 uSec
single 256 byte write, 598 uSec
it should take 400uSec to program a page typically
its taking 598 consistently
and a pre-built copy, if you dont have pico-sdk all setup
all of the above numbers, are on the sparkfun 16mb board, but only erasing the first 2mb
194702 uSec per block
198219 uSec per block
single 256 byte write, 562 uSec
single 256 byte write, 562 uSec
single 256 byte write, 562 uSec
and this is on one of the first pico's to come out
the 16mb chip erases faser
but the 2mb chip programs faster
Yep had a pico-sdk setup. Didn't look back here until I did a test. Getting 220834 uSec with gist version on clone
this is interesting thank you. On an Adafruit KB2040 (8MB) getting similar but slightly faster numbers around 206000 uSec
it may also vary within a single batch of the same spi chip
or between batches?
would need more testing
production quality variation
and maybe wear? it might repeatedly apply the erase pattern, until it fuly erases
yeah. I just pulled out a fresh official Pico from a bag and tested it: 226309 uSec per block
and thats even slower then every other test!
The RP2040 port lacks support for raw memory map access. Implementing the core memorymap module will provide access to RP2040 registers that are not otherwise available in CircuitPython, such as setting pad hysteresis. Let me know if this is desirable and I'll code a pull.
Currently, gzip decompression fails. I noticed when trying to decompress RESTful content bytes in my project that uses gzip for content-type that the headers are not read correctly and I get a failure message of -3.
I suspected I could get around this by slicing the byte array of the raw content. I came across [a comment](https://github.com/adafruit/circuitpython/pull/6069#issuecomment-1046090...
One problem with Pico W and I couldn't find answer:
When I create AP and then I want to stop it but it fails.
wifi.radio.start_ap("testname","testpasswd")
# Some tasks are happening here
wifi.radio.stop_ap()
And we get error:
NotImplementedError: Stopping AP is not supported.
How can I stop AP then?
The only "solution" was in stack overflow and it just said basic thing such as cutting off power and making sure no one is connected, which is in my case no one currely connected it.
What version are you using? https://github.com/adafruit/circuitpython/pull/8326 was just merged two days ago so you may need to grab the "Absolute Newest" from the circuitpython.org download page.
@wind kettle βοΈ
Thank you so much!
what is en_x_pirate in languages? π
It says "Arrr! Captain, we got a problem on ship" and then shows the exception? π
It changes the language and most of the strings to Pirate speak. It's fun on International Talk Like a Pirate Day.
Good day to everyone! I'm hitting a problem building MAIN for an RP2 target. "make BOARD=raspberry_pi_pico" fails due to a missing "genhdr/flash_info.h". Anyone seen this?
yup
Cool, so it's not my fat fingers. Any fix/workaround?
looks like a problem with the build scripts, 8.2.4 builds fine
OK, I don't see an issue on it, so I'll start one. Thanks!
there aren't that many commits in between
Yes, I'll see if I can find it. Looks like gen_stage2.py isn't getting run.
CircuitPython version
Current top of MAIN
Code/REPL
make V="steps commands rules" BOARD=raspberry_pi_pico
Behavior
supervisor/internal_flash.c:35:10: fatal error: genhdr/flash_info.h: No such file or directory
Description
No response
Additional information
Seems to be a problem in the port Makefile where it fails to run gen_stage2.py.
It was just disabled, possibly because of size considerations, but it's useful to be able to enable it explicitly for selected boards.
This requires some of the settings to use ?= instead of =, and fixing a bug in the traceback module, where the chain variable is unused if exception chaining is not enabled.
Looks like the chain bug was already fixed by someone else in the mean time.
Comparing MAIN with tag 8.2.4 there are significant changes to way that the qstr collection is built. On MAIN, py/makeqstrdefs.py runs first to generate genhdr/qstr.i.last, but it fails because supervisor/internal_flash.c includes genhdr/flash_info.h which has not been generated yet. So, this rule (or similar) in ports/raspberrypi/Makefile:
$(HEADER_BUILD)/flash_info.h: flash_info.h.jinja gen_stage2.py | $(HEADER_BUILD)/
$(STEPECHO) "GEN $<"
$(Q)$(PYTHON) gen_stage2.py $< $@ $(EXT...
Worked around the problem by making the include of genhdr/flash_info.h dependent on NO_QSTR like this:
#ifndef NO_QSTR
// Only include flash_info when not doing qstr extraction.
#include "genhdr/flash_info.h"
#endif
Not sure if this is most desirable fix, but let me know if it is and I'll make a pull.
@lone axle hihi if yr around, do you have the OSHWA API key
I am, and I do
Whats best way to send? mods channel?
@lone axle do you by chance have a script that like, gets all projects
we want to do some cool graphs showing project sources
i actually have the API key - sry π
I used this to pull everything out of OSHWA API:
import requests
import json
url = "https://certificationapi.oshwa.org/api/projects?types=electronics&q=Adafruit&limit=900"
f = open("env.json", 'r')
env_data = json.loads(f.read())
f.close()
token = env_data['token']
payload = {}
headers = {
'Content-Type': 'application/json',
'Authorization': f'Bearer {token}'
}
response = requests.request("GET", url, headers=headers, data=payload)
f_out = open('oshwa_data.json', "w")
f_out.write(response.text)
f_out.close()
#print(json.loads(response.text.encode('utf8')))
aha
@lone axle blesss u!
oh wait i need all all data
which has a higher qty than limit
but i can paginate
all good i found some code on learn
@lone axle ok i got i!
Nice! I'll keep an eye out for the graphs. I think you've got a good sized chunk of them!
This ensures that on linux no .Trash-1000 folder is created, storing deleted files.
The files will instead be sent to ~/.config/Trash.
This only covers deleted made by the user which has the uid 1000, but that's the default user uid.
Unless you are having many users on your system and you are a secondary user, you should have uid 1000.
It's not perfect, but better than not having it there.
All the tests do this: raising the class instead an instance. This is OK, per the docs:
https://docs.python.org/3/reference/simple_stmts.html?highlight=raise#the-raise-statement
(emphasis mine)
Otherwise,
raiseevaluates the first expression as the exception object. It must be either a subclass or an instance ofBaseException. **If it is a class, the e...
Even with almost no ram free, a simple "we receive display commands over uart / i2c / whatev" program can be used and makes some sense.
@jepler: your fix seems useful, but why was this not failing in the CI or locally before?
I don't know why it wasn't seen during CI but it reproduced locally with
make BOARD=raspberry_pi_pico clean && make BOARD=raspberry_pi_pico build-raspberry_pi_pico/genhdr/qstr.i.last
β¦eration
I investigated and found that this seems to be the best way to specify a file that must be generated before "qstr processing" can occur.
Closes #8337
We thought we were fixing this in the past by creating the .Trashes file (not folder) when CIRCUITPY is freshly formatted, as you can see in the source. So, I'm guessing that stopped working at some point?
I didn't know that! Sorry, and thanks, I learned something new about Python. I seem to remember it didn't used to be that way.
".Trashes" may be for some other operating system or environment, or it might be an outdated Linux usage. I wasn't able to establish for what OS this line was added. (some search excerpts seem to indicate it could have been MacOS)
Things that follow xdg specifications, which many Linux DEs try to do, use $topdir/.Trash-$uid, where $topdir is the mounting location of a filesystem (e.g., /users/<name>/CIRCUITPY). There's also a discussion of $topdir/.Trash/$uid but that likely doesn'...
.Trashes appears to be for secondary external drives on macOS, and contains folders for .Trash-1000, etc. Search on this page for more info: http://www.thexlab.com/faqs/trash.html
I have not got a chance to test this yet, but just wanted to leave my quick comment after looking it over.
I had left GZIP on the original as we were discussing better ways to include it. I do not see any downside to including this change to allow those who want to the ability to use it a bit easier.
Issue #6284 has some discussion about changes in micropython about uzlib and at some point it is worth looking at those and an overall plan for decompression in circuitpython. I just do not h...
All I am saying is that KDE doesn't care at all about .Trashes. Like, at all.
I don't know much on the topic though.
I think it would be best to leave .Trashes alone though.
This kind of issue is not gonna be reported or found easily (since it's all dotfiles).
Hi There:
I updated my Neuron board pin assignments a few weeks ago (with an approved pull request the master branch). I would also like to have those pin assignments (pins.c and mpconfigboard.h) files applied to the 8.2.X branch so that the firmware files on circuitpython.org match the current pin assignments for my board.
Thanks!
Successfully tested pull #8340 locally.
I am feeling like we need to comment these with whatever environment type they're for. Otherwise, we're left scratching our heads later.
Would you be willing to add a simple 1-liner comment that this is for Linux & a link to the xdg standards document I found related to this?
thanks!
This brings in the fix for RTD building
What about users who have a different uid than 1000?
Would you be willing to add a simple 1-liner comment
Sure thing. Should I also add a note about MacOS and .Trashes?
What about users who have a different uid than 1000?
I mean, >90% will have uid 1000.
If I add 1001 that will be probably >98%. But still..
We can keep adding more, but then we will make a million dotfiles.
The possible user uid's 1000-65k iirc.
There isn't a solution that covers all uids to my knowledge.
Tidied it up a bit, moving the indexing stuff in one spot and the trash in another, along with adding the comments.
Hi There:
I think (well hope!) I have the workflow this time. I've updated the pins.c and mpconfigboard.h files to reflect new pin assignments for the BrainBoardz Neuron and submitted this to 8.2.X branch. Specifically, I changed the pin assignments for SPI. This will ensure that 8.2.X firmware releases on circuitpython.org have the correct pin assignments for the current hardware configuration of my board. Thanks!
For a new CircuitPython source file, should I copy the MicroPython license header into the file and should microDev be the copyright asignee?
<@&356864093652516868> The weekly meeting will be held in two hours at 2pm EST / 11am PST. I look forward to hearing your hug reports and status updates. See you there! Notes doc for this week's meeting is here: https://docs.google.com/document/d/1j5Pv4_oJHyVMV9M9QQvvpCHj0E4yjOM3AaDDe58oDsU/edit?usp=sharing
Am I correct that the "In The Weeds" sections is for ideas and topics for discussion?
Correct anything that may be more then a status update can handle and a few minutes discussion may help give direction/clarity to
Thank you
I used this header in a file I submitted: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/gifio/OnDiskGif.h
Thanks Mark, I'll do it like that.
@devout jolt for flash debugging, I'd sniff the lines of the flash if you can. (I think pico is hard to sniff though unfortunately)
thanks and yeah too difficult π
Just noting, this is still an issue in the the 9.0 pre-alpha builds (9.0.0-alpha.1-13-gc395e1f9f).
I was reworking my wget and tried wget https://raw.githubusercontent.com/adafruit/circuitpython/029c912bf0f19062426922962deaf12d9785c5bc/supervisor/shared/filesystem.c to test how it coped with the filename.
Traceback (most recent call last):
File "adafruit_requests", line 1, in _get_socket
OSError: Failed SSL handshake
The above exception was the direct cause of the following ...
Yep, until the actual fix is decided on, if you want to use WiFi with the latest main, you need to manually replace lib/certificates/data/roots.pem with Dan's roots.pem file.
Where does the weekly CircuitPython meeting happen?
Right here in this channel and the recorded channel for voice
Thanks!
If you are writing a fresh file from scratch, you should provide your own name for the copyright data and the current year for the copyright year. If you are basing your work on existing work, then keep any existing copyright name & year and optionally add your own name. If you're taking code from another project, you'll need to make sure the license is one that we consider appropriate (mostly, we are not able to accept GPL but we can accept BSD, MIT, etc).
...or use:
context = ssl.create_default_context()
context.load_verify_locations()
with a CA string or .pem file
we just finished the internal meeting so adafruit people will be popping in very shortly! I'll brb π
(Damien George) MicroPython started life in early 2013 as an experiment, to see if it was possible to shrink a high-level language like Python down enough to run on very small devices. Ten years later MicroPython is a mature open-source project that is relied upon by a wide variety of users. In this talk I will discuss its history, my experien...
(Matt Trentini) MicroPython is great for hobbyists! You can control LEDs and motors, it's so easy! But you wouldn't use it for anything serious. Right? Surely not! It's too slow. You can't use all the features of a micro. It consumes too much power. You don't have control over memory.
Yeah, nah. You can't do serious embedded work with Mic...
can you just put =neopixel(0xff0000) in cell A1 to turn your neopixel red? oh darn, probably not.
"Circle of Fifths" search bring too much, so I will read this: https://learn.adafruit.com/circle-of-fifths-euclidean-synth-with-synthio-and-circuitpython
cgrover I want to see/hear this.
curious if you're using the standard (equal temperament) frequencies or have "correctly" applied good old integer ratios to a base tone so the intervals are all correct
FeatherWeatherFeatherWeather
somebody should do an example of that kind of thing
In music, just intonation or pure intonation is the tuning of musical intervals as whole number ratios (such as 3:2 or 4:3) of frequencies. An interval tuned in this way is said to be pure, and is called a just interval. Just intervals (and chords created by combining them) consist of tones from a single harmonic series of an implied fundamental...
I have a working backpack version for the I2S 3W amp breakout that was tested by JP (https://github.com/CedarGroveStudios/PCB_Reintegrator) . This newer but currently untested PCB version is a more flexible design that can connect via a simple PicoBlade speaker connector and ground wire (https://github.com/CedarGroveStudios/PCB_Reintegrator_DI).
Sure, it is not for "in factory" solution, but for first time user after flashing.
Guide only cover 1/3 of the board... the Adafruit one.
it would be good to have a place for simpletest files for the circuitpython repo, as opposed to libraries
It is a seed, I am planting it, the idea will grow. π
I wonder if there should be a place on circuitpython.org for a link to "the main documentation of using the board with circuitpython"
a basic any-board tester could check for common pin aliases for features (LED, NeoPixel, I2C scan, board.display, etc.)
for adafruit it would be a link to Learn; other manufacturers could link to other places
Sometimes the "manufacturer" is a single maker, or the board only exist as open hardware, but not something you can order.
Yes I like a button
[synthesizing @tannewt's remarks in the meeting as well as some info from the internal meeting]
The 8MB PSRAM uses additional pins because it supports "octal mode", in which 8 bits are transmitted every clock cycle. CircuitPython doesn't correctly protect these pins, which causes the "pin in use check" not to work.
If the check did work, it would not be possible to construct an SPI object using the pre-defined SPI pins because they overlap with the pins used by the PSRAM. (you'd get a "...
Maybe I can make a first simpletest_code.py for a random board in circuitpython repo.
Can we do import repl.py and have the same effect?
from go import *
on this idea from me as well. I end up naming my files with 1 letter names to reduce the amount I have to type for importing it inside of REPL.
The concept is important, not the filename suggested. π
I agree, it is just an idea
Should there be an issue for further discussion on that topic?
I suspect jeff will make a PR π
Thanks everyone
Thanks.
Thanks for hosting Paul. Hope everyone has a good week!
- For those who think they need it, there's a "user.py" module. This is not imported by default, but can be imported to run user-specific setup commands, ~/.pythonrc.py. [very old notes in python Misc/HISTORY file]
I may be mistaken that python ever automatically imported / ran a file before entering the repl
that's what happens when you carry too many decades of info in your head, sometimes you say stuff that's as wrong as chatgpt
using PYTHONSTARTUP: would only be available on boards that support settings.toml.
using a default filename: risk name collisions
Late to the party but I like the repl.py, as Foamyguy my files are named letter and numbers for easy importing.
repl.py output:
loaded repl.py
Traceback (most recent call last):
File "repl.py", line 8, in <module>
ZeroDivisionError: division by zero
Adafruit CircuitPython 8.2.0-94-gd6351b220e-dirty on 2023-08-28; Espressif-ESP32-S3-LCD-EV-Board with ESP32S3
>>> dir()
['I2C', 'I2S_SCK', 'SCK', 'SPI', 'I2S_SDO', 'TX', '__name__', 'I2S_WS', 'BACKLIGHT', 'RX', 'MISO', 'BUTTON', 'MOSI', 'SCL', 'TFT', 'SDA', 'board_id']
# content of repl.py
import storage
storage.remount('/', False)
del storage
from board import *
print("loaded repl.py")
1/0
yay the implementation was relatively simple
and if you don't have it you just get ```
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 8.2.0-94-gd6351b220e-dirty on 2023-08-28; Espressif-ESP32-S3-LCD-EV-Board with ESP32S3
If anyone gets a chance to merge my PR for the meeting notes, it's appreciated. Thanks! https://github.com/adafruit/adafruit-circuitpython-weekly-meeting/pull/131
@lone axle is a ninja. π
The overall RP2 memory map is interesting, with different access rules and restrictions for various sections of the memory map.
Memory-mapped I/O register write accesses are uniformly treated as 32-bit writes that ignore the low-order 2 bits of the address. Therefore, write accesses to these areas of the address map need to be restricted to a size of 32 bits with natural alignment.
If a write access to a field narrower than 32 bits within an I/O register is desired, RP2 implements atomi...
Does anyone happen know if or where the READTHEDOCS environment variable is documented? We use it in our docs conf.py file like this: https://github.com/adafruit/Adafruit_CircuitPython_MatrixPortal/blob/main/docs/conf.py#L120
RTD logs contain errors like this:
Configuration error:
There is a programmable error in your configuration file:
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/adafruit-circuitpython-lis3dh/envs/stable/lib/python3.11/site-packages/sphinx/config.py", line 358, in eval_config_file
exec(code, namespace) # NoQA: S102
^^^^^^^^^^^^^^^^^^^^^
File "/home/docs/checkouts/readthedocs.org/user_builds/adafruit-circuitpython-lis3dh/checkouts/stable/docs/conf.py", line 245, in <module>
'html_theme': html_theme,
^^^^^^^^^^
NameError: name 'html_theme' is not defined
and I'm wondering if that mechanism no longer works the same way which is making the logic of the if statement change and causing html_theme variable to not get created.
And now that I asked, the next link I tried contained the docs I was after πͺ https://docs.readthedocs.io/en/stable/reference/environment-variables.html#envvar-READTHEDOCS
@lone axle jas
@lone axle it only ever worked by coincidence. I fixed it here but the fix is only in 8.2.x and not in main: https://github.com/adafruit/circuitpython/pull/8322
GitHub
This is a speculative fix for the latest build failure on RTD: https://readthedocs.org/projects/circuitpython/builds/21689508/ which appears to be due to a change in RTD's "conf.py.tmpl&qu...
https://github.com/adafruit/circuitpython/pull/8342 is approved so I can go ahead and merge it, after which main's docs should build
oh wait it is merged .. did it not fix it?
seems to be fixed, and your curiousity about the environment variable is satisfied @lone axle ?
Ahhh, Thank you. I ran across it in a library, not the core. I think we may need to adopt a similar fix in the libraries.
Here's one of the failed builds for a library: https://readthedocs.org/projects/adafruit-circuitpython-lis3dh/builds/21742659/ same issue as you fixed from the core, and the conf.py file was similar.
Forgot to write a hug for Danh & RetiredWizard without whom I wouldn't have gotten the matrix portal s3 running the 9.0 alpha build. Don't want to tag now that the meeting is over... but they deserve a big hug from me for their guidance this week via github issues. β€οΈ
Yep. I think I could patch it across all the ones from the bundle. I'll try https://github.com/adafruit/Adafruit_CircuitPython_TestRepo individually to confirm the same fix works first.
I'd love to see this support added and am happy to review. I don't think we'll need more for atomic access since there are separate registers at a different address for them. Let's start with the existing API.
@RetiredWizard I think that's enough. If folks need more, they can use a regular pico. Will the pico build work on the pico w to disable wifi? I don't think it is worth having a pico w build where wifi interfacing doesn't work.
This has way more commits than it should. Did you accidentally update your main branch to something else? Generally, you should use a unique name for a branch to PR from.
@slender iron I'm sorry I think I really clouded this issue up. The current PR actually has Wi-Fi enabled and it works fine, to enable the DVI output you need user python code. To answer your question though yes loading the Pico firmware onto a Pico w and plugging into the base works fine except that Wi-Fi and the LED don't work
The new build gives you a Wi-Fi enabled board with the SD card and i2s pins to find in the board module
that's fine with me
@onyx hinge I was thinking we could add an exception you could throw to do it
it's probably ok to run repl.py in that case still
had a chance to re-review my rpi-zero pr? i believe i fixed the submodule stuff up
@slender iron can I message you now? (about atmel qtouch)
yup!
I think I just merged it
ah yep, merged
i also had an idea for another change
in theory, you can just build circuitpython ~3-4 times, for every pi model
put all of the kernels in the fat32
use config.txt conditionals, to select the right kernel at boot
Looks good to me! Thanks for the quick impl and doc update.
boom, now 1 disk image works on every supported pi model
@slender iron like PYTHONINSPECT / python -i? that'd be cool. requires more structural change to main.py though
Generally we like that board has board-specific pin names
but to do that, i would have to recursively run make BOARD=n for every supported n
the pizero and pizero2 have identical pin name/functions
I've never used inspect. I'm mainly thinking for those that want how MP works
ya, true. we do that already. thank you github for the CI time
it would also be using the pi4 board build, when on the pi4, so the import board would give pi4 data
where are the pin names defined in the port?
ah, found ports/broadcom/boards/raspberrypi_zero/pins.c
the only difference between the different rpi boards, is which gpio is the led
otherwise, those pins.c files are identical
Are the pin names in CP identical to the pin names if using Blinka on a Raspberry Pi running Linux?
The idea would be to run the same code with or without the Linux OS.
there are 5 unique files in there, but lets ignore the diodes_delight_piunora
i have no clue what it is, and it can remain a stand-alone image as before
lets also ignore the cm4, if your using that, you know what your doing, and will pick the right build
so that just leaves 3 unique variants
STATIC const mp_rom_map_elem_t board_global_dict_table[] = {
CIRCUITPYTHON_BOARD_DICT_STANDARD_ITEMS
// These match the names used in Blinka
all of them start with this
Piunora is a PCB in metro format where you plug a CM4.
ah
we are consistent with our one build per board model. I don't think we should change it
so its in the same category as the cm4, you should know what your doing, and just pick the right image
the only difference between those 3 variants, is the status LED, and a single stray newline
about the only benefit i can think of to changing it
would be that you can take a uSD card with circuitpython + code.py, and pop it into any supported model, and it just works
so you could migrate a project between pi's without having to reinstall
You can still do that
we just don't tell you
the build doesn't actually stop working on a different board
but the MMIO addresses differ between each, is it using device-tree, or hard-coded?
hard-coded in the peripherals sub-module, based on the compile-time BCM_VERSION == 2837 param
so the build would stop working when on the wrong model
Maybe just a warning if you use the wrong firmware?
because the MMIO addr is hard-coded, it cant do anything when on the wrong board
while we're having random ideas, some clarity about whether the board definition is by adafruit / other original manufacturer / community might help set expectations for "who will do something if it's not working"
OK, I'll stick with the existing API for now. Just thinking out loud about some might be nice tweaks.
At any rate, I will enforce alignment, write allowed, and size where required according to the RP2 address map area.
but, you could do:
[pi1]
kernel=circuitpy-zero.img
[pi0]
kernel=circuitpy-zero.img
[pi0w]
kernel=circuitpy-zerow.img
[pi02]
kernel=circuitpy-zero2w.img
[pi4]
kernel=circuitpy-pi4b.img
in config.txt
then it will dynamically select the right build at boot time
then you just generate a disk image with 4 builds of circuitpy
and this one SD card will now work on all of those, and the import board will match whatever you boot it on
Sorry, I have not use the broadcom port since a long time... but I guess the Pi still boot on the GPU and read the config file. Great.
That's fine if you want to do it. But I think there are more important things to do on the broadcom port
ugh
longs for usb host support on pi400
pi400 usb-host on the usb-a ports, needs pcie drivers first
usb-host on the usb-c port would be easier, but require some special docks or cutting up cables
I'm interested in the built in keyboard
yeah, that keyboard is on the xhci and pcie
Hi Scott.
Yes. I royally screwed that up! So this morning I made a separate
repository based on a fork of 8.2.X and updated just my updated board
files. I submitted a pull request on that and it went through. Sorry for
the mess-up on the first go.
Jeremy Littler
LEAD Emerging Technologies
The Creative School
Toronto Metropolitan University
416-979-5000 ext. 552222
RCC 353
On Mon, Aug 28, 2023 at 4:02β―PM Scott Shawcroft @.***>
wrote:
...
I didn't say my wish was easy π
that is something i want to get to at some point
i did also see a ticket on tinyusb, about OTG support
the dwc has host and device support, and there is a control register to query the OTG_ID pin
so, you could be switching roles without a reboot
but, then how would tinyusb and circuitpython handle that?
we've opted not to really support that because then we lose the device workflow
device and host concurrently is more interesting
but what if i boot on a pi-1b, where device is impossible
then you want host-only
until a user plugs an OTG adapter into the zero, and expects a usb keyboard to work
ya, it'd be cool if it worked
both tasks are low priority for me so do whichever interests you
I'm happy to review on the CP side
simpler option would be to build with both host and device support, as-if you where going to be running concurrently
and then just have one of the init routines fail, based on hw state
and now half the stack is dead, until you reboot
Thanks! Not a big issue with having to wait for a new 8.2.X release. Just happy to have the correct pin assignments going forward.
then you dont have to deal with resetting all of the state every time you role change
ports/raspberrypi/boards/raspberry_pi_pico_w/pins.c: { MP_ROM_QSTR(MP_QSTR_LED), MP_ROM_PTR(&pin_CYW0) },
ports/raspberrypi/boards/raspberry_pi_pico_w/mpconfigboard.h:#define MICROPY_HW_LED_STATUS (&pin_CYW0)
ports/raspberrypi/peripherals/pins.h:extern const mcu_pin_obj_t pin_CYW0;
trying to figure out where this object is defined, but i dont see a clear answer...
ports/raspberrypi/peripherals/pins.c: const mcu_pin_obj_t pin_CYW##p_number = { \
oh, thats why, macro's
on some of the pi models, the status led is behind an i2c gpio expander, which your supposed to control via the mailbox to the VPU
another crazy side-project i want to try at some point
an arm-less circuitpython build, on the rpi
oh, some of the esp32 chips, where there was a core in the wifi, and a master core, did they run 2 circuirtpy's or just one?
I think just one.
ah
On a board that has an ESP32 as co-processor for running Nina-FW to have wifi, you could imagin running CP on that ESP32, but I think no one tried that.
id say its less of a GPU, and more just another cpu core, that comes up first
it only got called the GPU, because it was initially running the drivers for the 2d/3d hw
but i have a compiler for that cpu core, and in theory, i could run circuitpython directly on it
in such a setup, start.elf would be circuitpython, and the arm core is optional, and could be off, running something else, or running a second circuitpython build
the pi-zero(w) has a dual-core VPU running at 500mhz, and a single-core arm running at 1ghz
tannewt wanted to work on co-processor and having a way to implement that in CP. Some people wanted to have two CP in RP2040, one for each core, but in CP the second core is sometimes used for special purpose like USB Host or DVI, so that was never done.
the rp2040 is also rather low on ram, so that would waste some of it
So if we decide to include the Pico W version of this board I think this PR is ready.
There's not enough memory to bring up the DVI display when the board boots, but it can be brought up with user code and both the WiFi and display function, albeit with only 40-50K of available memory.
The base board adds an SD card and I2S audio and both this PR and the existing PIco version firmware name those and the DVI pins appropriately.
facepalm
minicom was open in another window
it kept stealing lines of text
If you remove the space before "waveshare_rp2040...", I think pre-commit will be happy :grin:
"0x2E8A:0x1020": ["waveshare_rp2040_plus_4mb", "waveshare_rp2040_plus_16mb"],
anyone know of the best flash settings for esp modules?
I don't think this is a duplicate of #8288 because this board uses 2MB PSRAM which is in quad mode (not octal.)
Here is the notes document for next TUESDAY's CircuitPython Weekly meeting due to the Labor Day holiday in the US. 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/1P6AwndR-BBldT7jIzLpO72B9nSmnz7VJexO96ttI2O0/edit?usp=sharing
Access Google Docs with a personal Google account or Google Workspace account (for business use).
ah, i was wondering if i missed it
[adafruit/circuitpython] Pull request opened: #8345 Forbidden pins are now correctly "in use" on ESP
This removes duplicate code to make debug UART pins in use via never reset. It is done through forbidden pins automatically now.
Fixes #8288
Hey folks .. left field question π On my test jigs, when I'm viewing the output I am seeing when booting and testing with CP, I see this on boot \x1b]0;\xf0\x9f\x90\x8dWi-Fi: off | code.py | 8.2.3\x1b\\\x1b]0;\xf0\x9f\x90\x8dWi-Fi: No IP | code.py | 8.2.3 and I'm assuming the leading bytes are colour codes/text formatting?
If so, any idea how I can make them work in macOS terminal using ZSH without installing a theme manager?
I see these in the Mu editor as well. Iβve been curious myself
And in Putty
Oh, are they emojis? wow, ok, and even harder challenge in default macOS terminal.
If you see the codes in Mu then time to update Mu? Mu added emoji support about 6 months ago.
what serial emulator are you using ? It might be one that automatically converts those to \xnn
(I have no issue displaying emojis using tio in the mac terminal)
I think there was an issue with that happening with the 8.0 betas. Then they fixed it in Mu. I think it's more for web workflow now?
of it might be that they are cut off, so invalid utf codes
I'm just using vanilla macOS terminal. I've found running terminal themes on macOS to bog things down quite a lot.
no but what serial app ?
yeah in Mu i think they removed the blinka icon by truncating it but i think it still exists for the web workflow?
like screen ?
None, just ssh in termninal
