#circuitpython-dev
1 messages Β· Page 301 of 1
@tulip sleet So Adafruit CircuitPython Crickit uses the C-level seesaw firmware? Do I understand that correctly? Considering filing an issue on seesaw for quadrature support as per https://github.com/adafruit/Adafruit_CircuitPython_Crickit/issues/13 but I want to make sure I'm in the right place.
@ionic elk nice work! they both worked
π
the h7 should be faster than the f7 right?
@idle owl The C++ code in question lives at https://github.com/adafruit/seesaw
But it also depends on which pins can be chosen. They have to be ones that have a TC, but on seesaw it looks like those are already dedicated to an internal function (the DC motor drive)
ok, h7 is faster. 76ms vs 179 for an empty for loop 20k long
@onyx hinge Hmm. I'll not file an issue then since I don't know what I'm talking about.
When's the last time we pulled from upstream MicroPython? What version?
@idle owl I appreciate you are trying to help a community member with their idea!
@idle owl our docs say "This release is based on MicroPython 1.9.4 @25ae98f" (5.2.0)
er the release note says
Still ok. Thanks.
hrm, with this test the f405 beats the f767
@slender iron just to mention, you can remove these two caveats from the next release notes:
ulab can give erroneous results when sorting 2D arrays
ulab can give erroneous results with expressions like a[a<1]
import time
print("hello world!")
start = time.monotonic_ns()
for i in range(20000):
pass
print(time.monotonic_ns() - start)
@onyx hinge kk
Please add the objcopy flags for the hex too, then it'll be good to go!
The F76/7 devices have 128k DTCM and 16k ITCM. Please add a TODO to add it. Totally ok to follow up with it.

You'll want MCU_SECTIONS for the hex below too I think.
Hi hi, please push a new commit. The CI had trouble last night and it needs a push. Maybe add yourself as the copyright for these files?
Yeah I realized I missed this this morning but wanted to get this PR wrapped up. I'll do two follow up PRs ASAP, one for this and one for the documentation.
@slender iron by the way, I was hoping to ask for your opinion on a hobby project sometime, if you've got a minute
@ionic elk I have time now
Is pulseio healthy in 5.x on nrf? I am seeing some difficult to explain occasional variations when I use it to repeatedly charge a capacitor. I'd normally suspect a loose connection but I'm not nudging it at all...
The STM32F405 isn't in the support matrix?
@crimson ferry its in work... https://github.com/adafruit/circuitpython/pull/2598
Thanks!
any idea what it's waiting for?
the proposed changes to the CIRCUITPY_----_BUILD mechanics.
to summarize the why not now? the builder doesn't recognize MINIMAL build.
@crimson ferry I'm working on that tomorrow actually
π
I need to put in new build flags and stuff
k, cool
but it's my next up alongside a reworked readme
π
@idle owl you can file an issue even if we can't do it; it would be aspirational
@slender iron the hobby project I wanted to ask you about was my fork of UncannyEyes - I'm trying to figure out what the best platform to port it to would be
would it be better if I asked that in help with arduino or some other room though?
@ionic elk are you going to adjust the doc builder part too (if needed)? not calling dibs, just wondering if i'll need to put it on my docket...
yes
I just mean in terms of Hardware. I don't know atmel too well, so my biggest question is how hard it is to get SPI DMA running on Arduino vs the raw atmel libraries
we have pretty thin wrappers for it in circuitpython
I'd like to actually have the whole thing be Circuitpython but it'd be too slow unless I made it a module
@slender iron I was out of the house and thought I got a message from you about not merging something (I didn't have my glasses), but now I can't find it. Did you send something?
@tulip sleet check your dm
Ignore my earlier comment, it's unlikely to be pulseio, I think it's probably just something like usb activity adding inter statement delays
I'm finding myself in need of reading lots of samples at a set rate or highest rate of the ADC on the nRF52840. This came up in the discussion (on SAMD21) on https://forums.adafruit.com/viewtopic.php?f=60&t=142006 - has there been any work in this area?
I try to check PWM with Version 5.1.0.
But Failed.
Would You Please check PWM output with Teensy 4.0 ?
Thank you very much^^
Every One Cheer Up !!!
I've been baking in different fonts with the CIRCUITPY_DISPLAY_FONT parameter in the board mkconfigboard.mk files. Certain BDF fonts will fail upon running this script during build.
Arial.zip or knxt.bdf in the repo as well.
python3 gen_display_resources.py --font fonts/Arial.bdf --output_c_file foo.c
Traceback (most recent call last):
File "gen_display_resources.py", line 84, in
b[overall_bit // 8] |=...
@kevinjwalters can you download 2 file of cdc driver below replace (after removed the .txt) to lib/tinyusb/src/class/cdc . I tested here and it seems to be fine. Once confirmed I will make an PR to update tinyusb submodule. It may take a bit of time since there are ~500 commits comparing with current one used by cpy. Though we need to update anyway for the esp32-s2 support.
cdc_device.c.txt
[cdc_device.h.txt](htt...
At this point, Actions reports '80 successful, 43 queued, and 1 in progress checks'. build-arm (circuitplayground_bluefruit) started 19h 17m 4s ago and has been running the step 'build' for 19h 15m 35s. The log for the build step can't be viewed.
I'm going to cancel and re-run, and if that doesn't break it loose, I'll push a nonessential change. Hopefully one of those will get this on the road again.
Hi @onyx hinge I have the following adafruit board https://www.adafruit.com/product/3211 and a 64x64 matrix that worked fine (with the recommended hardware modification) on a Raspberry Pi 3b. Do you think I should be able to drive that matrix with your Protomatter/RGBMatrix code? Did you have a chance to work with a 64x64 matrix (they are "special", I believe they use one more pin/GPIO)? Will you write a learn guide to explain the steps (the electrical powering of those matrix is the most frightening for me, and that's why that Adafruit Bonnet and instruction really helped getting me started). Thanks.
@thorny jay I haven't used the 64x64 matrix. The code should support the 5 address lines A through E, but the existing featherwing for feather m4 express would need to be modified to actually bring the signal to the header.
Would love to get your feedback if you try it
Surely readline() "rtype" is string not int as stated (and not bytes as some might expect).
Also it is not totally unambiguous what happens on a timeout so it would help to clarify in docs that on a timeout it does NOT return with what it has read so far, rather it leaves all that in the buffer ready for a future read and returns nothing.
Likewise clarify that if timeout=0 but there is no newline it DOES return what it has read so far (NOT None).
At least this is what I think it doe...
Hi,
The fix looks good to me. I ran 100 tests on a CircuitPlayground
Express
with no errors. Thanks!
-Dave
On Fri, Apr 17, 2020 at 4:36 AM Ha Thach notifications@github.com wrote:
@kevinjwalters https://github.com/kevinjwalters can you download 2 file
of cdc driver below replace (after removed the .txt) to
lib/tinyusb/src/class/cdc . I tested here and it seems to be fine. Once
confirmed I will make an PR to update tinyusb submodule. It may take ...
Hi, thanks for noticing this. I tested `UART.readline() with 5.2.0:
readline() does not return a string, it returns a bytes. It returns None if there's nothing to read,. regardless of timeout = or > 0. It will return everything in the UART buffer when the timeout is reached, except that if there's a \n in the buffer, it will return only up to and including the next\n.
It should probably be noted that newline means exactly that; \n, and not \r. When testing I noted that t...
heya @onyx hinge is it possible to play independent waveforms using the DACs on a an M4's A0 and A1 pins? When I try I get an error about the DAC already being in use
@pastel panther looks like a no, unfortunately.
https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/common-hal/audioio/AudioOut.c#L128
@raven canopy wub wub
I think it does support stereo so maybe I can hack that to set each channel with separate data
audiomixer, though? doesn't support balance (yet), but you could channel the source waves...
π
yes, it does support stereo
@onyx hinge is the restriction to make the memory handling easier or something?
@pastel panther I don't really know, the samd audio was largely by Scott, before I came on board.
ah, ok thankx
#copoutanswers
doesn't make it the wrong answer. π
@slender iron any more testing you want to see from the H7/F7 port or should I go ahead and merge?
@ionic elk merge away. I was just waiting for CI
@slender iron it seems that Dan's review didn't get dismissed by the update, did we change a setting? I'm no longer able to merge
All stylistic. Massive amount of work, great!
π
@slender iron Thanks! Working on docs now. If you have any direction for what you'd like me to start looking at in the i.mx port after that though let me know - I'll start brushing up on the datasheets/libraries today and early next week.
@ionic elk https://github.com/adafruit/circuitpython/issues?q=is%3Aopen+is%3Aissue+label%3Amimxrt10xx
@hathach I'm starting to look at ESP32-S2 today again and will likely do the TinyUSB update as part of that.
@tulip sleet any updates from github about the stalls?
@dhalbert anything I need to do here or is this a website issue?
@hathach I'm starting to look at ESP32-S2 today again and will likely do the TinyUSB update as part of that.
That is great, don't forget you also need to define the USBIRQ and call the tud_init_handler() there as well.
@tannewt the only stm32f7 boards' i have is openmv cam https://www.adafruit.com/product/4478 and a 32blit, can i test with either?
Hi, The fix looks good to me. I ran 100 tests on a CircuitPlayground Express with no errors. Thanks! -Dave
I am glad that fix the issue, if anyone is curious about the bug, It is fixed by PR by majbthrd in this PR to usb stack here https://github.com/hathach/tinyusb/pull/260
@ladyada was going to add the H7 cam next week
@tannewt the only stm32f7 boards' i have is openmv cam https://www.adafruit.com/product/4478 and a 32blit, can i test with either?
I tested on the two Nucleo boards. I have a 32blit and would be keen to get it going there. I should focus on ESP32-S2 though.
@hathach Thanks for the fix. It'll take me a while to look at this. I've never compiled up CircuitPython and I've got a feeling it requires a few later version of things, like gcc, than I currently have.
lol agree. @tannewt keep esp32s2'ing :) @hierophect lemme know when the cam is ready, ill grab one from the office and we can try it out!
@hathach Thanks for the fix. It'll take me a while to look at this. I've never compiled up CircuitPython and I've got a feeling it requires a few later version of things, like gcc, than I currently have.
Which board you are testing with, I can upload the uf2
I'm sure you've seen the notifications but this is worth a re-test after the fix https://github.com/hathach/tinyusb/pull/260 for #1639 is picked up by CircuitPython.
We need a low level swdio module that does the lowest level of SWD using bitbanging. That way we'll be able to use CircuitPython to recover another board that had it's bootloader busted.
SWD overview is here: https://github.com/MarkDing/swd_programing_sram
This is also useful but we don't need the SPI speed yet: https://medium.com/@ly.lee/openocd-on-raspberry-pi-better-with-swd-on-spi-7dea9caeb590
We'll only use it to re-flash the uf2 bootloader.
I'm mainly using the Adafruit CLUE at the moment and I've seen it twice while fiddling around on REPL, I also have Circuit Playground Bluefruit and Circuit Playground Express which I used fairly frequently. I can test on any of them.
@gentle bronze I'm updating tinyusb in circuitpython now
@kevinjwalters Here you, I uploaded all 3 uf2 you mentioned
clue-firmware.uf2.txt
cpb-firmware.uf2.txt
cpx-firmware.uf2.txt
@tannewt note that the H750 on the MicroBlit would require a little extra work since it only has 128k of flash, we'd have to do something like the i.mx has for loading code.
@slender iron nobanswer to ticket. Official forum responder said to try cancel and rerun
The STM32F7s have ITCM and DTCM banks capable of being used with Circuitpython, but they aren't currently set up for use since they require extra steps in the reset handler to appropriately set MPU definitions. These should be added to speed up F7 performance.
My apologies, I am still using old version CircuitPython because v4.0 broke some things. But I have some new Teensy M0 boards on order, hence I was reading up on what changes I needed to make to suit v5.2. I guess I should have been more patient for them to arrive and tested first!
I think we agree that rtype isn't and shouldn't be "int". I assumed it would be string because it lacked a notice along the lines of the one attached to write(buf) -
New in CircuitPython 4.0: buf must...
@lone axle and @tulip sleet Your suggestion to look at ble_uart_echo_* and Bluefruit Connect is perfect. I took the Nordic UARTService code and just replaced the 3 UUID (main, RX and TX) by those in use by my device. And now I can send command and get response. π
We need to change tools/build_board_info.py so that it uploads the uf2 for the board. I.e. Add
"meowbit_v121": UF2,
to extension_by_board. That will upload the .uf2 instead of the .bin.
esp32s2 branch: https://github.com/tannewt/circuitpython/tree/esp32s2
Rebased and "make translate"d again.
TIL that this error doesn't stop a github actions/checkout@v2 in its tracks: ##[error]fatal: unable to access 'https://github.com/v923z/micropython-ulab/': Failed to connect to github.com port 443: Operation timed out ##[error]fatal: clone of 'https://github.com/v923z/micropython-ulab' into submodule path '/Users/runner/runners/2.169.0/work/circuitpython/circuitpython/extmod/ulab' failed
In my own fork's actions, 9bfe6b7 (framebufferio: update copyright information) succeeded instead of hanging: https://github.com/jepler/circuitpython/actions/runs/80760861 -- however, for circuitpython it was hung and I cancelled it.
@slender iron think long living classes could be turned off for a specific board?
@marble hornet The mechanism could be overriden in the functions that take a boolean saying whether an object is long-lived or not. But what would you gain? (π€ soon so we can discuss later)
i'll ping you tomorrow then. sleep well
Testing scope: 5.0.0 and 5.1.0 releases on Feather NRF52840 Express
I'm using a 240x240 IPS display, and my display layout consists of
- 4 groups
- 23 labels (total)
- four lines (total)
- one Bitmap
I'm loading three fonts like this:
font_arial = bitmap_font.load_font("/fonts/Arial.bdf")
font_arial_16 = bitmap_font.load_font("/fonts/Arial-16.bdf")
font_helvetica_bold_16 = bitmap_font.load_font("/fonts/Helvetica-Bold-16.bdf")
# ...
As an experiment, I hacked up the code to allow baking in more than one font to create custom terminalio.FONT and terminalio.FONT2
I baked in Arial.bdf and Helvetica-Bold-16.bdf. Arial-16 only had two labels so I changed them to FONT2.
The resulting load time is 4 seconds, of which 3 is the bitmap logo.
As an experiment, I hacked up the code to allow baking in more than one font to create custom terminalio.FONT and terminalio.FONT2
I baked in Arial.bdf and Helvetica-Bold-16.bdf. Arial-16 only had two labels so I changed them to FONT2.
The resulting load time is 4 seconds, of which 3 is the bitmap logo.
https://github.com/k3wals/circuitpython/commit/3d3e6b16f0ed024003b16280a06c7aaa3d1a1193
[patch_circuitpython5.1.0_2fonts_hack.txt](https://github.com/adafruit/circuitpython...
@gentle bronze I'm updating tinyusb in circuitpython now
@slender iron kk, tag me when you create PR for update. I will double check it π
I'm porting CircuitPython to this board and require a VID/PID.
I'm using stm32f746g_disco as the board-id.
thats awesome - thank you :)
stm32f746g_disco VID 0x239A PID 0x009B # bootloader
PID 0x809B # arduino
PID 0x809C # circuitpython
nucleo_f746zg VID 0x239A PID 0x009D # bootloader
PID 0x809D # arduino
PID 0x809E # circuitpython
Very similar to the nucleo_f767zi, just a different flash size, tested on a real board with various python scripts, all ran fine.
What are practical options for databases on Circuitpython? Is btree it?
Someone here knows how the serial console works? It outputs fine over the USB-CDC...but I'm looking at getting it to output on the VCP 'debug' serial on a STM32 nucleo board.
Update: I've fixed it π
@meager fog are you familiar with what might cause raytac nrf52840 's bluetooth to stop working? did this ever happen to you when developing the boards?
fona library is here, its very early but can be tested if folks want to try it out!
https://github.com/adafruit/Adafruit_CircuitPython_FONA
Please do not underestimate the level of experience that a "beginner" has when they start out with Circuitpython. Some of us have been programming with Python for several years, but have not yet ventured into some of the more advanced features. I would put myself in that category, having written quite a lot of robot control software in Python. I think I would be somewhere in the intermediate level, where I am just now starting to need some of the more advanced features Python offers. Some of ...
@tannewt Again, this PR build hung. I've made another non-essential change.
tested with feather m4 + 32x64 matrix!
@tannewt actions finally finished this time!
@ionic elk We should talk sometime...I've ported C.Py to nucleo_f746g which works fine...and have now got it working on disco_f746zg. Thing is...there is a lot of changes that would break existing ports, so we need to move things either more generic, or less specific depending on what it is.
Would it make any sense to have a #help-with-micropython channel, or do we want to steer people toward MicroPython.org resources? Some folks come here for help, typically in a general channel or the CircuitPython channel. There are many Adafruit Learn guides for MicroPython on Adafruit hardware. Adafruit Forum is combined CircuitPython and MicroPython, though almost all posts these days are CircuitPython. I don't have a strong preference, just trying to get a general sense of direction.
We should just point people to the Micropython forums.
@crimson ferry our MicroPython guides are mostly historical. We don't try to do extensive micropython support. We can answer simple MicroPython q's, but their forums are better for regular users. Often the q is some kind of comparison of CPy vs MPy.
Thanks, will do, kind of what I figured.
@slender iron could I ask you a PacketBuffer q, or is this not a good time?
@tulip sleet I have 10 mins
i'm trying to use a PacketBuffer on the peripheral side as a server, to queue writes to a fixed size characteristic (i.e., not notify, just straight writes). This may be the first time this is being doen, though I thoguht it was done for HID or MIDI.
common_hal_bleio_packet_buffer_get_packet_size() returns 0 if there's no connection, which is not what I'd expect (I'd expect max_length), and the code subtracts the att_overhead from the returned packet size, which is also not what I'd expect.
ok, I see, I guess it tries to return the min(mtu, max_length), and then adjusts for the overhead. I thought it would just return the max_length if < mtu
how would it write when it's the server?
no, the client writes to the characteristic (it's the tone service for adafruit services, so it's sending a tone to play)
i.e. the bluefruit playground app writes to the char
i was htinking the packet size was the max size of the written data, but it doesn't seem to be that
in this case, the tone is a fixed lenght, 6 bytes
notifications are limited by the mtu
yah, but I needed the packet size before any connection was set up. I mean, I can get it in another way (by the struct format string), but i'm misunderstanding what packet_size means, I think
I thought it meant the max size of the data of a single packet, which is usually way smaller than mtu
I think it's fine to return max length
it should be whichever is longer since packet length is used to validate the buffer passed in
i was using it to allocate the buf initially, but if it's mtu-size, that's unnecessarily huge
not the PacketBuffer buf, the writeinto() buffer
when sending it should check against the smallest
ya
so maybe I'll PR a fix for common_hal_bleio_packet_buffer_get_packet_size(), since it usually is going to return mtu size rather than actual char size (if char size is smaller).
this is all trying to debug some buffer overflow
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "ble_adafruit_circuitplayground_bluefruit.py", line 68, in <module>
File "adafruit_ble_adafruit/tone_service.py", line 81, in tone
ValueError: Buffer too short by 5376 bytes
obviously some length is wrong here. It's taking some data values as the length, I think
ok, tnx, I'll proceed with the debugging. I wasn't completely misunderstanding, which is what I was worried about
Β―_(γ)_/Β―
good night!
Im working to add circuitpython support to https://github.com/Anderson69s/HolyIoT_NRF52840
@onyx hinge I'm getting a compilation error from the tip of master in ulab, which is odd, because it should work:
In file included from ../../py/obj.h:32,
from ../../extmod/ulab/code/poly.c:12:
../../extmod/ulab/code/poly.c: In function 'poly_polyfit':
../../py/misc.h:89:43: error: 'y' may be used uninitialized in this function [-Werror=maybe-uninitialized]
89 | #define m_del(type, ptr, num) ((void)(num), m_free(ptr))
| ^
../../extmod/ulab/code/poly.c:88:26: note: 'y' was declared here
88 | mp_float_t *x, *XT, *y, *prod;
| ^
../../extmod/ulab/code/poly.c:127:46: error: 'x' may be used uninitialized in this function [-Werror=maybe-uninitialized]
127 | XT[i+j*leny] = XT[i+(j-1)*leny]*x[i];
| ^
cc1: all warnings being treated as errors
this is in nrf
Submodule path '../../extmod/ulab': checked out 'a746bd8e0953853056ee405e2fa02c8ebca4fb79'
/home/halbert/bin/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc
hmm, this only happens if I compiled with DEBUG
I'll make an issue
On the tip of master, and only in the nrf port, and only if DEBUG=1:
In file included from ../../py/obj.h:32,
from ../../extmod/ulab/code/poly.c:12:
../../extmod/ulab/code/poly.c: In function 'poly_polyfit':
../../py/misc.h:89:43: error: 'y' may be used uninitialized in this function [-Werror=maybe-uninitialized]
89 | #define m_del(type, ptr, num) ((void)(num), m_free(ptr))
| ^
../../extmod/ulab/code/poly.c:...
@slender iron I found some issues with using ringbuf.h for PacketBuffer, can discuss tomw
i wonder if this is causing other issues, if you are using it for MIDI, etc.
@slender iron think long living classes could be turned off for a specific board?
@marble hornet I don't think it should be turned off. If there is a bug, then we should fix it.
@slender iron I agree. Fix bugs when they are found. Do not turn features off because of a bug.
I have not seen any bugs. Besides the in-list Id issue. I would want to disable it for just one board, the GUI imports and destroys classes often and over. Do you think it would be advantageous to disable long living for that board?
Those tests sure take a while to run...
STM32f746g_Disco: Working β
@marble hornet why are you destroying imported classes? Is it because they are just used for constructing something and then aren't needed after that?
@tulip sleet I am destroying them when I get rid of the whole module
@marble hornet why would the user program want to unimport a module? I know you've been trying this for a while, but what is the use case?
The user would t. My βsystemβ would. The watch can switch between apps. Like open one then go home then open a different. The apps loaded in memory can change. Each app is a class in a module. To prevent memory errors, when memory is low the oldest imported module is deleted. (Using the above sys.modules and careful handling of anything that has a reference to it )
Does that answer your question?
yes, I remember that. This is difficult enough to do in regular Python. Does a strategy of restarting the whole thing after remembering what do to after restart not work out? Would it help if there was a non-flash way to remember state between VM instantiations? I imagine the only strong reason for this is lack of RAM.
yes that is for this scope. inter-VMinstance would probably help and "boot-up" time of the system is > 1 second. although freezing in some of the source code will speed up "boot-up" time. via importing it is much faster
it is working right now except for the couple hundred bytes. i just realized i did the x y problem switch.
@marble hornet did you make .mpy files of the source to speed up loading?
not yet i've still been editing a lot of the files, i'll give it a shot to estimate.
when reporting the issue I should have said , i think theres an error when garbage collecting/ unimporting a module. after removing/garbage collecting all the instances and references to a module and its content a few hundred bytes still stick around.
using .mpy will make the loading a lot faster, and will reduce some garbage
nice! here ya go :)
Holyiot nrf52840 VID 0x239A PID 0x009F # bootloader
PID 0x809F # arduino
PID 0x80A0 # circuitpython
Thanks for this PR! Looks good, thanks for going the extra mile in exploring the SoC additions.
However, note that a lot of these files need to be re-generated instead of copied and pasted - there are quite a lot of differences between the F767 and the F746 regarding pin-to-peripheral mapping, which would lead to some very confusing user problems if ignored. I've included some instructions below on how to generate them below, but if you have any problems I'm happy to help.
The F7x6 line does not have a double precision floating point unit, so it shouldn't be included here.
@tannewt could we get a new PID for this board?
Please use the existing convention for this file, BOARD_OSC_DIV, since it is already defined in mpconfigboard.h.
a touch faster
Additionally, we don't usually add copyright attribution for single-line additions to fold new chips into the build process, since it'd lead to ever-expanding lists of attribution for macros that are often factored out anyway - please reserve attribution for files you add or significantly rework.
Please add attribution to these files when re-generated
I'm interested in this too. Here's some previous forums discussions where this has come up:
- ADC / DAC very slow (on a Feather M4 express)
- Is there a blocking analog read and what is sample rate?
I'm not sure if it's related but I've noticed some demand for performant circular buffers discussed in [CircularBuffer equivalent in CircuitPython?](https://forums.adafruit....
I think we need to move the clock code outside of this, various boards use totally different clock settings....the nucleo_f7 uses the internal Osc, whereas the disco_f7 has an external 25mhz one.
@slender iron there were two issues with using ringbuf.h:
- Due to the way it does buffer-full checking, it only stores
n-1values when allocated as sizen. The calling code was not aware of this and was trying to fill up the buffer with exactlynbytes. - When the buffer was written to when full, it started overwriting the oldest bytes. This is not so terrible for UART and CharacteristicBuffer, but it played havoc with PacketBuffer, because the length bytes would get overwritten.
I am doing a PR that will clean this up, and will just drop overflow bytes instead of overwriting the oldest bytes. I don't think this is really an issue for UART, it's still terrible anyway, but we can discuss.
In general, clock settings tend to differ on the Family level (F4, F7, H7, etc) but within that the only setting we need to change is PLLM, which is typically set to equal the oscillator frequency/1,000,000. That's the purpose of BOARD_OSC_DIV, so there's a clear reference to the oscillator speed in mpconfigboard.h.
This section could use the hal-conf macros instead, but that requires more specific HAL familiarity and I've been avoiding doing so until there's a more compelling reason.
I would like to add more control over the ADC, such as specifying oversampling, averaging (if available), maybe even differential mode, etc.
The native nRF52840 ADC accuracy is 12 bits. You can set it to 14 bits, but that just shifts the result over if oversampling is not enabled. But with oversampling, you can get 14 real bits.
That's fine if the OSC is internal, but on some boards it's not.
For the F7_DISCO port, I'll do a more in-depth look into this. There are quite a few things I've come across that would need to be more configurable by board.
I'm not sure what you mean. We do not use the internal OSC on any board.
Sorry, my mistake...but RCC_OscInitStruct.HSEState is different on some boards...
We assume all boards have an external oscillator which we match with BOARD_OSC_DIV, leaving the rest of the settings the same so that USB and the peripherals receive a consistent clock speed. You can see an example of a 25MHz oscillator setup in stm32f411ce-blackpill
I discovered that the settings were wrong when testing the Nucleo_f746 board, when copying more than 16kb of files it crashed C.Py.
@lucid solar regarding your mention of RCC_OscInitStruct.HSEState, do you have a board in mind that does not use a high speed external oscillator?
Well, no...but I'm about to comment something else on the PR π
Yes, that's fine...but the PLLN and PLLQ need to be different if we use the external SRAM on the disco board, which will be needed in the future to get the display to work. It can't be the max 216mhz speed, but max 200mhz for the external SRAM.
Good catch, missed that during the transition to the dual-bank system. Thanks for the PR.
Interesting. We don't have support for external SRAM yet, but that's a good heads up. If you want to submit a PR for that I'd be happy to take a look. It'd probably be something that could be handled with a one-time mpconfigboard.h flag. It might be worth checking out the F412 as well and see if it has a similar requirement.
@ionic elk no external SRAM on F412_disco....but I've seen some on other boards...I don't have any right now yet.
You'd have to check with @slender iron about where that'd be in terms of priority. It's probably not something I'll be able to revisit for a while but I'm sure he'd be open to PRs.
I'll resolve this...will make an issue about custom clock settings which we can look at later.
@ionic elk peripherals/stm32f7/f767xx/periph.h
Any reason the mcu_tim_banks is not extern, and the mcu_tim_pin_list is not defined there?
CircuitPython Weekly Meeting in ~40 minutes. Everyone is encouraged to attend! Please add your status updates and hug reports to the notes doc even if you'll be attending - it's super helpful! Thanks and hope to talk to you soon! <@&356864093652516868> https://docs.google.com/document/d/1YIp-LKPdIzsN2LN4yRo4FzxzTTnLuFeDOJPboQKDVhc/edit
Folks, if you have any CircuitPython/MicroPython/Python projects, news, etc. for the CircuitPython Newsletter, please send to me at anneb@adafruit.com as soon as possible as I'm finalizing things this afternoon. Thanks!
I've just put some graphs of the nRF52840's 12 bit mode in action in CircuitPython 5.2.0 in Changing ADC to over-sampling mode for higher resolution?.
I rebased and pushed again as there was a failed check...but I don't think it was 'my fault' anyway.
Good afternoon all you wonderful coders -- happily lurking today 
@idle owl i won't be able to make meeting today
@tidal kiln Thanks for letting me know. Hope all is well.
Happy, healthy, and lurking today. Hope everyone is doing well!
Lurking, but not leering π
If you'll be lurking, add it to the notes or let me know in here. Got you, Mr. Certainly, cater, cgrover, duewester
Text only
@lucid solar will you walk to talk during hug reports or status updates, or are you just listening (lurking) today?
@idle owl Not going to the meeting either, and did not provide notes . I have a few hug report, but I can provide them next week. And I cannot really talk about my current CP related project.
I can just lurk....My mic doesn't work at the moment anyway π
@thorny jay Thanks for the update. No worries. Hope to see you next week.
@lucid solar You can type your hug reports and status updates in this channel as well if you would like to participate without a mic.
Yes I can'
You can also listen in by joining the voice channel even if you are not going to talk.
Hello hello back at you
Scott + Water = wet keyboard
Hello @idle owl
lurking
I have one of these in case water spills: https://www.amazon.com/gp/product/B074DTL449
In anticipation of global warming issues, I'll be wearing my stillsuit.
When I was on subs in the Navy, if you came even near a control panel with liquid they knock you away.
Man.... double the volume slider seems like its 4x as loud lol
lurking today
@timber mango noted, thanks
lurking
Adafruit Industries, Essential service and business: Critical Manufacturing, NYC β Executive Order 202.6
https://adafruit.com/covid
How to place an essential, COVID-19 related order at Adafruit
https://adafruit.com/covidorders
...this sunday we're testing out a new pr for adding support for 'hub75' style rgb matricies to circuitpython. we're also honoring prof john conway, who was an amazing mathematician who recently passed away. conways game of life uses simple rules on a matrix of data to create ...
Thanks Charles
I was just admiring the new leaves on the trees across the street. π³
lurking, sorry
i blame the Discord client crashing! π
π
Lurking (and late)
i was merely the messenger. π
π€
heh, im over here switchless
w00t! nice job @lucid solar
@lucid solar an impressive debut
Thanks 
RosiePi - a physical test platform for CircuitPython. Demo utilizes a Raspberry Pi 3B+, running Ubuntu Server 19.10. There is no CircuitPython board connected in this demo, for brevity. With a board connected, RosiePi will build the CircuitPython firmware at the commit specifi...
@lucid solar I added you to the circuitpythonistas role so you get notified about meeting stuff
@raven canopy it might have been the pin I picked
if it is pin related, we can handle that better than just pushing out zeroes. π
Join Scott as he starts the ESP32-S2 port of CircuitPython.
Adafruit Industries, Essential service and business: Critical Manufacturing, NYC β Executive Order 202.6
https://adafruit.com/covid
How to place an essential, COVID-19 related order at Adafruit
https://adafruit.com...
Animal Crossing? Enjoying being in debt? π
I see you're digging up these puns π
how are we not further discussing Jeff's mention of the RNG LEEK?
π
[I turned on a software audio monitor of my mic and the lag makes me have a ton of trouble talking. I'm going to turn it off right after this]
@slender iron whoops posted it just to you yeah I put it on show and tell last week
cute as promised
@onyx hinge that's why I like the blue yeti. it pipes audio back with no lag I can tell
Which mic are you using @onyx hinge ?
@modern wing today I'm using the built in mic on some gamer headphones, HyperX brand
Great day. Be Safe to all.
@slender iron I'm sure considering some upgrades to my conferencing equipment maybe we can talk some more about what you recommend.
Thanks everyone
Thank you everyone, and stay awesome π
Heading AFK, thanks all!
Have a good week, all -- the dog is pacing -- need to go for a walk π
@onyx hinge There's a sale at B&H right now for some AT gear: https://www.bhphotovideo.com/c/buy/audio-technica-large-diaphragm-usb-mics/ci/46964
I use the AT2020usb (not plus), and I'm very happy with it. No need for a pre-amp or cloudlifter.
Shop B&H's in stock, large inventory for fast shipping, great service and everyday low prices on Audio-Technica Large Diaphragm & USB Microphones. For more info, please call 800-947-4415
I remember opening a serial session via Putty, with a brief panic when I got no output. Turns out that I didn't even plug in the cable to my laptop nor the device....it was sitting in my bag.
It happens to all of us at one point π
Animal Crossing turnips are literally doing better than real-world oil right now. π’οΈ
samd51-ish
it's M4 and the same clock speed
I grabbed both the discovery and nucleo from digikey π
want me to?
sure π
This is expected?
Adafruit CircuitPython 5.2.0 on 2020-04-09; Adafruit PyPortal with samd51j20
>>> lines = 'line 1\nline2'
>>> lines.splitlines()
['line 1', 'line2']
but
Adafruit CircuitPython 5.2.0 on 2020-04-09; Feather STM32F405 Express with STM32F405RG
>>> lines = 'line 1\nline2'
>>> lines.splitlines()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'splitlines'
i would guess some of the MICROPY_ flags haven't been tweaked in the STM port/boards.
Some string methods are in one but not the other. And vice versa.
Should all ports support identical language features? If so, I can file an issue, but I'm not sure how to find all of the differences beyond string exhaustively.
I've been writing a CMSIS-DAP debugger app on top of Zephyr...so I have quite a bit of knowledge of this. How do you think it should work? A python lib/script that they just copy over MSC to the 'host' device and that connects to the 'target' device to program it?
ya it would be heavily based on/perhaps even wrapper of https://github.com/adafruit/Adafruit_DAP which does buffers and fuses. then you can read/write from disk if ya like
@crimson ferry the STMs are still a little young I think. and we have various things turned off at the MICROPY_ level even on M0 (Gemma, Trinket). not sure it requires an issue, as it will likely be worked out as the STM port matures. then again, an issue never hurts! #NonAnswerAnswersAreHelpful
@slender iron Scott, do you have two minutes?
chatting with someone else now
OK.
I can do a quick text answer
@raven canopy Maybe I'll just give it some time. rtc is another thing., not currently supported.
https://github.com/micropython/micropython/commit/30840ebc9925bb8ef025dbc2d5982b1bfeb75f1b brings in warnings, which mess up ulab. What would I have to do to shut it up?
Warnings like these: https://github.com/v923z/micropython-ulab/issues/102
These are actually errors, that's the snag.
@slender iron Scott, I think, I have found the cause of the error.
@onyx hinge Jeff, https://github.com/micropython/micropython/commit/f31f9a8b70db03cbcbcf39b493f959d0e284962a changed the treatment of floats in micropython, and that messed up ulab. I have implemented a fix in https://github.com/v923z/micropython-ulab/pull/104, and the question is, whether it is still OK in circuitpython, or we have to patch it up.
@lapis hemlock I didn't actually check if it builds but we have both mp_obj_new_int_from_float and MICROPY_FLOAT_C_FUN so it shouldn't be too far off
I'm not likely to have time to look into it in detail this week
I'm not likely to have time to look into it in detail this week
@onyx hinge It compiles on github now. Would it be OK, if I merged it as it is, and we can modify it later, if you run into difficulties incircuitpython.
that is fine by me
OK, I'll do that. Thanks for the feedback!
You can ignore the review request, that was accidental.
your changes won't stop circuitpython from building, because we have to make a pull request to update the ulab submodule first, and we'll see any problem then.
okay, I do appreciate you keeping me in the loop
Thanks for spotting the error in polyfit! I could now pull in your modifications.
U can start with this fragment:
`
import board
import busio
import digitalio
import time
from array import array
import gc
class DMX():
def init(self, max_channels):
# First byte is always 0, 512 after that is the 512 channels
self.dmx_message = array('B', [0] * (max_channels+1))
self.dmx_uart = digitalio.DigitalInOut(board.TX)
self.dmx_uart.direction = digitalio.Direction.OUTPUT
self.dmx_uart.value = 1
def set_channel...
Hi hi, load_font does not load the glyphs into memory because it would load a bunch it doesn't need. load_glyphs is a way to do one linear search of the font file for all characters of interest.
Passing the font to a label will cause each new glyph to be loaded independently which is really slow because it is a linear search through a text file for each glyph. I recommend doing load_glyphs to speed things up.
Another way to speed things up would be using a file format that we could jump...
Can this be closed? I see a PR has been merged that seems to fix this.
Yup! Thanks @k0d. Fixed by #2756
CI isn't working so I'll just merge.
@k0d I think swdio would just be SWD primitives that are time sensitive. On top of that we can write Python logic to change behavior based on the chip and flash setup.
I'm not sure what to do about the CI actions. But, I was able to build this and test with Pew Pew M4. All colors are appearing normal for me now. Thank you deshipu!
This is expected?
Adafruit CircuitPython 5.2.0 on 2020-04-09; Adafruit PyPortal with samd51j20 >>> lines = 'line 1\nline2' >>> lines.splitlines() ['line 1', 'line2']but
Adafruit CircuitPython 5.2.0 on 2020-04-09; Feather STM32F405 Express with STM32F405RG >>> lines = 'line 1\nline2' >>> lines.splitlines() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'str' object has no attribute 'splitlines'
@crimson ferry https://circuitpython.readthedocs.io/en/5.0.x/docs/library/index.html#omitted-functions-in-the-string-library guess this is why....but we should be able to enable it.
@lucid solar ya, looks like a build config issue
The one thing I do not like about my ItsyBitsy M4 is the reset button. It is almost level with the board and is difficult to press, especially if I need to "double click" it.
@lucid solar Thanks, appreciate the link π
@lucid solar @crimson ferry @slender iron It sounds like this is part of what I'm already working on, which is the adjustment of build flags for the docs. STM32 has some redundant build flags to avoid FULL_BUILD that should all basically just get removed
with minor exceptions which is what I've been working on
@ionic elk Thanks, is rtc one of the things that will pop into the rebuild or does that need development?
rtc will need some love after my lower_power branch is merged in
since it starts using the RTC for time keeping
Is there a new bootloader for some boards? I seem to remember something about this.
For M4s, yes, they're on the circuitpython.org download pages
OK, got it, thank you.
Is there any blog/tutorial on how to use raspberry pi as SWD programmer? I am especially looking to re-program particle xenon board to be used with CircuitPython but don't have a SWD programmer, I read rpi can do SWD, so is it possible to flash bootloader on xenon using rpi?
Hey guys, newb here. Anyone know of the best method for reading/editing a .mpy file?
@tidal garden .mpy files are bytecode, you'll want to find the .py version. If it's a CircuitPython library from the bundle, they can be found on Adafruit's Github https://github.com/adafruit
Yup, all of that is quite possible in vanilla CircuitPython, just a takes bunch of onerous state to maintain and careful registration of your sensors in loop() (of course there are near-infinite ways to do this).
If you had asyncio from the usual Python library or something like existing clever MicroPython implementations you could organize each sensor as its own mini almost-realtime progr...
This patchset adds support for nRF52833, including various modifications required to reduce memory and flash usage:
- Making rgbmatrix and framebufferio optional
- Making I2C, UART, and SPI optional
- Making neopixel optional
- Allowing configuration of the SoftRadio memory region
- Allowing configuration of the SoftRadio memory settings
- Allowing the bootloader size to be conditionally set
I'm a little concerned about 7d810e3c4b168a015dfc491910d22e8869ef0adc which was necessary, ...
Right now, debug symbols are only turned on when compiling with DEBUG=1. I ran a test where I built the image twice: Once with -ggdb3 and once with (i.e. adding a space to ensure both were built from dirty git repos).
The resulting file was 8 bytes larger over 228384 bytes, and much of the resulting binary was identical. I suspect there may be other conflating factors including the order in which symbols are generated.
Is there a reason circuitpython isn't normally built with ...
My prior "experiment" utilizing load_glyphs must have been incomplete because I see a reduction in speed.
2x fonts with just load_fonts: 17 seconds
2x fonts with load_fonts and load_glyphs: 5 seconds
2x fonts baked into UF2: 1 second
What's special about the fonts baked into the firmware image? Aren't those also copied from flash to ram at some point? Why does the display element drawing go from 5 seconds to 1 second?
There isn't really an issue here since I'm happy with th...
I was able to suppress the terminal output to a display by commenting the following lines:
//supervisor_start_terminal(width, height);
within:
- shared-module/displayio/Display.c
- shared-module/displayio/display_core.c
It would be convenient to disable the terminal display output in bo...
Followed the guide at https://learn.adafruit.com/building-circuitpython/build-circuitpython to the letter and get what seems like a a good build output :
pixel@RYZEN3500U:~/circuitpython/ports/atmel-samd$ make BOARD=feather_m4_express
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
137512 bytes free in flash firmware space out of 499712 byt...
To enable easier debugging whilst developing, it could be good to have some kind of Makefile targets to flash the firmware and setup debugging etc. For now I'm using the following and setting the OPENOCD_FLAGS in the mpconfigboard.mk file.
flash: $(BUILD)/firmware.elf
@openocd $(OPENOCD_FLAGS) -c "program $< reset" -c "shutdown"
openocd:
@openocd $(OPENOCD_FLAGS)
debug:
@$(CROSS_COMPILE)gdb -ex "target extended-remote :3333" $(BUILD)/firmware.elf
DO NOT MERGE
@hierophect Can you take a look at this and give your comments, specifically on the clocks.c changes. I'm not sure how you'd like to have this.
It's based on the code I did for the nucleo board, this PR include that commit. I'll rebase on top of master when the other PR is merged.
Could you attach the .uf2 here? You may need to zip it up first.
What version of gcc are you using?
What does git status say? (I want to know which commit you're compiling.)
My commit seems to have broken Github (and these very tall print statements from black are going to take some getting used to)
@tidal garden @crimson ferry The .py versions are available on https://circuitpython.org/libraries - the "Bundle Version py" is the .py versions of every lib. At least when GitHub is working.
@idle owl thank you!
@tidal garden The .mpy normally come from a bundle and the VERSIONS file in the zip bundle will tell you which version you have if you need to match them up perfectly.
@obsidian compass it's definitely possible. I'm not sure of the process though. I think openocd is involved
anyone have an ili9341 handy? https://forums.adafruit.com/viewtopic.php?f=60&t=164561
@slender iron I've uploaded a test firmware for the ili9341 issue...if it doesn't work for him still, then I can try with a different board and the ili9341 display (I don't have the feather_m4_express)
did you manage to replicate the issue?
I don't have the board to test it...but at least I know I've made the firmware with the right steps.
@slender iron we're making 5.3.0-rc.0 from master right?
that was my plan. the ili9341 bug above could be an issue
@obsidian compass https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi
I'll read back
@k3wals What is your reason for this?
Do you need a test? I have a Feather M4 and ili9341 / 2.4" FeatherWing... Mark's UF2 + code.txt (both from forum)?
@crimson ferry I think testing with the latest github is what we're after
@crimson ferry that'd be helpful!
OK, give me a few
he said, despite being only half-way up to speed
thanks!
I wanted to chime in and say we've encountered @ATMakersBill's failure mode countless times with students building solar and battery powered projects.
Maybe I can frame it in a different light:
- regardless how you get there, recovering from safe mode requires user intervention
I think we need an ability to dictate safe mode behavior without hard-coding temporary fixes into main.c (for example).
I'll get started drafting release notes right now anyhow
π
@slender iron who can add 5.2.x and soon 5.3.x docs on RTD?
pixel@RYZEN3500U:~/circuitpython$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pixel@RYZEN3500U:~/circuitpython$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
[firmware.zip](https:...
Do we have a 5.x branch?
I don't think so
I'm not sure we should have a 5.x branch (yet). in 4.x it just confused things about whether to use 4.1.x or 4.x
Feather M4 + 2.4" FeatherWing (ILI9341) + latest S3 ...a4d86b9.uf2 + forum code.py = safe mode [5.2.0 UF2 is fine]
what does arm-none-eabi-gcc --version show?
#2685 only adds light sleep during time.sleep. We should add a new mechanic for sleeping until an alarm.
An alarm can be anything a microcontroller supports during sleep such as RTC alarm, pin change interrupt and comparator. The alarms should be in separate modules so that the microcontrollers can support different ones.
Then, one sleep_until_alarm() function can take any number of alarms. It will return the object that woke it up.
I've touched displayio indirectly for rgbmatrix, seems like I should take a look at it then
pixel@RYZEN3500U:~/circuitpython$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thank you @dhalbert for the review!
- [ ] I'll migrate the chip-specific stuff to the features struct and touch base again to verify variable names are appropriate.
- [ ] I'll build and test on a couple different boards with QSPI chips
After we have #2795 we'll have the mechanic for waking on a variety of sources.
We should add the ability to set what alarms should cause a reload when the user code is finished. This function should validate that the alarms can be run at the lowest power setting.
All RAM and program state can be lost in this sleep state. So, we also need a way to read the wake up cause from user code. CircuitPython should also start up faster when woken by an alarm by skipping things like the safe mode...
@crimson ferry can you try this, see if it crashes
I'd like to make sure this is namespaced to the tool such as openocd_debug because I use JLink instead of openocd.
@maholli That is a good way to put it! I just filed #2795 and #2796 related to more low power work. The latter also needs a way to provide a start reason to user code. That could help the user's safe mode code too.
does mp_raise_RuntimeError cause CPY to go to safe mode?
@lucid solar same behavior
@lucid solar it shouldn't
I don't seem to have any ili9341. I wonder if I can run that code without HW connected.
@onyx hinge I bet you can
@lucid solar safe mode is triggered by reset_into_safe_mode
@lucid solar still safe mode with ...1c8c.uf2
@crimson ferry https://adafruit-circuit-python.s3.amazonaws.com/bin/feather_m4_express/en_US/adafruit-circuitpython-feather_m4_express-en_US-20200414-ada102d.uf2 << love the git hash for this one
@slender iron I am really looking forward to your low power stuff. This will be great for robots too! π
π if only I could get it checked in
I got ValueError: Unsupported display bus type then a moment later dropped to safe mode
this is with some random "protomatter in progress" commit, which reinforces the idea it may be due to my changes.
That is weird. Display only code should not care whether a display is actually connected or not.
@tulip sleet want to review https://github.com/adafruit/circuitpython/pull/2789 ? it looks good to me
Of course, it is nice to know whether a display controller is present or not.
No, I think @jepler has wanted this too.
I do. Also, the step of always running 'strip' after linking circuitpython needs to be removed.
self=self@entry=0x20001d80 <displays+192>, brightness=brightness@entry=1)
at ../../shared-module/displayio/Display.c:162
162 self->updating_backlight = true;
(gdb) p self->core->bus
$4 = (mp_obj_t) 0x0
``` well that's clearly not going to work out π π¦
Baked in fonts aren't loaded into memory. They are objects in flash that are readily available.
I assume the 5 seconds is from load_glyphs which is doing a lot of text parsing. Our goal was using a wider variety of fonts, not to do it quickly. :-)
I'll close this issue because I think it's a library issue and not core CircuitPython. Thanks for the investigation!
@lucid solar Boom. Of course, the "ada" firmware works π
@onyx hinge Yeah, it does seem like the 'bus' thing is the issue. commit 09dc46a98480 seems to be where it broke. (Now I'm going to help my wife...back later)
Thanks @lucid solar I agree with your finding!
When allocate_display_bus_or_raise was factored out, the assignment of the bus's Python type was lost. Restore it.
This would have affected displays of any type other than RGBMatrix, when they were created dynamically. Boards with displays configured in flash were unaffected.
Testing performed: ran the code from https://forums.adafruit.com/viewtopic.php?f=60&t=164561 on a Metro M4 Express (no display attached)
Closes: #2792
hooray for our community, I'm glad we didn't ship a release candidate with this bug.
@onyx hinge looking now
The make the device a bit more product like for demo use. Don't need the verbose info to non-technical user.
I think I'm going to replace the bitmap_data with a static image with text such as "Contact XYZ and cycle power". Perhaps show a more intelligent error code if possible.
(not sure if this is the best venue?)
I'm trying to get CIrcuitPython running on the wonderfully tiny Itaca uChip boards.Β Those boards come with an Arduino Bossa-compatible bootloader.Β I don't see a UF2 bootloader availalble for uChip, but I'm fine with keeping the existing bootloader.
My understanding is installing CircuitPython with Bossa requires .bin files.Β But only .uf2 files are availab...
Confirmed building okay now. Many thanks for such a fantastic response.
i'll be back in ~ 1h to check on the status of things and presumably continue on to blog & forum posts.
Automated website update for release 5.3.0-rc.0 by Blinka.
New boards:
- nfc_copy_cat
- nucleo_h743zi_2
- nucleo_f767zi
I'll probably schedule the blog post for tomorrow, as it'll be getting late
This is now hidden. @NightSkySK please submit a PR if you want it shown to the world. Closing for now.
This is now hidden. @TG-Techie please submit a PR if you want it shown to the world. Closing for now.
@stuck elbow any ideas for slimming down the pewpew m4 build? somehow my sleep work is making it larger
@slender iron it's mostly the graphics for the menu program and the pew emulator, I include them in the firmware because I don't want them to use RAM
@slender iron it already has the analogio disabled, that should have freed a lot of space?
I want to rewrite the pew emulator to not need external graphics, but I don't really have much usable time for this recently
I'm only failing the DE and zh builds
can you tweak that code inlining stuff in the makefile?
otherwise, I suppose you could disable AUDIOMIXER for those languages only?
I don't think any game uses it at the moment
that reminds me .. assuming I didn't see it here, this is possibly relevant: https://github.com/google/bloaty
forum announce made, blog post schedule for tomorrow AM ET. thanks y'all!
w00t 1872 bytes free now
\o/
@onyx hinge I just merged master into my branch, and I'm still getting that ulabuninitialized variable error I reported a couple of days ago when compiling DEBUG. Is there a backport from 5.2.x that needs to be done to master?
@tulip sleet oops I didn't pull request to update ulab submodule
halbert@salmonx:~/repos/circuitpython/extmod/ulab$ git status
HEAD detached at a746bd8
nothing to commit, working tree clean
is the ulab commit
I'm on mobile, can you file a bug in circuitpython?
sure, but that's not in the rc, right?
It's not fixed in the rc
@jepler Per our discord conversation, this is just a reminder to pull in the ulab change to fix this.
Yes there were 3 new boards and 2 aren't on cIrcuitpython-org yet.
Thank you for this fragment, it is super helpful for me to try and wrap my head around how to get DMX working with Circuitpython!
Is it possible to include a binary module in circuitpython?
I have an AES module I've written, and right now I add it to shared-module and shared-bindings. I'm not sure if anyone else would find this AES module useful, so I'm considering just carrying it locally.
But it requires modifying py/circuitpy_mpconfig.mk and py/circuitpy_defns.mk.
Would anyone else be interested in this AES module? Or could I carry it in the board port without needing to modify files in py/?
@half geyser your AES module is written with C is that right?
@lone axle Yes, it's https://github.com/kokke/tiny-AES-c/blob/master/aes.c
The actual patch I have to add AES support is at https://github.com/simmel-project/circuitpython/commit/15aa364be7a63ee80cad564f4711d1c8e8e2119f
It passes the NIST tests at least!
@half geyser I don't believe there is currently a way to use C modules (or any binaries made from them) by just including the files on the device. They must be "baked in" to the system I think. If you had a python implementation of the AES module then you could include it as a file on the device in the libs folder and use it within your code.
ringbufusage inPacketBufferformerly would wrap around and overwrite an older packet on overflow, including its length field, which would cause a bad packet. Now an overflow simply drops the excess packet, preserving the older packets. (This is the bug that this PR is fixing.)- In various UART implementations,
ringbufused to overwrite the oldest data with newer data if there was an overflow. Now excess new characters are simply dropped. Per @jepler, this is how Linux works, and i...
Is there a way to "bake in" modules by appending them to e.g. the mpconfigboard.mk and/or mpconfigboard.h files? I can't see any modules that do that -- most seem to simply override various common-hal files.
Also if you had a python implementation of it, there is a "frozen" file that is made from the .py file it's called .mpy and the tool that makes them is mpy-cross.
they are all conditionalized with CIRCUITPY_whatever
I'm not sure what you mean by "appending", you mean just listing the sources? We don't do that; we use the make ifdefs and turn things on and off
@tulip sleet: I made a conditional CIRCUITPY_AES that I check against, which is how I'm able to get it to build.
But there's no concept of PORT_MODULES or BOARD_MODULES in the same way that there is a SHARED_MODULES, is there?
no, they'd just be in common-hal, if they were port-specific
That does seem like a good policy. It prevents board- and port-level fragmentation.
_bleio is like that, only exists in nrf, so it's port-specific (mostly), but controlled as if it's for all prots
yes, our intention is to make the ports as uniform as possible
this is not micropython's philosophy, which is to expose capabilities of a port in the interest of increased functionality for that port, even if it differs from others
Would there be any interest in an AES module? I'm still not sure if it's necessary for my usecase. I suspect it is, which is why I did the port.
it doesn't hurt! and it may be handy for some network stuff? We can always just leave it off
It might end up being called _aes.
we'd add an underscore if we didn't want to guarantee the API across minor versions. If there's a wrapper library, that's fine. That's why it's _bleio
Ah, that's the significance of it! I thought that referred to the fact that it was a low-level library. Gotcha.
One more question: Is there any SPI flash memory API?
Right now I'm using internal memory for the filesystem, and I want to use SPI flash as a database. Reads and writes are infrequent, so I don't want to do XIP.
From what I can see, you can either have internal flash or external XIP SPI. Is there any way to have block-level access to the SPI, or should I just write SPI wrappers in Python to manually manage the flash?
we have microcontroller.nvm for simple bytearray access, but it's not block-level. i wrote a simple consecutive-logging db for bonding information in _bleio, but that's not visible to python
sorry, I misread your question, you meant the external flash
there is block-level access for SD flash that's used via python.
we actually want to rewrite that in C, because it's a big problem it's python calling C calling python
I ran into the logging db from _bleio when my firmware pointers were incorrect. Circuitpython really gets unhappy when parts of its text section get erased π
That does look like a good approach, though! A logging db is exactly what I had in mind.
https://github.com/adafruit/Adafruit_CircuitPython_SD this style was copied from micropython
i'm sorry i messed up the calculations of the regions; i was going to look at your fixes. I had to move things around a couple of times and it sounds like I forgot to fix the arithmetic.
It's okay! I just wasn't sure if I got it right. It's not a well-exercised code path.
it is -really- simple. There are fancier logging db's in the nrf SDK
My big fear was that I mess it up for someone else.
i will double-check it; i didn't get a chance to review that PR
hathach uses LittleFS for storing the bonding info in the Arduino nRF code. That looked interesting too, but it was more work to port it than I wanted
Okay, adafruit_sdcard looks like it does state management in python.
Ah, I see that the C code inside spiflash.c just calls out to common_hal_busio_spi. So maybe it's not so bad to do everything in python.
the problem we were having is displayio reading data for the display from the sd card, and also other stuff going on: https://github.com/adafruit/circuitpython/issues/2417
If I'm using the internal flash filesystem, there's absolutely no utility in defining EXTERNAL_FLASH_DEVICES is there?
right, you don't need it; take a look at the pca10059 board files, for isntance
This is good information.
And what about the code generator? I don't see CIRCUITPY_ENABLE_MPY_NATIVE enabled for many ports. Does it offer much benefit?
it's maybe twice as fast in some cases, but it makes the code bigger. we don't have room on the M0 ports for that. Our inclination is to code stuff that needs to be really fast as a native module
Nice to know it offers some benefit at least.
see https://github.com/adafruit/circuitpython/issues/1248 , which has some discussion, and PR #2271
Well, this'll be fun. Now that we have the basic port done, I will need to work on some of the audio stuff. Unfortunately the PCB is designed such that it needs an I2S input and PWM output. Which is the opposite of what the nrf port currently has. At least there's a starting point. And PWM output should be simple.
? for audio ? we are doing PWM audio output on the Circuit Playground Bluefruit already
mic is PDMIn
Oh! I was looking at the common-hal/audiobusio/ directory and I only saw I2SOut and PDMIn. I didn't see common-hal/audiopwmio.
we split it up because it wasn't a "bus". It is a bit confusing
Is there support yet for complimentary PWM? This board has the speaker hooked up to two PWM channels with the plan to drive one signal as a differential pair for 2x the output power.
nothing like that, I think; we had only our own boards in mind π
Thanks for the information! It's good to get a sense of what exists and what doesn't. And this has answered a lot of questions I've had over the past week.
feel free to ask scott or jeff or me any time
It really was a quick and relatively painless board bringup. You've put together a really great ecosystem overall.
thank you; we generate so many boards ourselves at such a pace that we really have to avoid too much special-casing
we really appreciate all the work you have put into it too; we really enjoy getting a larger and larger community
The single subjob build failure is bogus: it's a job failure fetching dependencies.
It's late, but I'll submit a PR to fix this tomorrow, assuming it looks good to others.
@xobs I think this should be
#define CIRCUITPY_FIRMWARE_SIZE (CIRCUITPY_BLE_CONFIG_START_ADDR - CIRCUITPY_FIRMWARE_START_ADDR)
because of the order of regions here:
https://github.com/adafruit/circuitpython/blob/51dbe9109fb6a474fe7f4cf4e3766e27ba0b34b5/ports/nrf/boards/common.template.ld#L8-L18
The original calculation is wrong because it didn't account for FLASH_BLE_CONFIG and FLASH_NVM, but the change doesn't account for the size of FLASH_NVM (which maybe is empty in yo...
Thanks for the review. Yes, FLASH_NVM is 0 in my port, which is why I didn't run into the problem. Thanks for taking a look.
thanks; I decided I would sleep better if I filed the PR now :)
@xobs thanks for informal review in https://github.com/adafruit/circuitpython/pull/2789#discussion_r412663778.
CIRCUITPY_FIRMWARE_SIZE needs to be calculated based on the start address of the region just above it.
https://github.com/adafruit/circuitpython/blob/51dbe9109fb6a474fe7f4cf4e3766e27ba0b34b5/ports/nrf/boards/common.template.ld#L8-L18
The original calculation before #2789 is wrong because it didn't account for FLASH_BLE_CONFIG and FLASH_NVM, but the #2789 change didn't ac...
@dhalbert we may need to upgrade the SD to v7 for nrf52833. S140 v6 is written before 833 is released

@xobs hmm, did you run into issues with SD v6.1.1?
I haven't run into any issues yet, though all I've done is run the scanning demo from Adafruit. Is there a Bluetooth regression suite I could run? I have one PCA10100 (nrf52833) and two PCA10059 (nrf52840) boards in my possession.
No test suite that I know of!
I'll look into updating to 7.0.1. It compiles, at least.
I'll do some testing and open a PR that adds 7.0.1 and bumps nrf52833 to use 7.0.1 instead of 6.1.1. I may have just gotten lucky given my limited testing abilities.
We could ask in https://devzone.nordicsemi.com/, but they would probably say it's not supported. The question is whether they would be willing to say that it should work OK, or whether they know of some fatal flaw.
This patch adds S140 v7.0.1, which Nordic says is the first version that supports the nRF52833.
Well, it built and scans and Appears To Work. So I made a PR: https://github.com/adafruit/circuitpython/pull/2801
good morning! I'll see about merging ulab and then I have some RGBMatrix oddities to chase down.
Closes: #2787
@PaintYourDragon this also brings in the new ulab.compare.clip function
@tulip sleet what was the original purpose of small build? I know it was to enable smaller builds of circuitpython but is there a specific cutoff in terms of the chips it applies to?
Is it just boards using the SAMD21G18A
@ionic elk it is SAMD21 builds that don't have external flash, so 64kB of the internal flash is reserved for the filesystem.
e.g. Trinket and Gemma M0
Just to confirm, you loaded the 7.0.1 SD on your board as well when you tested?
Yes, I've updated the bootloader as well (see https://github.com/simmel-project/bootloader) and I'm loading 7.0.1 of the SD.
the flash layout for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.
the flash size for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.
I worried about this too, but it turns out I parameterized it when I parameterized the .ld file:
https://github.com/adafruit/circuitpython/blob/51dbe9109fb6a474fe7f4cf4e3766e27ba0b34b5/ports/nrf/boards/common.template.ld#L11
@tulip sleet sorry to bug again, do you think you could help me fill out this list? I'd like to put it in the documentation somewhere... I'd still like to make a template port at some point.
CIRCUITPY_DISPLAYIO = 0 # Technically has common-hal, but it's just a stub. Depends on SPI
CIRCUITPY_BITBANGIO = 0
CIRCUITPY_GAMEPAD = 0
CIRCUITPY_I2CSLAVE = 0
CIRCUITPY_PIXELBUF = 0
CIRCUITPY_RANDOM = 0 # Depends on OS
CIRCUITPY_STORAGE = 0
CIRCUITPY_TOUCHIO = 0
CIRCUITPY_USB_HID = 0
CIRCUITPY_USB_MIDI = 0
CIRCUITPY_REQUIRE_I2C_PULLUPS = 0
CIRCUITPY_ULAB = 0
Storage just requires internal flash, right? Pixelbuf I'd assume is Neopixel write?
the flash size for SD v7 0x27000 while v6 is 0x26000, did you update both flash layout for bootloader and circuitpython. I don't quite see the linker script changes in the commit diff.
I worried about this too, but it turns out I parameterized it when I parameterized the
.ldfile:
https://github.com/adafruit/circuitpython/blob/51dbe9109fb6a474fe7f4cf4e3766e27ba0b34b5/ports/nrf/boards/common.template.ld#L11
that is too smart, Dan :100:
@ionic elk pixelbuf is a C optimization to speed up RGB LED writes. it is separate from neopixel_write. storage for is any filesystem, internal or external
when you say "fill this out", I'm not sure what you mean
there are many of these options, and a few a MICROPY instead of CIRCUITPY.
I'm trying to comment what each item depends on - it's the list you need to include in a port mpconfigport.mk so it compiles in the early stages.
I don't see pixelbuf in the common-hal list for atmel or the other ports
This looks good!
In the long run it might be nice to use a submodule for the SD header files, though I'm not sure how we would have two versions available at once.
I will not merge yet pending any comments by anyone else.
That definitely would explain why my flash space shrunk by about 4096 bytes when I made the change.
i think pixelbuf is not quite ready
there is a python equivalent of it to save space on small ports
so normally it'd be in common-hal?
no, it's shared-module, because it's port-independent. it's C helpers for some stuff that is kind of too slow in python
ok, it is turned on for CIRCUITPY_FULL_BUILD, so we're not waiting on anything
there is prerequisite info for these modules implied in https://github.com/adafruit/circuitpython/blob/master/py/circuitpy_mpconfig.mk
but I think you are looking there already
Yeah I'm looking at prerequisites that are a good bit earlier than were considered in that file.
CIRCUITPY_DISPLAYIO = 0 # Technically has common-hal, but it's just a stub. Depends on SPI CIRCUITPY_BITBANGIO = 0 # Requires DigitalIO CIRCUITPY_GAMEPAD = 0 # Requires DigitalIO CIRCUITPY_PIXELBUF = 0 # Does nothing without Neopixel Write CIRCUITPY_RANDOM = 0 # Depends on OS CIRCUITPY_STORAGE = 0 # Requires a filesystem implementation CIRCUITPY_TOUCHIO = 0 # Requires Microcontroller (for generic implementation) CIRCUITPY_USB_HID = 0 # Requires USB CIRCUITPY_USB_MIDI = 0 # Requires USB CIRCUITPY_REQUIRE_I2C_PULLUPS = 0 # Does nothing without I2C CIRCUITPY_ULAB = 0 # No requirements, just takes space
pixelbuf can be used for DotStars too, so neopixel_write is not necessarily a prereq
if you want to add more conditionalization or testing in that file, that would be great
Well, actually right now I'm basically reverting all my conditionals since I'm realizing that they're kind of useless.
We could chat about it if you're open to it real quick
That definitely would explain why my flash space shrunk by about 4096 bytes when I made the change.
Did you change the bootloader knowledge of application size and starting address !!!
@ionic elk do you want to audio chat?
@tammymakesthings I just got a maxrefdes117# from digikey. it has the max30102. i could help write the library if you are interested. I so, do you have your current work within a github? Thank you.
@tammymakesthings I just got a maxrefdes117# from digikey. it has the max30102. i could help write the library if you are interested. I so, do you have your current work within a github? Thank you.
I would love the help. I have a GitHub repo set up, but nothing in it yet. I will add the people who have expressed interest, and then we can figure out a path forward. Thank you
I'm unsure of how it worked, but somehow it did. I have a feeling there's something in the UICR region that told it where to go, or possibly based on macros such as SD_SIZE_GET(MBR_SIZE) that are imported from the nrf headers.
Is there a functional flow-chart/diagram of the nitty gritty of how the CP ecosystem works? From bootloader to execution.
I see references to an API, but curious what that looks like visually.
Found this: https://learn.adafruit.com/adafruit-feather-m0-express-designed-for-circuit-python-circuitpython/uf2-bootloader-details but curious if there's more.
@spice crypt I think that's the best reference. I'm always happy to answer questions
Alright. I hate to bother you with my frivolous questions. I'm on a quest to speed up the boot times, as you may have noticed. π
Any time I spend teaching you comes back in spades. π
Digging into the nrf bootloader; see some delays I can shrink down.
you are trying to speed it up when waking from sleep right?
Right now, just curious where the handover from bootloader to "firmware" is, and how they talk for things such as the SoftDevice(BT)
No, from fresh boot
I've decided to just do a global power off, rather than use sleep for now
I'm at 7 seconds to UI loaded
how long does it take to get into circuitpython?
I'm unsure of how it worked, but somehow it did. I have a feeling there's something in the UICR region that told it where to go, or possibly based on macros such as
SD_SIZE_GET(MBR_SIZE)that are imported from the nrf headers.
No it is not that good https://github.com/simmel-project/bootloader/blob/simmel/src/usb/uf2/uf2cfg.h#L12
I am actually updating the bootloader repo for supporting self-updating with uf2 and also cross-version v6 <-> v7 support. I am not sure why it works out so ...
seems like most of that 7 seconds would be graphics stuff
you could set a pin high from C
Yeah, I figured I'll have to use some GPIOs to profile it.
I'm enjoying digging through the code
wakeup source? Assume that's a NRF register
I see that's used in the bootloader to determine if to start dfu. Anyway, I didn't understand what you meant by : "I'd love to see each delay check the wakeup source"
A ctrl+c, ctrl+d reset takes 2 seconds for first sign of life from CP
then 3-4s for the rest of my UI to load. So from raw poweron, looks like bootloader eats about 2s
basically, only delay if reason is pin-reset or vbus
aha! vbus is what I'll be shooting after
ctrl-d should be pretty quick. I guess the screen update may slow it down if showing the terminal
there is usb enumeration time too
but vbus should delay because it's the same as plugging in
there is usb enumeration time too
@tulip sleet Is this regardless if USB host is present or not?
I think the check for USB present is quick, but I'm not really sure. i think it's an electrical check by the USB peripheral
I shall experiment. Thanks for your input guys.
proceeds to continue premature optimizations
π learning is helpful
anyone planning on automating the download stats again? @tulip sleet or @raven canopy? Every release causes the downloads page to be sorted unhelpfully. Maybe we need to move assets back to github so we can grab the stats easily?
@slender iron I would like to process the download stats. Did you put your scripts anywhere? I think moving back to github is not a good idea at all
at the very least we could sort it alphabetically for now
I can manually do it but that doesn't happen immediately
I don't think we should have moved off github until we had this setup
the fix for download stats with github would have been simpler
i kind of disagree. The issues with github was not download stats,they were failed uploads and huge release pages. I will work on this.
i spent a lot of painful time fixing up releases
π I agree github wasn't perfect. I'm just frustrated by the regression of the stats.
i will put it on my short list
tfw you go looking for a bug, and the bug goes into hiding
I would have estimated that 1/20 of the time I would see a crash while updating code.py when an rgbmatrix display was in the mix. but now it hasn't happened in 100+ tests
What's the best way to generate documentation that needs line breaks at a specific column width? Do we have a python script, or is there an editor I should be using, or what?
Description: Particle Xenon has an on-board analog RGB LED, with current configuration in CircuitPython it is not available to user.
`
import board
import digitalio
led = digitalio.DigitalInOut(board.RGB_LED_BLUE)
Traceback (most recent call last):
File "", line 1, in
ValueError: RGB_LED_BLUE in use
`
It is understandable that this RGB LED could have been used to show bootloader status but it doesn't follow the standard set by CircuitPython project making it unusable and no...
Ok! This is ready for another look. @hierophect and @k0d please take a look at how I factored out the hal_conf stuff.
I tested on these boards:
- CircuitPlayground Bluefruit
- Feather M0 Express
- Metro M4 Express
- STM32 F405 Feather
I previously tested iMX RT and Fomu but didn't with this final change.
@ionic elk what's the formatting? Is this an .rst or an .md or ?
.rst should reflow paragraphs, which are separated by blank lines. so the input width shouldn't matter
so I can just write with word wrap on, and then save, and it should be ok?
or is this in code?
I'm editing porting.rst in Sublime Text 3
yes, just set your local word wrap to match the file approximately
it should reflow the paragraphs (e.g. compare the input with the readthedocs output)
Is there any blog/tutorial on how to use raspberry pi as SWD programmer? I am especially looking to re-program particle xenon board to be used with CircuitPython but don't have a SWD programmer, I read rpi can do SWD, so is it possible to flash bootloader on xenon using rpi?
@obsidian compass
so i managed to do it and wrote a blog on the same : https://codensolder.com/blog/rip-swd-programmer
It would be great to do SWD bit-bang using an existing CP board, @slender iron I saw your issue for the same, would be great to have that feature π
i actually tried this to do some fuse fixing before I got a J-Link; sounds like you did the same thing. I had more trouble with not-great chip support in in openocd
but that was a few years ago
yeah it's way easier if companies provides configuration files in openOCD, for NRF52 it was easy, I just spent two hours figuring how to put particle bootloaded to DFU which goes like push RESET and MODE button, then release RESET until you see GREEN blinky LED, after that it was easy
Also i didn't had the mini jtag connector so I soldered directly on the small pin headers π
@raven canopy I'd like to work on https://circuitpython.readthedocs.io/en/5.0.x/docs/porting.html#porting. Can you recommend a good editor for RST text? I'm new to it and Sublime really doesn't like the word wrapping.
@ionic elk how much time do you expect to spend on it?
Like 10m? I can just ignore it if you want
what is the issue?
I just ran into it as I was skimming and it doesn't make a lot of sense. Figured I could fix it up pretty quick
It's just very confusingly worded
I use sublime just fine
For me sublime acts like there's a newline after every 80 columns, and if I type in the middle of a paragraph, I have to go down and fix alignment on every line after it until I hit a paragraph gap
ya, I think that's what I do
Oh π¦
had the same issue with Zephyr documentation
Figured people were using some kind of autobreak tool I didn't know about
I just have the column line turned on so I know
@ionic elk there's probably some autoformatter for rst in VSCode
I imagine there is one
Yeah it just makes everything more work when I gotta get in there and fix like 6 lines just to edit one word choice
I really like emacs meta-q
yup. sometimes I just do small things the hard way
sometimes I start each sentence on a new line and don't worry about refilling. That makes it easy to edit, and the formatter takes care of the reflow
Does someone have some trick they use for debugging whilst developing. I can output to the USB-CDC, but that closes down on re-flash...If there isn't something there already, maybe we enable the VCP/ST-Link to output the 'console' also?
i just reopen the serial connection; i have some aliases to maek that easy to type
Ok, I found a good thing - Sublime->edit->wrap->"Wrap paragraph at 80 Characters" for you @slender iron
I do mp_printf(&mp_plat_print, ...) a lot
@tulip sleet I just think, that if a board has the debugger onboard (nucleo/disco) then we should make use of it.
@ionic elk did you have some thought on this whilst making the STM32 port?
@lucid solar not sure what you mean. I use onboard STLink sometimes with arm-none-eabi-gdb and OpenOCD or texane/stlink
i am doing that in conjunction with gdb
But that doesn't require anything extra from Circuitpython other than turning on symbol flags in the build process
I mean....being able to printf something to the VCP console through the st-link
I rarely do a printf when debugging, I just use print
@lucid solar you are proposing using the SWO right?
the serial output through the debug connection
@slender iron we could...but there is the VCP...much easier to use I think
that's a uart out to the debug chip right?
yup
I'd accept a PR for it. I either reconnect over screen when printing or switch to iterating with gdb and no prints
mostly we are not using dev boards with VCP built-in, so it hasn't come up that much
Ok...I'll make the code π DAPLink also has that feature.
that is, we are debugging on the adafruit boards
If we make it so a CPY board can work as a debugger/reprogrammer (CMSIS-Dap), then we could also enable that feature there.
@tulip sleet what do you use as the SWD programmer? j-link?
yes. I also have a BlackMagic, but until recently it didn't have SAMD51 support. The J-LInk has been mosty fine
and it supports so many chips
Adafruit bought me a commercial one since I'm using it for pay
aha...nice π
Hi @mew-cx. I believe we build the bins. We just don't upload them. You can build it yourself with these instructions: https://learn.adafruit.com/building-circuitpython/
We can start uploading it once an exception is added here: https://github.com/adafruit/circuitpython/blob/master/tools/build_board_info.py#L42
@slender iron is sommersoft around? I realize we need a regex thing to properly identify certain modules in mpconfigport.mk for stm32 now but thats not something I'm practiced in
how would I know?
he is not online (click the "persons" icon at the top), but if you tag him he may answer later
I don't want to lose the status functionality. To provide user access we should add custom exceptions to "busy pin" detection like we do for neopixel. https://github.com/adafruit/circuitpython/blob/master/ports/nrf/common-hal/microcontroller/Pin.c#L97
@ionic elk I was looking in the wrong file, now I understand
@slender iron sorry, I just meant if he was out of the country or something.
he has a day job
ah
(but is US based)
@ionic elk what do you want to do? enable the modules depending on the MCU?
goes to exercise
Thanks @tannewt I will look at that approach
I also built locally, and everythingΒΉ seems to be turning out correctly. Thanks @hierophect!
ΒΉ There appears to be some deeper brokenness going on. Things like frequencyio are showing up as available on the STM32F4s. They shouldn't be, since its not included in a MINIMAL_BUILD and I don't see it explicitly turned on anywhere. That is mostly outside of this though, so I'll find a better way to document the issue.
@lucid solar just pushed. parse_port_config in shared_bindings_matrix.py needs to be adjusted to fit stm/mpconfigport.mk
@ionic elk I see...
Issue is the H7 defines are turning off modules for the F4
I looked through everything, and it looks great! This may be some kind of record PR for number of files changed. I hope to get a chance to get some typical power measurements during time.sleep() vs not.
this is like a leap-year calculation :)
@ionic elk nearly done...I can see why it's not matching
I added
elif port in ["stm"]:
re_board_chip = re.compile("MCU_SERIES\s=\s(\w+)")
chip_keyword = "MCU_SERIES"
but still no dice so far
use r"..." because you have backslashes that are interpreted by re
the backslashes will get eaten by ordinary strings. using r (raw strings) prevents them from being interpreted.
ifeq\s($(MCU_SERIES),(\s)*(\w+)
it didn't seem to find it because (\s)* wasn't there
it needs to be r"MCU_SERIES\s=\s(\w+)"
also as you point out should be \s* to make whitespace optional
r"MCU_SERIES\s*=\s*(\w+)
and any length of whitespace
@ionic elk FYI, I use https://regex101.com to test things...
Regex101 allows you to create, debug, test and have your expressions explained for PHP, PCRE, Python, Golang and JavaScript. The website also features a community where you can share useful expressions.
now you have two problems
still not getting anything
what is the new code
the tester should be r"MCU_SERIES\s*=\s*(\w+)" to recognize ifeq ($(MCU_SERIES), F7)? do I have that right?
could you point to this file in a repo, also?
Sure, here's the PR changes
are you using match() or search() ? match has to match the whole input string
i'm confused, are you trying to match ifeq ($(MCU_SERIES), F7) ? That has no = in it. The above is going to match MCU_SERIES = <something>
Yeah I'm a knucklehead this is for the compile
got it! thanks @tulip sleet @lucid solar!
great!
@ionic elk did you see how I reworked the hal_conf stuff in my lower_power branch?
Taking a look right after I get this docfix PR in
Anyone good at bitmasking?
I have a uint16_t value...I need to split it in 2...lower byte and upper byte
8 should take the upper?
yes
& 0xFF lower?
yep
thanks...turns out I did know
There seems to be an issue with never_reset_pin_number not working in stm32
I'm totally game for this! Do we need to update the UF2 bootloader along with it?
Turns out I misunderstood how it saves the pin...it still doesn't work, but at least I can debug it.
@sommersoft I've adjusted the shared_bindings_matrix.py file - builds ok for me but let me know if you'd like to see any changes.
@jepler could you double check the change I made to MICROPY_COMP_FSTRING_LITERAL in circuitpy_mpconfig.h? I removed MINIMAL_BUILD as a flag - are there still conditions where you'd like this to be optional?
@slender iron ok reviewing low power now!
π
I think packet_size needs to be asymmetric because WRITES can be as long as the attribute length while NOTIFY is limited by the MTU. Based on the doc here it needs to be the larger of the two: https://github.com/adafruit/circuitpython/blob/master/shared-bindings/_bleio/PacketBuffer.c#L100
We'll want to validate that outgoing data fits into the mtu if NOTIFY is being used.
Overall, a very nice cleanup! Just a couple details to sort out.
@slender iron if an adafruit board has a built in display, you initialize it inside board_init right?
@lucid solar yes - check out the stm32 Meowbit or the Hallowing for examples
I see...just wanted to check that's the right way to do it.
π
I didn't find any evidence that MICROPY_COMP_FSTRING_LITERAL was presently defined before reaching this line; the compiler should shout if it was. If it's accepted, and if no boards suddenly overflow due to fstring literals being compiled in, it's probably fine.
Just have a couple questions. I like the changes to hal_conf, much more organized. I'd like to know your reasoning on removing STM32_HAL_H from the mpconfigport.h - how is that being passed to the common-hal modules now? As for port.c, do you expect you'd like all of the low power code to eventually be factored out into an rtc module or some other location, or do you think it's best left where it is?
Why does this lack a HSE value? Shouldn't it be 12 to match the pyboard?
I'm split on making redefining this optional. I'd prefer for each mpconfigboard.h to have the oscillator specified for easy reference, rather than having a default value elsewhere. If we use HSE_VALUE in this way, we should also consider going into the clocks.c files in peripherals and setting PLLM to HSE_VALUE/1000000, and removing BOARD_OSC_DIV entirely.
Why take this out? Makes it have to be manually included with every clocks.c file. And it doesn't impact the common-hal modules in your testing?
@ionic elk sorry for being a π today! i'm looking over it now. and yeah, i missed every r"" literal when i wrote it initially and haven't fixed it. deshipu fixed one a while back..
re: rST editing... i'm like Scott; the hardway. π
anyone know how to fix
../../py/circuitpy_mpconfig.h:335:50: error: 'MP_QSTR_displayio' undeclared here (not in a function); did you mean 'MP_QSTR_digitalio'?
335 | #define DISPLAYIO_MODULE { MP_OBJ_NEW_QSTR(MP_QSTR_displayio), (mp_obj_t)&displayio_module },
make clean and rebuild?
QSTRs don't regenerate properly most of the time, so they force you to clean when you add new modules.
aha thanks
Just have a couple questions. I like the changes to hal_conf, much more organized. I'd like to know your reasoning on removing
STM32_HAL_Hfrom thempconfigport.h- how is that being passed to the common-hal modules now? As forport.c, do you expect you'd like all of the low power code to eventually be factored out into an rtc module or some other location, or do you think it's best left where it is?
common-hal modules should include it directly. It's a good rule to list any includ...
I'm totally game for this! Do we need to update the UF2 bootloader along with it?
Yes, the bootloader includes the SoftDevice. So if we update CPy to v7.0.1, the user has to update both, and can't roll back just one. So it's kind of a big deal.
We don't yet a have self-updater for the bootloader: it's hard because once the bootloader protection is set, you can't undo it to write the bootloader. We could fix that in a new bootloader, but not in the current one, I think. So I think th...
Manually including it is a better practice because it's clearer where definitions are coming from then. Eventually I'd like to use include-what-you-use to automate include maintenance: https://include-what-you-use.org/
Everything compiled ok so I suspect common-hal code is getting it implicitly.
That's fine with me! I'd rather not do it in this PR since it's overstayed its welcome.
I looked through everything, and it looks great! This may be some kind of record PR for number of files changed. I hope to get a chance to get some typical power measurements during time.sleep() vs not.
Ok @hierophect. Should be good to go.
I built locally, a couple times. Verified that the ifeq ($(MCU_SERIES),F4) patterns in the STM port's mpconfigport.mk work, should they start to drift. Its all 5x5 that I can see.
I kind of liked the ALWAYS/DEFAULT/MINIMAL approach, but I spend no time adding ports. I'll agree with any approach of those that do. π
There are a few cleanup things, but they're mostly my doing from the initial effort. I have no issues handling them myself, as I prepare to loop shared_bindings_matrix.py...
I'm getting no REPL connection on a Metro M0 or CPXwhen built from your repo.
Couple of minor nitpicks and this should be good to go.
remove attribution for board folding
I don't know why the ST hal doesn't differentiate between the STM32F746xE and the STM32F769xG variations the way it does for most chips with a flash variation. I'll revisit this later if necessary, but for now, could you add a warning stating that this applies to the F746xG only? The xE has only 512KB of flash memory.
remove attribution for board folding
sure thing I'll revisit it after both this and the F746 are in
This looks good to me for merging, I'll mess with it more once it's in.
@ionic elk please don't ask folks to remove attribution. if they want ownership of it that is a good thing. I'd only object to them removing other folks
Further tests:
Feather M0, CPX, Metro M0: no REPL (tried USB2 and USB3 ports)
Metro M4: OK
CPB: OK
enumeration is partly failing:
Apr 22 17:52:46 salmonx kernel: [127707.719478] usb 1-1.4: new full-speed USB device number 95 using ehci-pci
Apr 22 17:52:46 salmonx kernel: [127707.832251] usb 1-1.4: unable to read config index 0 descriptor/start: -75
Apr 22 17:52:46 salmonx kernel: [127707.832257] usb 1-1.4: can't read configurations, error -75
Apr 22 17:52:46 salmonx kernel: [1...
@sommersoft I liked the concept of ALWAYS/DEFAULT/MINIMAL at first, but I realized it was backwards in how it affected ports. Setting everything to off and then adding what you support meant that you had to memorize what was in each "level" and then constantly re-evaluate if you should be moving up to the next. Starting at 100% and having a list of everything you turn off is like having a built in TODO list, one that you continually whittle down at. So I ultimately think it's better this way,...
@slender iron nope, it doesn't work, so maybe it's Linux-specific
it's flaky for me
usb problems usually means we're sleeping when we should be calling tinyusb
@slender iron Dan and I were talking about it for big list files like the STM32 has where we fold in macros or blocks of settings to add new board/SoC support, since they could lead to long and kind of confusing lists of attribution for stuff that doesn't really alter things structurally. If we do add them maybe we could attribute on a board-by-board level, where the name goes by the board that was added?
I have a few notes, but I think they're mostly because I lacked the context or (in one case) talking about a preexisting shortcoming that is not affected by this PR.
ideally this would be able to return up through the layers so the actual byte count written was known, but maybe this is not feasible
I don't understand why it's useful/necessary to switch away from ringbuf_alloc here
Because LPUART provides its own ring buffer implementation. It doesn't need a ring buffer, it just needs a buffer. So all the code was doing is a gc_alloc() on rbuf.buf. The ringbuf operations in ringbuf.h were never called.
SPIM3 is now available, so the comment is now obsolete.
@tulip sleet I can't replicate it when on gdb. can you?
@slender iron did you compile DEBUG?
I tried both though it looks like I may have triggered it with debug
er, without debug
without debug, REPL arrived a little delayed the first time, but then the second time it didn't work
(with j-link and gdb connected)
could try lowering the background interval to say 500 or 800us instead of 1ms; is that possible or is it 1/1024 based?
but i'm wondering if the USB peripheral is shutting down or something
The simplest solution here would be to simply default to 200MHz for the F746 overall, rather than the fastest possible speed for the chip, but that's a bit of a cop-out. I think another easy fix would be to have some #ifndef PLLQ_VALUE defaults for this file that can be overridden at the board level.
@tannewt do you have a preference here?
@tulip sleet I thought I removed the background interval
oh, hmm
could debug by setting a pin when call the tud task function, and saleae-ing the timing on working vs not working
ideally anything usb will trigger an interrupt that then wakes up the loop and then runs background tasks
Also, thank you for putting in the TFBGA216! That's a ton of work, much appreciated!
@slender iron maybe turn off the actual sleep now, to confirm that the new USB interrupt strategy works,
Ok I'm out for the day to make dinner be back tomorrow
@tulip sleet that's easy to do. it works for me. want a uf2 or to poke it yourself?
if i'm going to debug it, tell me the change, or a uf2 is easy
comment this out to prevent the sleep: https://github.com/tannewt/circuitpython/blob/lower_power/ports/atmel-samd/supervisor/port.c#L491
wfi = wait for interrupt
this is the sleep loop: https://github.com/tannewt/circuitpython/blob/lower_power/supervisor/shared/tick.c#L89
@slender iron commenting out the WFI didn't help. It worked, and then didn't work. (J-Link is disconnected)
@slender iron~~ if I power cycle it by pulling the plug, I can get the REPL to appear. If i press the reset button, it doesn't~~
ok, no, that's not true, I pulled the plug and now it didn't work. It's just flaky
must be timing since it's ok on samd51
the samd51 might be quicker on the draw on the USB interrupt
ya
i'll be off for a while but will check back later tonight
I'm about done for the day
@lucid solar https://github.com/modm-io/modm-devices
@tulip sleet just a random thank you! i hit some USB bugs that caused total crash, with a metro m4 when flashing new firmware with rosiepi. (when do these hurdles stop? haha)
updated the bootloader, and it seems to be fixed. π
anyone planning on attending the virtual pycon edu summit? https://us.pycon.org/2020/events/edusummit/
Thanks @dhalbert. sigh I may wait until next week to tackle M0 flakiness. I'm itching to work on ESP32-S2. Will see how I feel tomorrow.
No it is not that good
I see. In that case, I assume it worked because 0x26000 is within the region that's reserved for BLE pairings on my board, and I didn't pair any BLE devices. I've since replaced it with a macro, so now it should be loading at the correct address: https://github.com/simmel-project/bootloader/blob/simmel/src/usb/uf2/uf2cfg.h#L12
I think that updating the bootloader and softdevice is a major enough event that it's not worth it for most customers. I saw all so...
Oh. No, the reason why it works is because UF2 encodes the address as part of the file, and the bootloader was just honoring the addresses generated by circuitpython. The invalid USER_FLASH_START address just means that the UF2 file is capable of overwriting the SD, but because circuitpython has the correct addresses it won't actually do so.
Also, my USER_FLASH_END variable is incorrect. And the UF2_FAMILY_ID is still 0xADA52840 even for nrf52833. Hmm...
Thanks for the pointer to the build exceptions, @tannewt ! I'll submit a PR probably this weekend.
uChip boards are shipped with an Arduino bootloader. The .bin files can be installed without first installing a .uf2 bootloader.
Resolves #2798
Oh. No, the reason why it works is because UF2 encodes the address as part of the file, and the bootloader was just honoring the addresses generated by circuitpython. The invalid
USER_FLASH_STARTaddress just means that the UF2 file is capable of overwriting the SD, but because circuitpython has the correct addresses it won't actually do so.Also, my
USER_FLASH_ENDvariable is incorrect. And theUF2_FAMILY_IDis still0xADA52840even for nrf52833. Hmm...
Yeah, exactly, t...
I might be wrong here but isn't self update available via serial (or were you referring to self update via uf2)?
The feature list includes the following (and i recall testing this):
- DFU over Serial and OTA ( application, Bootloader+SD )
I've found some line-noise-like junk printed over USB serial console from 5.2.0. When GitHub starts working again I'll add a comment on existing issue...
Does anyone know of an existing tool that is like Circup, but is for upgrading the version of Circuit Python itself on the device rather than the versions of libraries?
@lone axle Do you mean one that doesn't require the user to initiate (could be viewed as authorise) the action with the double-click on reset button?
@simple pulsar correct. My thought is to have the program connect via serial and get in to REPL and issue reset to bootloader command from there.
π©
Here's my junk on serial console ```
0000000 Q u a n t i z e 2 3 2 . 5 6 1
0000010 2 3 2 . 5 6 1 e 3 4 8 0 . 0 5 1
0000020 _ X u 357 277 275 y 342 226 222 342 226 222 342 226 222
0000030 342 226 222 0 342 226 222 } 342 226 222 2 2 0 . 0
0000040 \n
0000041
Need to have a reasonably wide window for that to display nicely. The separator in print which should have been a space character has turned into a load of junk.
the args to print there would have been "Quantize", 232.561, 220.0 - curiously, 232.561 is repeated. Just added all of this to GitHub, I think it's in the stages of recovering at the moment.
I had a variant of this recently on 5.2.0. I've never seen this before b[ut I scrolled back a few hundred lines and a single line had some junk on it that looks like line noise.
lines here
On closer inspection:
0000000 Q u a n t i z e 2 3 2 . 5 6 1
0000010 2 3 2 . 5 6 1 e 3 4 8 0 . 0 5 1
0000020 _ X u 357 277 275 y 342 226 222 342 226 222 342 226 222
0000030 342 226 222 0 342 226 222 } 3...
I had a variant of this recently on 5.2.0. I've never seen this before b[ut I scrolled back a few hundred lines and a single line had some junk on it that looks like line noise.
Quantize 454.051 440.0
(1.48047, 4.81685)
4583 302.296 1480.47 4.81685 1480.87 1.48158 1.48158
Quantize 190.122 184.997
(1.48231, 5.04943)
4584 302.328 1482.31 5.04943 1481.75 1.48158 1.48158
Quantize 232.561 220.0
(1.48164, 5.0496)
4585 302.426 1481.64 5.0496 1481.84 1.48155 1.48155
Quantize 289.54...
@lone axle not a polished end item, but this is what i use with rosiepi: https://github.com/adafruit/circuitpython/blob/master/tools/cpboard.py
nice, ty
requires changes for CPython3.7+; has instances of async as variable names. https://github.com/sommersoft/circuitpython/commit/c5415cb82edf6a42ba11d04069e975809be311fa#diff-51ce48f797ab56188d3824c76f125eb2
Getting an error on GitHub trying to download zip file of the AzureIoT repo. Can't clone it from a terminal either.
https://github.com/adafruit/Adafruit_CircuitPython_AzureIoT
remote: Internal Server Error.
remote:
fatal: unable to access 'https://github.com/adafruit/Adafruit_CircuitPython_AzureIoT.git/': The requested URL returned error: 500```
Anyone else seeing GitHub oddities?
@old smelt I was getting a lot of 504 earlier. Probably still buggered.
also see https://www.githubstatus.com/
Welcome to GitHub's home for real-time and historical data on system performance.
Thanks @tulip sleet
@slender iron when you are available, could we talk about .packet_size before I submit another commit?
@slender iron thanks for the link to the edu summit, I'm going to be offline for class-rel. tomorrow but I'm now reg'd to attend this.
Good explanations in the new comments. I had a few corrections, and some queries.
These are implemented in shared-module, and are port-independent, so as soon as their port-dependent dependencies are implemented, they can be turned on. So could you change the comment to reflect that? For CIRCUITPY_PIXELBUF, it doesn't have dependencies, but it's not useful until either neopixel_write (NeoPixels) or SPI (DotStars) are available.
This should be a raw string: r"...".
@dhalbert the raw strings were part of the cleanup I mentioned in my review. Nothing wrong with fixing them here; I just figured I'd clean up my own messes. π
It was me, right when I got started. As I mentioned in my reply to Sommersoft, I got stuck on thinking about the problem backwards and wanted ports to build up from things being disabled, rather than the other way around. Nobody else uses it so I think it's best deleted.