Was this introduced in the last few days? I remember you mentioning it but I thought I pulled right before submitting this PR...
#circuitpython-dev
1 messages ยท Page 302 of 1
@tulip sleet at my comp now
I honestly think the whole system is a little dangerous, because it has two separate flags that do the same thing (SMALL_BUILD = !FULL_BUILD) and you could easily do something like setting FULL_BUILD=0, SMALL_BUILD=0 without realizing. It might be better if we remove SMALL_BUILD altogether, but I didn't want to go overboard.
@prime flower so you are going?
I looked in the latest master, because I thought it was merged already. So maybe try fetch and merge again.
I meant that I need to create a common-hal folder and implementation for them, but I can switch it around if it seems unclear.
CIRCUITPY_SMALL_BUILD is used in atmel-samd for 192kB builds (and only in that port). So it could probably be removed from here, but something equivalent still needs to be in atmel-samd.
@slender iron if you have time, now's good to chat
yup, good for me
@slender iron I registered using the link and intend to attend
Right, what I'm saying is that it might be better if atmel-samd 192kB builds did this by setting CIRCUITPY_FULL_BUILD=0, rather than using SMALL_BUILD which literally just does the same thing but with an extra step.
Is there still a way to turn on verbose logging to the REPL? It seems like notro was able to in this issue, but I don't see the command. Is it a special build flag? Only results I'm finding online are for SWD debugging
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...
Quick question, is there support for USB HID gamepad in CP?
@dhalbert ok fixes are in and merge completed. I went ahead and deleted SMALL_BUILD completely across the port, atmel simply sets FULL_BUILD=0 now.
I just realized on reviewing more closely that my suggestion is what your code does - guess we were on the same wavelength.
@spice crypt I don't know what you mean by verbose logging
@obsidian compass yes but the gamepad descriptors that work with a host can vary
I am looking for Linux
@tulip sleet do we have a learn guide for usb gamepad?
@spice crypt I don't know what you mean by verbose logging
@slender iron output like this assign byte code: code=20002a40 len=27 flags=0
assign byte code: code=20002b20 len=44 flags=0
assign byte code: code=20002b60 len=17 flags=0
make_function_from_raw_code 20002990
mp_obj_new_fun_bc: 20002960
make_function_from_raw_code 2002d970
mp_obj_new_fun_bc: 200028f0
make_function_from_raw_code 20002a90
mp_obj_new_fun_bc: 20002990
@tulip sleet Here is the board check I wrote for the Circuit Playground Library. python @staticmethod def circuit_playground_type(is_type=None): if is_type is not None and is_type not in ("Bluefruit", "Express"): raise ValueError("Valid Circuit Playground boards are Bluefruit and Express.") cp_type = None if "Bluefruit" in os.uname().machine: cp_type = "Bluefruit" if "Express" in os.uname().machine: cp_type = "Express" if is_type is not None: return is_type == cp_type return cp_type
Code looks like this: ```python
from adafruit_circuitplayground import cp
if cp.circuit_playground_type("Bluefruit"):
print(cp.circuit_playground_type())
Easily expandable to add new boards as they come.
might rename is_type but otherwise I'm happy with it.
@slender iron @obsidian compass There's no HID gamepad Learn Guide; sorry; I don't think it worked well or at all on Linux; it MIGHT have worked with the browser support on Linxu
@idle owl I think it would be better not to have it do the comparison itself if the arg is not None. That makes the function do two pretty different things depending on the argument. How about:
from adafruit_circuitplayground import cp
if cp.circuit_playground_type() == "Bluefruit":
# whatever
having it return either a string or a boolean is highly unusual
I wanted to force it to require "Express" or "Bluefruit"
So I made it more complicated to require one of those.
So you could put in if cp.circuit_playground_type() == "foo" and it will allow whatever you want. So if you typo'd Express or Bluefruit in your code, you might never know that you're not validating properly because the code will run.
And attempt to work on both boards.
@slender iron @obsidian compass There's no HID gamepad Learn Guide; sorry; I don't think it worked well or at all on Linux; it MIGHT have worked with the browser support on Linxu
@tulip sleet thanks for info, is there anything I can do to bring it to functioning state?
ok, so how about having two routines: circuit_playground_is_type(something) and .circuit_playground_type as a proprty (or a no-arg function). What I'm saying is that the API style you have now is highly unusual and potentially confusing
@obsidian compass there was no gamepad description that worked across all of MacOS, Linux, and Windows, so I had to do two out of three. In addition the Linux support seemed flaky in general
or you could have circuit_playground.EXPRESS and circuit_playground.BLUEFRUIT as predefined string constants (or integers!) that the user would compare against.
sounds ok
@obsidian compass issues were range of joysticks (8 vs 16 bit) and maybe signed vs unsigned
it was kind of a mess; support is poor and there were few hardware examples of non-proprietary game controllers that would work without installing drivers
@ionic elk in general for re patterns, you should always use raw strings, because you might edit an existing one and forget to put the r prefix on when it becomes necessary
a raw string is just a string that's parsed on input differently; it is not a different data type
@tulip sleet ```python
@staticmethod
def circuit_playground_type():
if "Bluefruit" in os.uname().machine:
return "Bluefruit"
if "Express" in os.uname().machine:
return "Express"
raise ValueError("Board unsupported by this library.")
def circuit_playground_is_type(self, is_type):
if is_type not in ("Bluefruit", "Express"):
raise ValueError("Valid Circuit Playground boards are Bluefruit and Express.")
return self.circuit_playground_type() == is_type```
from adafruit_circuitplayground import cp
if cp.circuit_playground_is_type("Bluefruit"):
print(cp.circuit_playground_type())
you could make circuit_playground_type a property; that would be consistent with what we make properties.
ok
you could save a tiny amount of code space by calling os.uname().machine only once and assigning it.
i'm just thinking about the frozen size
I don't know how to do that and have it return properly.
@spice crypt Ah. I'd just look in the source for those messages and turn the define on. I don't know it off the top of my head. (I never use it.)
@staticmethod
def circuit_playground_type():
m = os.uname().machine
if "Bluefruit" in m:
return "Bluefruit"
if "Express" in m:
return "Express"
raise ValueError("Board unsupported by this library.")
I'm partway through your uheap memory video, hope to do it that way eventually.
_CP_TYPES = ("Bluefruit", "Express")
@property
def circuit_playground_type():
m = os.uname().machine
for t in self._CP_TYPES:
if t in m:
return t
raise ValueError("Board unsupported by this library.")
def circuit_playground_is_type(self, is_type):
if is_type not in self._CP_TYPES:
raise ValueError("Valid Circuit Playground boards are Bluefruit and Express.")
return self.circuit_playground_type() == is_type
that assumes the type names are actually in .machine, which is true currently
Something will be in .machine I would think. And we can return whatever we want, so if it's not necessarily the name, we can still return the colloquial board name.
hmm ok
again, just saving bytes
right. Does _CP_TYPES go in init or outside
raise ValueError("Valid Circuit Playground boards are", self._CP_TYPES)
it's a class constant
ok
class ...:
_CP_TYPES = ...
yah ok that's where I was putting it.
@tulip sleet So this look ok for the error? Auto-reload is on. Simply save files over USB to run them or enter REPL to disable. code.py output: Traceback (most recent call last): File "code.py", line 3, in <module> File "/lib/adafruit_circuitplayground/circuit_playground_base.py", line 155, in circuit_playground_is_type ValueError: Valid Circuit Playground boards are ('Bluefruit', 'Express')
I think so, do you think so?
Good enough I guess. I used .format otherwise it does weird things with quotes separating each section.
We'll have to update the frozen lib. bleh.
At least we're not still dealing with 4.x I guess. Should probably figure out a way to make it fail gracefully if it's on 4.x still?
"figure out" I mean we already know how to do that. I suppose I simply mean do it.
Actually there's probably no point. Because Bluefruit was never supported on 4.x. We already put a hard stop on that.
ok, getting really close!
This is the same as CIRCUITPY_RGBMATRIX = $(CIRCUITPY_FULL_BUILD)
This is redundant with what's already in circuitpy_mpconfig.mk, I think.
Do you still need an answer from me? I'm not sure what the question was.
@gilded cradle or @tidal kiln This looks like something that one of you may be able to assist with: https://forums.adafruit.com/viewtopic.php?f=60&t=164690
@tidal kiln, want to take a look since you're more familiar with the FT232H?
@gilded cradle yep
Thanks
@slender iron you are right, notifications are only single BLE packet events, so the size is limited to that. And the discovery process does not include a way to determine a characteristic's max length.
I think it would actually be useful to have a Connection.max_data_length property so you could retrieve the negotiated max data length (mtu - 3) for a particular connection. That makes it easier to do length checking in various places.
Added some performance data on a few different ways to read and sometimes store samples in https://forums.adafruit.com/viewtopic.php?f=60&t=164758 - nothing better than 21-21kHz on a CLUE.
I've been dabbling with ulab recently. For a simple bit of analogue sample reading its data storage is the slowest. Is that as expected? Times are in https://forums.adafruit.com/viewtopic.php?f=60&t=164758
Does anyone know if the CircuitPython port for the Xenon / Argon supports the bluetooth functionality?
@pseudo pebble Last I knew, no. It utilises the microcontroller successfully but does not include support for the radio. It's been a while since I looked into it though.
@idle owl I knwo the Argon supports wifi, wasnt sure about the bluetooth
Ah hmm ok. @solar whale might know better than me.
With Adafruit not yet supporting a feathewr of their own with onboard wifi that works with CP, my stack of Argons is still relevant
@pseudo pebble the Argon is an nrf52840 and the Circuitpython bleio functions should be supported.
Like I said, been a while since I looked into it. I'm guessing it was pre-nRF52840 CircuitPython support.
Thanks for chiming in!
The Wifi via the ESP32 is only minimally supported
:: nods :: YEah, it works fine for basic stuff... but I gues particle is dead long term
Still, i have like 11 xenons and 8 argons and 3 borons... so if I can at least use the xenons ? Boonus
the xenon and argon should be functionally the same.
I even the Boron should work the same -- just no support for the celluar part.
I flashed up an argon, I'll try some BLE code on it, see what happens
you can use the wifi on the argon if you reflash the esp32 with the AT command firmware but it is not as well supported as the ESP32SPI capable boards.
:: nods :: Yeah, I am using it that way for some basic data logging. Qorks fine but the connection isnt super stable
In my opinion,you are better off adding an airlift featherwing....
Well, a xenon + airlift woudl not be a horrible option. I hate having to go to a two board solution, evne with stacking, but it is what it is
Good luck with BLE -- it should behave much like the fearther nrf52840 express
with a few pin name differences
:: nods :: I am lookign at some sample code now.
Big win foer me if it works. I cant go to production with them ofg course, but for dev? Perfect
Ok. It works
Good to know!
Yeah. No real muss
Do you still need an answer from me? I'm not sure what the question was.
@tannewt since you've been working with the clock files recently I was hoping for your input on including ifndef-mediated default values for the clock divisors (PLLM, PLLQ, etc) in each MCU line's clocks.c. These could then be overridden at the board level in the case that a board needs to suppress clock speed for a certain purpose (like external SRAM). Would this break anything for your low-power code or vision...
@hierophect I'm going to look at this a bit more before I say it's ready from my side. I'd like to test more of the functionality first. I won't implement Audio/TFT/Ext.Flash/Ext.SDRAM in this PR though. I guess that's ok with you?
@k0d we tend to go for shorter PRs most of the time, there are a lot of boards with major features missing - it makes the work available to others if they'd like to contribute as well. That policy often goes double for boards like the Discoveries since they could suck up a lot of time for features that we don't know the actual demand for.
Do you still need an answer from me? I'm not sure what the question was.
@tannewt since you've been working with the clock files recently I was hoping for your input on including
ifndef-mediated default values for the clock divisors (PLLM, PLLQ, etc) in each MCU line'sclocks.c. These could then be overridden at the board level in the case that a board needs to suppress clock speed for a certain purpose (like external SRAM). Would this break anything for your low-power code or ...
RGBMatrix is only enabled for the SAMD, so this is appropriate here. If it was full build, everything else would need to turn it off.
Ditto for RGBMatrix, this is labeled as though it's a SAMD only feature. is it?
@slender iron are RGBMatrix and FramebufferIO SAMD specific?
@ionic elk ladyada has asked me to look into porting it to stm, starting with the feather.
but right now, it isn't on that port, just the ones tannewt mentioned
That's what I thought. I wasn't sure about FrameBufferIO though which is why I asked. That's part of RGBMatrix?
right now framebufferio only works with rgbmatrix. in the future, we imagine that for microcontrollers with built-in LCD driving might implement something else that would work with framebufferio.
Ok, sounds good. Thanks!
happy to answer any more questions you have.
Chatted with @jepler about this on Discord to verify that FrameBufferIO is only used with RGBMatrix on the SAMD for now. Both RGBMatrix or FrameBufferIO default to 0 right now (unlike ulab, which defaults on) so they should be defined port by port - I imagine we'll make them default to 1 sometime later once they have more coverage (doesn't seem like we have a specific line for that but I'd figure it's when all the "big" ports atmel-samd, nrf, mimxrt, and stm are supported).
Great. I may go ahead and add this feature for all ports at some point (probably once the low power code is in), since it's low effort and could add flexibility for other use cases we don't know of across all boards.
@ionic elk rgbmatrix and framebufferio are on nRF too
@slender iron cool! it's not a super big deal just mentioning it in my conversation with @tulip sleet in the docs PR. There's minor ambiguity for some modules about whether they should be "default" or not but I'd hardly describe it as urgent.
just making sure you know after seeing "Chatted with @narrow dirge about this on Discord to verify that FrameBufferIO is only used with RGBMatrix on the SAMD for now." above
yeah I'll edit that to remove any confusion
Shouldn't impact the code, it's basically just whether the modules are set to 1, 0, or FULL_BUILD in circuitpy_mpconfig.mk. I figured in this case they should be 0 and turned on per-port.
I was just saying that the code
ifneq ($(CIRCUITPY_FULL_BUILD),0)
CIRCUITPY_RGBMATRIX = 1
endif
is equivalent to the shorter
CIRCUITPY_RGBMATRIX = $(CIRCUITPY_FULL_BUILD)
CIRCUITPY_FULL_BUILD is either 0 or 1, so you can just set the variable to its value.
Oh you mean just here in this file, I see, it was the other way because it was setting the opposite of SMALL_BUILD but now that it's FULL_BUILD it's just one line. Changed.
Sorry, I thought you meant you wanted it relocated.
@vale spire @atomic summit got the build setup enough to crash the linker
oooer, progress!!! Awesome!
you can make BOARD=saola menuconfig and the sdkconfig file ends up in the board folder
had to make minor changes to the idf to get it happy with -Wundef and -Wsigned-compare
It now requires us to call the interrupt handler.
This patch does two things:
- Add s140 v7.0.1 as an option to build, and
- Switch nrf52833 to use v7.0.1
Since this is the minimum supported version for that chip, and while 6.1.1 works (but is not supported by the vendor), are there any blockers for integrating this into circuitpython?
There's a lot of discussion here about how to update nrf52840 boards, but I suspect that should be a separate topic, since nrf52833 shouldn't ever really be running v6.1.1.
@slender iron neat! just reading throught he Makefile now. so you call the idf cmake with your sdkconfig and get a bunch of .a files for the relevant components and then you do the rest in the Makefile?
@vale spire that's the theory
It's fine! I was just waiting for extra vetting, but I see no reason not to proceed.
Everything looks great as it should be. We could remove an empyt ifdef with litex port, but it is not a big deal. I am not sure why nRF port ci failed due to lack of prototype for tud_int_handler. It should be present if tusb.h is included.
maybe remove this empty ifdef for cleaner code
Update the manufacturer of Fomu to Sean 'xobs' Cross.
Tested on nucleo_f746zg
@slender iron Github check mpy-cross-mac is failing, I think it's because msgpack isn't installed now for some reason.
@dhalbert should be all wrapped up for one last review!
@hierophect I've tested this a lot and feel that it's ready to go after a code-review.
OK, looks great, thanks for all the work on this!
@lucid solar noted, I'll look into it
we'll just drop that macos job if necessary, it's only a curiosity
https://github.com/adafruit/circuitpython/pull/2794 is an example of a job that is failing due to this
@onyx hinge we could just brew install msgpack
are you familiar with macos and brew? I'm not, though I did write that section of the actions file. I would be happy to see a PR from someone who is, to make it work right.
msgfmt is part of msgpack I think...I could be wrong will check anyway
on linux msgfmt comes from gettext, and we were running 'brew link --force gettext'. Until some recent change, that made the msgfmt program available. but now brew just criticizes you and doesn't do what was requested, even with --force
gettext was updated 2 days ago on brew, must have been that
could be? yesterday a run said this: ``` brew link --force gettext
shell: /bin/bash -e {0}
Linking /usr/local/Cellar/gettext/0.20.1... 181 symlinks created
If you need to have this software first in your PATH instead consider running:
echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile```
today a run said this: brew link --force gettext shell: /bin/bash -e {0} Warning: Refusing to link macOS provided/shadowed software: gettext If you need to have gettext first in your PATH run: echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile
maybe we don't even need gettext installed if macOS provides it...but I guess it doesn't provide msgfmt...which I guess we use?
do either of you have a Mac to update and check this on? If not I do (not used on a daily basis)?
I'm updating now ๐
fwiw this seems to work today on github actions, so I can also PR it if @lucid solar's tack doesn't pan out. ```- brew link --force gettext
-
echo "::set-env name=PATH::/usr/local/opt/gettext/bin:$PATH"
weird way to set an environment variable, but what are you gonna do
msgfmt is in /usr/local/opt/gettext/bin on my mac, so I think that's a good fix. can you do the PR @onyx hinge please?
sure thing
'brew' apparently introduced an incompatible change, where even "--force" does not actually make the commands available in the default path.
Also switch to a numbered macos release instead of "latest", though this did not save us from breaking changes in brew or other preinstalled sw.
This was reported upstream and they may be fixing it, but for now this puts the wheels back on the bus. https://github.com/Homebrew/homebrew-core/issues/53485
@k0d ran into this problem, and also reported that his mac has the /usr/local/opt/gettext/bin program preinstalled.
@lucid solar are you familiar with how to merge or rebase your PR to get this change once it's merged?
@lucid solar @onyx hinge I have a very vanilla Mac with only XCode installed, and there is no gettext available in /usr/local/
so I think you have it from a previous instsall
I was just going to say that...it's installed by brew
I didn't mean it was preinstalled
so we need the other command also
"brew install gettext" might be needed on a fresh mac ? It seems to be preinstalled on the runner, though it's not explicitly listed at https://github.com/actions/virtual-environments/blob/master/images/macos/macos-10.15-Readme.md
it's installed on the runner but is not placed on the PATH.
lets see if the test fails
ok, got it
@onyx hinge yes, I can rebase my PRs when this is confirmed working.
@lucid solar excellent. I wanted to make sure in case you were unfamiliar.
I had a couple of comments but they may not even need to be implemented, so I'm tagging this approved if it all looks good to you. We'll need to revisit board.c anyway after the low power stuff goes through. Overall this looks great, nice work.
This comes after port_init in main(), so the clocks should already be on.
Once the clocks are dynamic to save power they'll get turned on with a claim_pin() instead.
I figure this is new since it doesn't match the Nucleo F767 or the F746, but I figured I'd double check.
I can change the PR to ``` run: |
-
brew install gettext echo "::set-env name=PATH::/usr/local/opt/gettext/bin:$PATH"
``` though that prints a warning: Warning: gettext 0.20.2 is already installed and up-to-date which seems a bit silly
it might be better, instead of assuming gettext is installed when I can't point at documentation that says it is
this is odd: I did brew install gettext and now I have both gettext and msgfmt on my path under /usr/local/bin
https://github.com/Homebrew/homebrew-core/pull/53489 may have changed the behavior a second time?
we aren't doing brew update/upgrade so we wouldn't get it until the base runner image was updated.
(look at me pretending I know much about brew :-/)
I'm assuming, the actions macos image installs some of the "Utilities" via homebrew, so it probably installs gettext as a dep. of one of them.
@lucid solar my theory too
yes, my brew updated itself before trying to fetch, so it may be fetching the older one?
"Where is the macOS source? We are in the process of preparing our macOS source to live in this repo so we can take contributions from the community. Until then, we appreciate your patience and ask you continue to make tool requests by filing issues."
anyway, your pr is working, that job passed
i'll approve and merge once the test job works, unless you want to do it a different way
I think it's fine
I don't need to fiddle with it further, thanks
I had a couple of comments but they may not even need to be implemented, so I'm tagging this approved if it all looks good to you. We'll need to revisit board.c anyway after the low power stuff goes through. Overall this looks great, nice work.
I think it's good practice to turn on the clocks in case something else turns them off...in this case we know the flow so that's not going to happen...but for safety's sake it could be good to keep it?
I think this is the change in brew that happened: https://github.com/Homebrew/brew/pull/7328
Yes, it does. I'll look at setting it as a pulldown though...
Yeah, I got them quite some time ago from ladyada.
@ionic elk whats your plans for the STM32F7 ports? I'm starting to enable the missing modules, done pulseio, doing os now...
Sure. The eventual intention is to have clocks turned on and off when a pin is reserved with claim_pin, which will have the effect you're thinking of, so we can just leave it until that gets in. I've been putting it off since Scott's close to finishing his low power code and I'd like to do it as a part of my port cleanup after that.
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.
@tannewt I am adding Connection.max_packet_length, which returns the maximum number of bytes that will fit ...
@jepler does this make sense to you?
os.uname() works
os.urandom() doesn't work yet, will enable in another PR
Tested on nucleo_f746zg
I'm happy, the CI failed check doesn't matter, it was a GitHub timeout. Can you merge without me restarting the checks again? @hierophect
@ionic elk https://github.com/adafruit/circuitpython/blob/1f034f0f59e4263a52cd376ed53888eeaca3c0a4/ports/stm/mpconfigport.mk#L53
Is SPI really needed for displayio? when the driver for LTDC is made, it won't use it. But I guess they might still want to add a SPI display? just checking what you think.
@lucid solar right now enabling displayio probably expects that spi and i2c are available. You're right, it could be separated out, but I suspect there's work to do first
@lucid solar Yeah I saw your quick PR to add PulseIO in, looks good. There are probably a number of modules that can very easily be added - OS and thus Random and Storage are among them. ADC support is probably among the more difficult.
They didn't make my original todo list because I like to double check the Micropython and STM32Duino implementations to make sure there aren't any initialization gotchas or other major hidden differences from the F4 that could mess users up unwittingly. Making sure of that takes testing and reading and it isn't at the top of my priority list right now, but I'm happy to review anything you feel is low hanging fruit.
@ionic elk yeah, I'm just enabling simple things just now. Ones that I know won't break other ports. I'll get some F4 boards so I can test more complicated things in the future.
As for DisplayIO, that comment could probably be a little cleaner, yeah. Right now it fails because PulseIO isn't in and there's some backlight brightness thing somewhere that needs it factored out...
If you want, you could just breeze through the initialization settings between the CubeMX exports for the F4 and F7 for the basic/PWM timers and see if anything stands out to you. Micropython doesn't have an great equivalent to our PulseIO so it's less ideal for gotcha checking compared to, say, flash, where we're basically identical
Just FYI I'm working on a PCB project I promised a friend I'd do by the end of the week so I'm going to have sporadic availability today, but I'll be doing some reviews tomorrow and I'll be fully back in gear on Monday as well.
Ok, take your time. None of this is really priority, it's just I'm wanting to understand how CPY works so trying to 'touch' as much of the codebase as I can.
No it's great! It's awesome to have someone else exploring the STM32 port in detail. And I'd also admit that I didn't spend as much time on the F7 implementations as the H7 ones so it's good to have you pointing out issues like these
I don't understand the shared-bindings/shared-module system yet.
I'd like to look at the L4P5 port at some point....seems @meager fog is interested in that mcu and it's very similar to f7 in terms of features.
I think they like it for the similarity in stats to the SAMD51. But that said the Micropython is littered with structural differences for the L series, so I definitely wouldn't underestimate the difficulty of adding it. I think it'd likely be as much if not more work than the H7 port.
They have different flash memory structure, different bus settings, all kinds of stuff.
But I'm excited to explore the L series now that we have more low power focus and support. I've got friends who use Circuitpython for environmental sensors so this kind of stuff is definitely intriguing to me
I'm more into graphics, that's why I want to get LTDC working on the discof7 board...the screen is nice!
I think I'll leave it for a few days though, I've got another CPY issue I want to tackle first.
Actually, I want to get openocd into the Makefile first, as it's very useful for debugging...plus the USART/VCP thing we talked about.
@lucid solar shared-bindings/ provides the Python visible API layer for native modules. A native module is implemented per port in port/<port-name>/common-hal/<module-name>. If part or all of the module can be implemented in a port-independent way, then that port-independent code is in shared-module/
so any knowledge of the underlying datastructures should be kept out of shared-bindings. I keep falling afoul of this, and tannewt gently corrects me
It's not in the same directory as mylog.txt resides
hrm, what did you run in gdb?
looks like the ram.bin bit is commented out
line 13 may need to be updated too
that's how this stuff goes. it always needs a little updating because it's not fully auto
It's not happy after uncommenting the ram dump
`Breakpoint 1 at 0x310e6: file ../../py/gc.c, line 106.
Breakpoint 2 at 0x62d88: file ../../main.c, line 251.
Breakpoint 1, gc_log_change (start_block=start_block@entry=0, length=length@entry=2) at ../../py/gc.c:106
106 change_me += length; // Break on this line.
$1 = 0x0
$2 = 0x2
$3 = 0x6b0
#1 0x00037a20 in gc_alloc (n_bytes=<optimized out>, has_finaliser=<optimized out>, long_lived=<optimized out>) at ../../py/gc.c:597
597 gc_log_change(start_block, end_block - start_block + 1);
#2 0x0004441e in m_malloc (num_bytes=<optimized out>, long_lived=<optimized out>, num_bytes=<optimized out>) at ../../py/malloc.c:81
81 void *ptr = malloc_ll(num_bytes, long_lived);
#3 0x00053d88 in m_malloc0 (long_lived=false, num_bytes=24) at ../../py/malloc.c:122
122 void *ptr = m_malloc(num_bytes, long_lived);
#4 mp_map_init (n=3, map=0x20014f5c <mp_state_ctx+76>) at ../../py/map.c:87
87 map->table = m_new0(mp_map_elem_t, map->alloc);
../../tools/output_gc_until_repl.txt:32: Error in sourced command file:
No symbol "_srelocate" in current context.`
Also, I had to compile with -ggdb or else gdb would never break on gc.c:106
yes
need to look in the .ld file for the new name
looks like it's _ram_start now
I don't think I've done it with nrf before
you should be able to watch ram.bin grow
it is indeed
it dumps all of ram every gc action ๐
does your code finish? you may need to ctrl-c it at some point
the break in main.c is meant to stop gdb after the user code finishes
I had originally tried to run this on my full code and Jlink just segfaulted after a few minutes. I did change the code to something very minimal
Yep, I see that. I'll give it a few minutes
do yo have analyze_heap_dump.py command in your history so I can avoid transcribing from youtube
let me see
BBL, will report back
@spice crypt I don't have it in my history. It's been a while since I did it
np. Thanks for looking
(I realize it's late.)
@slender iron I'm here, sorry, didn't get the notification yesterday
no problem ๐
I finally got some focused time to work on things
one thing I ran into is a few compiler errors due to use using -Wundef and -Wsigned-compare
headers
we don't compile the source with our flags
sure, can pull these changes in
the other question I had for you was how I could disable overwriting the given sdkconfig
my ideal would be to have a full sdkconfig.defaults for the port and then individual sdkconfigs for each board
where the sdkconfig only has the differences
you can pass multiple sdkconfig defaults file via SDKCONFIG_DEFAULTS variable, like so:
cmake -D SDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.myboard"
(one sec, will double check the syntax...)
and then no sdkconfig? or one in the build folder?
it will create sdkconfig file from the contents of both specified sdkconfig.defaults files
usually it is recommended to add sdkconfig to .gitignore
kk, then it can be in the build folder
i think you should be able to customize sdkconfig file name, which makes it possible to move it to the build folder
yup. I sorted that out yesterday
just hadn't thought about the board one being a default as well
cmake -DSDKCONFIG=build/sdkconfig -DSDKCONFIG_DEFAULTS="sdkconfig.a;sdkconfig.b"
my current state is that the compiler is segfaulting when I try to use it for linking
so I've gotta mimic the link command the idf is doing
I'm happy with the structure
oh. that's interesting. if you find what change in the command line makes it segfault/not segfault, let me know
kk
Possibly some improvement in the future about this part: https://github.com/tannewt/circuitpython/blob/bab671a45e8c327d170787c86549f3c2a2bdfb9e/ports/esp32s2/Makefile#L63-L87
to derive it from the build system, instead of hardcoding
yup! That was just expedient
We tend to reorganize the files/directories once in a while. We do this in a way that doesn't break apps compiled with IDF build system, but if you are hardcoding directories then it may break unexpectedly.
had to do that first since tinyusb pulls in the headers
ya, we can always update it too
i've logged a task in our issue tracker this week about finding a way to generate list of compiler/linker flags for external build systems.
I was debating pulling them from the build.ninja file
that might actually be not a bad approach!
I think I need to union them though
or find the component I'm actually using and snag it from there
if you declare requirements of the main component on other components you use, then the include paths for the main.c will be correct
regarding tools/.gitignore โ was it needed because you set IDF_TOOLS_PATH=$IDF_PATH/tools?
yes, should I not have? seemed like what it was going for
usually if you don't set it, it defaults to $HOME/.espressif, or %USERPROFILE%\.espressif
All set! thanks for the ping, and the PR!
ah ok
@hierophect found this bug, it's stopping pulseio from working on the f767.
in docker containers, sometimes we put it elsewhere, like /opt/esp
heh. I'm on fish so the install needed me to add it
oh, i see. fish versions of install and export were contributed, i don't think we have fish users on my team, so this part might have been untested.
with bash and zsh it works without setting IDF_TOOLS_PATH
ok, I'll remove the .gitignore changes and look into updating the fish script too
@sour lynx will you want a rebase with it or is a separate commit ok?
separate commit is fine. I think we may have to amend your commit which fixes -Wundef after some bikeshedding, which ifdef/if defined(/if defined pattern we want to standardize on in our header files. And also will need to add a CI job to prevent it regressing in the future.
So likely the PR will be rebased and some commits might be squashed after we accept it.
๐ I tried to match the file's use
yeah, i understand. Maybe it will pass as is. Will see.
they should probably be #if defined(FOO) && FOO to be extra correct
in general I want us to move away from checking defined
for things which come from sdkconfig, if defined(CONFIG_FOO) should be sufficient, as Kconfig never defines to 0.
ya, that was my first approach (to have Kconfig define 0)
it might have been nicer if it instead always defined CONFIG_FOO to either 0 or 1, but alas
there was a lot of other issues to run down due to that
I like always defining because then you can verify the referencing code actually included the appropriate header
that's right, agree that defining 0s would have been a better option.
nowadays we have a CI script which checks whether we may have forgotten to include "sdkconfig.h" or misspelled the option name.
I think I have the start of that work in a stash if you are interested
i'm afraid if we change Kconfig behavior to define 0 values now, we have a good chance of breaking a lot of our users' apps
ya, it's a pretty big change
pretty sure we had a PR internally with the same change a while back (around the time of IDF 2.1) and even then when we had much less users it was decided that the change was too big.
kk
maybe in IDF 5.0...
luckily I realized the simpler way to fix the warnings ๐
thanks @sour lynx I appreciate the help. will poke the linker on my stream in a 2.5 hours
will poke the linker on my stream in a 2.5 hours
@slender iron Where do you stream at?
on Adafruit
youtube I'm assuming
aha
@tannewt I am adding
Connection.max_packet_length, which returns the maximum number of bytes that will fit in a single transmitted packet (MTU size - 3). It will throw an exception if you call it before the connection is established, since we don't know the MTU size.
I don't think you will be able to raise an exception because a Connection object doesn't exist prior to it being established.
How will you know the maximum amount of bytes you can read out? If you are a server with a wr...
Everything looks great as it should be. We could remove an empyt ifdef with litex port, but it is not a big deal. I am not sure why nRF port ci failed due to lack of prototype for tud_int_handler. It should be present if tusb.h is included.
@slender iron Re: heap analyzer. I got as getting the analyzer dependencies setup for analyze_heap_dump.py, but now running into the issue of different named symbols in the linker. I'll continue poking to find the appropriate translations. rom_start has me scratching my head right now.
nRF: https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/common.template.ld#L97
SAMD51: https://github.com/adafruit/asf4/blob/039b5f3bbc3f4ba4421e581db290560d59fef625/samd51/gcc/gcc/samd51g19a_sram.ld
I'll continue later on today
what symbol are you looking for now?
I'll be around off and on. just exercising now
Looking for mapping of this:
rom_start = symbols["_sfixed"][0] KeyError: '_sfixed'
'rodata' in nrf seems similar
ya, worth a shot. I'd have to look at the context
Tried, but that's not really a symbol
you may need to add it into the linker script
or hard code it
I think it should be FLASH_FIRMWARE
er, whatever CIRCUITPY_FIRMWARE_START_ADDR is
k, bbl. exercise time
๐
Linker: _rom_start = ${CIRCUITPY_FIRMWARE_START_ADDR};
mkdir heapviz
analyze_heap_dump.py: rom_start = symbols["_rom_start"][0]
Getting somewhere!
I don't think you will be able to raise an exception because a Connection object doesn't exist prior to it being established.
Right, sorry, I was calling bleio_connection_ensure_connected(), which will throw an exception if the connection is no longer connected. So PacketBuffer.max_packet_length will throw an exception if it's not connected, because it doesn't know the MTU and so can't answer reliably.
How will you know the maximum amount of bytes you can read out? If you are a ...
nice @spice crypt !
@slender iron I want to output the console on both uart and usb-cdc...thing is the serial.c file that does it over uart isn't included if usb.c is. So I'm wondering where is best to put the code. Any thoughts?
in some ways I feel serial.c should really be console.c etc, but that's something that needs bigger discussion I guess
@lucid solar for now I'd just #if it into the usb one.
ok...that's what I just started to do ๐
we can always reorganize it later
ideally it'd be any stream object
though the ctrl-c checking requires an interrupt
goes to lunch
@tulip sleet upgraded to ubuntu 20.04 -- part of a a complete rebuild of my system due to a disk drive failure. Just finished a complete build of CP (en_US only) but no issues (other than fomu - I have not installed the risc-v tools yet) . I managed to get away with just replacing my disk drive with a new solid state drive ... so far so good.
i got the motd on my RPi last night (running 19.10). not real sure i'm ready to test the waters there. ๐
@slender iron i've narrowed it down to the presence of --gc-sections on the command line. Which, again, is odd, because we use this flag in IDF build system.
but once i remove --gc-sections, the linker starts actually complaining about missing symbols instead of crashing
oh, and you seem to be missing -mlongcalls from CFLAGS
k, awesome!
Brand new Adafruit Metro M0 arrived today. The first time I plugged it in to my Windows 10 desktop, it seemed to connect OK, but several minutes later Windows said it was malfunctioning. Now Windows doesn't even recognize it. Nothing shows up in the Devices USB listing; there's no "beep" or any indication in Windows that anything got connected at all! But the Metro does receive power thru the USB cable. I can also plug in the 9V supply before connecting the USB; just nothing at all! What should I try?
@remote dawn did it have circuitpython on it?
It was ordered as CircutPython. The Adafruit Metro M0 instructions are confusing because they told me to start by installing the Arduino IDE, which I did. I downloaded the proper set of board files, and selected the Metro M0 but it said it couldn't connect.
what happens if you double click the reset button? that should get you into the bootloader
The light beside the reset button stops varying across the spectrum and turns solid green. Also the tiny LED labeled "L" turns on. But nothing shows up in Windows.
ah, so the varying sounds like the arduino rainbow pattern.
In fact, now the LED turns red, not green
red means that usb isn't detected by the bootloader
you may want to try a different cable and remove any intermediate hubs
Aha. I moved the cable to a different plug, without any intermediate hub. Now I have a green light AND Windows is giving me a METROBOOT hub. So now what do I do? Ignore the Arduino IDE completely and start up Mu?
Windows just informed me that the device is set up.
I've downloaded the latest version of CircuitPython (a UF2 file) - should I try to install that?
Welp, I tried to open the INFO_UF2.txt file on the METROBOOT drive and now it's hung up. Window USB manager is not responding. I'm going to try resetting. Hmm... a simple single press of the Reset button closed out the METROBOOT and brought up a window called CIRCUITPY. So I guess I'm in business. Thanks, tannewt!
@slender iron I've kind of fixed some of the esp32s2 stuff
@remote dawn no problem! glad you made progress
FileNotFoundError: [Errno 2] No such file or directory: 'boards/saola/saola-spi.ld' is my issue now
@lucid solar igrr saw that you can remove gc-sections and it doesn't crash
weird! that might be an old version of my branch
ok...did you have that file then?
ya, I think that is a litex remnant
but you wouldn't get that far without the newer makefile
@slender iron basically it seemed like xtensa-gcc was outputting the file, just not exiting correctly, so I tricked it into always reporting it exited ok. That seemed to fix some things, but not everything...so I think it's not a valid hack for now. I'll go to sleep now. Have a good weekend if we don't talk before Monday.
Thanks you too! Happy birthday!
Thanks ๐ฐ
Here is the notes document for Mondayโs CircuitPython Weekly meeting. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1hcf6M5Xfg-LgcnLCO06eExrDE44b1aTNV_eSqdDRjRE/edit
How will you know the maximum amount of bytes you can read out? If you are a server with a write and notify characteristic, then a client could write more than the MTU to you even though you can only write an MTU back.
That's a bit pathological (WRITE/NOTIFY vs the typical READ/NOTIFY), but I"m thinking the point of
.max_packet_lengthis how big a notify packet the server can send, and the point ofPacketBufferis to queue notify packets. Maybe we should just call it `max_notif...
Is this array declared in a different header somewhere? That'd be better.
@hathach I sorted out the include and the build passes now. So, please take another look on your monday.
@remote dawn If you are running certain antivirus or disk utility programs, they can interfere with seeing the BOOT drive (or CIRCUITPY). See some discussion here: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#circuitpy-drive-issues
It's not pathological. That's how USB MIDI works.
All right, I stand corrected. So I'm thinking that what one wants .packet_size to reflect varies based on which direction you're interested in and what the flags are. Perhaps the best thing is to drop it, and have the user code figure out the packet length required based on the situation, the new Connection.max_packet_length, and on the Characteristic's max_length. Or do you think calling it .max_notify_length makes more sense?
It looks great, please merge anytime you like
I'm wondering if a library for micro:Bit micropython will work on circuitPython.
@clever wren Which one?
cube.bit accessary
4tronix Cube:Bit
Un a little unsure if it is the Python library to run the cube:bit from a raspberry Pi with Python or micropython for Micro:bit
is the setup.py file included in the library repos "only" for installing the library via pip? Or does that serve a different purpose as well?
@lone axle only for PyPI/pip.
Thank you ๐
So, FYI, this "bug" is present in every SoC that we support, including heavily tested ones like the F405. It doesn't impact the functionality of the timers in any of them as far as I'm aware.
The use of the extern keyword here was carried as a convention over from the pins.c and pins.h file, but I'll admit I don't need to make much use of the keyword in my own projects. Is it strictly necessary to even have it at all for array declarations like this?
I don't really know much about this, just it couldn't find mcu_tim_pin_list when I enabled pulseio, so I assumed it needed that. I'll look into it more to figure out why it needed it.
@k0d what's the nature of the issue you were having with this array not being extern? I want to make sure we aren't overlooking any other issues. If there's a bug here it should be fixed for all boards.
ok, that extern isn't needed...it's the other line that was important.
Oh, yes I see we're simply missing the tim_pin_list array altogether! That's a typo for sure. Please remove the extern for now, I'll fix it across all boards later.
@clever wren From the 4tronix page on this, With Raspberry Pi, use any of the WS2812 code already available to drive your Cube:Bit eg. Pimoroni, Adafruit or 4tronix FireLed products. - The Adafruit NeoPixels are WS2812. The cube looks like it performs just like any other strip (or circle) of addressable LEDs. There are native Adafruit libraries to talk to these. https://circuitpython.readthedocs.io/projects/neopixel/en/latest/
@slender iron No wonder I have memory allocation issues all the time:
This is after initiation of all my code and then in "idle" state
I wish the GC just nullified all the "out of scope" blocks
You could try using weakref more
oh hm, does circuitpython even support weakref?
@ebon raptor that could be hard to do, due to the way GC looks for pointers
I'm more familiar with CPython than micro/circuit but weakref is more about triggering the refcount collector than the mark-and-sweep phase.
Yes, for robots, blocking would be very bad, even for a very short interval. It could cause important event(s) to be missed. I would not want my robot to collide with an obstacle because it could not catch the distance sensor event. I really hope the team can come up with a good and sensible implementation of concurrency for Circuitpython.
@tulip sleet @slender iron Looking at the changes on master since 5.3.0-rc.0, is the nRF firmware size calculation an important bugfix? I am pretty sure I don't want to go beyond that, where the SD version was changed. Just trying to decide whether to go to 5.3.0 final, bump slightly to the merge of #2800 (and get #2802, a nice little safe ulab update that might help PhilB), or what. I just happened to be checking now, will bring this to In The Weeds if chat doesn't produce a conclusion.
oh hmmm, #2802 is no good, it added docs but didn't actually pull in the ulab changes egg on face
Hi to all. I believe that it may useful have a file with raw data ( only samples data ) and to know which of them are the heart rate and SpO2. In this manner we can develop and test some algorithms before to try the sotfware in the bare-metal. Do somebody has the file or know where is possible to get it ?
PR#2802 missed the submodule update itself.
Hello, according to the documentation here, there is supposed to be a time.time() function like normal python. However, when I try to use this function it doesn't exist. It is probably just a documentation oversight. My output from the error and REPL is shown below:
code.py output:
Traceback (most recent call last):
File "code.py", line 37, in
File "code.py", line 17, in __init__
...
@onyx hinge The https://github.com/simmel-project/circuitpython/blob/689dd613791439b04b2cce6a45ebb9b99c95d098/ports/nrf/mpconfigport.mk change only updates the SD for nRF52833; it doesn't affect the nRF52840 ports
@slender iron when CPY is running a script...and it waits for CTRL+C...it seems to be running inside mp_builtin_input is that correct?
This is mostly a documentation issue, as it doesn't address time.time()'s need for long integer support.
Boards with small capacities/internal filesystems like the Trinket M0 and Gemma M0, have long integer support turned off to save space.
I think it should be raising a NotImplementedError on non-longint builds.
@lucid solar ctrl-C is detected in usb.c (mp_interrupt_char). It is not running inside mp_builtin_input. There's a check for ctrl-c there, but that's not the interrupting charater check
ok, thanks
pyexec.c parse_compile_execute() is where code.py gets run (that is well down the call chain; it starts in main.c)
I think I found what I needed...I need to do mp_interrupt_char for serial also...nearly done...just having interrupt issues ๐
The documentation here says microcontroller.nvm should return either nvm.ByteArray when available or None. I am was looking at my Trinket M0 (Circuitpython 5.2.0) and it gave me AttributeError: 'Processor' object has no attribute 'nvm' ... is this documentation error or an issue with the Trinket M0 build?
>>> import microcontroller as mcu
>>> mcu.cpu
>>> help(mc...
We may now face the first need to disable a ulab module, such as the newly added comparison module. At least the espruino pico board no longer builds with this PR, due to overflowing flash.
@onyx hinge Jeff, do you want to add the equal and not_equal functions to the compare sub-module? As far as I remember, the == and != binary operators won't work properly in circuitpython, if the operands are ndarrays. The two functions would offer a workaround.
I wouldn't mind seeing it added. ๐ I have continuing work on the RGBMatrix stuff that takes precedence right now.
I have continuing work on the RGBMatrix stuff that takes precedence right now.
@onyx hinge My question was not an invitation to tango๐ I will see to adding the implementations.
From your comment, I would think it was mcu.nvm instead of mcu.cpu.nvm.
Stay well.
Rich
shared-bindings/board/init.c:116
mp_raise_NotImplementedError_varg(translate("No default %q bus"), MP_QSTR_SPI);
Should be UART, not SPI.
(I will probably fix this and create a PR...just didn't want to forget to do it, so writing an issue)
I just experienced a variant of this or perhaps a different issue. I tried to copy over code.py as I normally would and it paused and didn't appear to copy any bytes. After maybe 20 second Windows popped up a very unique looking error. I've never seen an Adafruit board elicit one of these before, Error 0x80070079: The semaphore timeout period has expired:

Yep looks like it's something I just fixed with the docs change but wasn't on the specific feather I was using.
Thanks!
does it have any extension in capability from what's on the docs, along with the rename?
you mean for our version? Our version is the same as MicroPython.
ok
I'm working on a UI for a 3d printer using displayio and an m4 express feather:
MemoryError: memory allocation failed, allocating 1096 bytes
> in uart_port.readline()
I have to poll JSON from a UART to get the status of the printer. The JSON generates quite a bit of garbage (gc every couple of seconds), maybe fragments the memory.
I'd love to use a fixed buffer, and I'd just adore some kind of memory dump via USB. Any tips, dear friends?
@low sentinel if you can get away without parsing the JSON, but just reading characters until you hit the status field, that should help a lot. I'm not sure what you mean by memory dump via USB.
There is regular expression support: import re
maybe do readline() from the UART, though it will return an incomplete line if it times out
I'm not sure what you mean by memory dump via USB
I mean I have a lot going on here between displayio, json parsing, instrumentation, displayio font glyph cache, icons... It is tough to understand exactly where my memory is and some kind of visualization would be wonderful.
maybe do readline() from the UART, though it will return an incomplete line if it times out
That's the line that is OOMing.
Regexes - I'm not really sure I'll be able to use them. There are indices and identifiers and stuff. It's not straightforward anyway - would need to dynamically generate the regexes.
(I am in the wrong channel, this is more appropriate for help-with, I'm sorry!)
there isn't a detailed dump available in an ordinary way. We have some tools for doing this, but they are meant for development.
and it doesn't necessarily classify the memory as you wish
@low sentinel here is a stream I did about memory analysis: https://www.youtube.com/watch?v=baa5ILZTRkQ&list=PLjF7R1fz_OOXBHlu9msoXq2jQN4JpCk8A&index=7&t=12s @spice crypt has been doing more recent digging and is using displayio as well
Live stream of @tannewt debugging memory issues in CircuitPython.
Visit the Adafruit shop online - http://www.adafruit.com
LIVE CHAT IS HERE! http://adafru.it/discord
Adafruit on Instagram: https://www.instagram.com/adafruit
Subscr...
Yeah, these SVGs look right about perfect
I had to make a few tweaks for use on nrf (will make a PR) but otherwise the instructions are clear. You will need to uncomment the append line in the gdb script.
Hi all,
I'm a huge fan of this project. I was looking for some advice before I submit a PR.
I have a project that uses Optical Switches for determining wheel speed (and distance). I have put together a module that handles the counting via interrupts, very similar to rotaryio, however where rotaryio looks for a quadrature encoder, this module purely looks for single pulses.
My question is, how should I prepare my code for the PR. Given this linear encoder is similar to rotaryio, should I pa...
@slender iron how do you tell what driver one of these waveshare epapers has onboard? I've been poring over their datasheets and they don't seem to list it anywhere
this is weird. My ulab PR overflows espruino-pico, going from >60kB free to over-full. but .. the added code in ulab itself is negligible. and it only happens after being merged with origin/master, not on its own. (happens to be based at 5.2.0-rc.0)
hmmm
the linker script has
FLASH_TEXT (rx) : ORIGIN = 0x08010000, LENGTH = 320K /* sector 4 is 64K, sectors 5,6,7 are 128K */
but the successful build prints
68356 bytes free in flash firmware space out of 393216 bytes (384.0kB).
FLASH_FIRMWARE is the name that is supposed to be used for this region, the script gets it wrong and uses FLASH instead but that refers to the whole flash
so this port was really full before, but the script reported wrong and made it look like there was about 60kB free...
will note it on the PR
I'm back to see what's going on over here. I'm helping out with the Covid Watch project. Covid Watch is an anonymous exposure notification app to help contain Covid-19. I'm doing some BLE testing and measurements. I'm using CLUE this instant, but have some other boards. I wan't to squeeze out what I can from BLE in CircuitPython. I'm currently using _bleio. However, there seems to be a warning that it could change. How much of a risk is that?
While diagnosing the build failure of #2811, I discovered that for espruino pico, there is actually 320kiB for flash, but the build (when successful) reports space free against 384kiB. This appears to be due to using FLASH_TEXT as a section name, while the script (build_memory_info.py) uses FLASH_FIRMWARE (indicating it's the current best practice) if available, or FLASH otherwise; but FLASH includes e.g., bootloader and internal filesystem data.
@onyx hinge It is possible that the double-precision float routines have been included due to something in the code. Try arm-none-eabi-nm --print-size --size-sort --reverse-sort --radix=d and look for large routines, and look for dadd, dsub, dmul, ddiv etc.
ah, I read your later message.
@bright aspen It probably won't change that much; if there's something that you need in adafruit_ble in Python that we don't supply, feel free to open an issue.
we just don't guarantee that it won't change
hence the underscore
@tulip sleet still a helpful recipe, I'll file it away in my memory
so happy to see this added on github pull requests, even if it's a little hard to spot.
@ionic elk I know how to do it when looking at good displays website. what screen do you have?
@bright aspen nice! I've got my eye on a couple contact tracing projects. I mean to make sure we can be compatible with the Google/Apple system with a dedicated device.
How about renaming it incoming_packet_size but have it manage the notify vs write difference?
@LearnWeaver Awesome! We had some discussion of adding a counter class to frequencyio. I'd probably do it as a separate module though. Maybe just countio?
I'd encourage you to make a PR and mark it as a draft. We're happy to see early code and help guide it along.
@tulip sleet @slender iron Thanks! Covid Watch will probably switch over to Google/Apple and I'm also in the non-phone discussions, so this sounds great. I'm currently working in improving distance estimations.
We may now face the first need to disable a ulab module, such as the newly added comparison module. At least the espruino pico board no longer builds with this PR, due to overflowing flash.
@jepler @tannewt I am willing to change the sub-module structure, if necessity be. I would, perhaps, suggest at this point to run a poll on which functions people need, and use the results as a guideline.
I'm using CLUE this instant, but have some other boards.
@bright aspen I suggested the use of CLUE for anonymous Covid-19 tracing. If one tracing protocol/app is 100% open, then it could be implemented on an anonymous device such as a CLUE. https://twitter.com/DavidGlaude/status/1254016084719607809?s=20
@thorny jay I think getting decent distance estimates from BLE is going to be really tricky, I've been thinking about this. In a "normal" city environment I'm sure a basic system would be near useless. Apple might have some big data ML-magic from their "find my" service to improve this. There's also some basic techniqes with smartphones to try and work out if it's inside a pocket/bag or in-hand.
@thorny jay But it could certainly be an interesting educational tool for showing the protocol or allowing people to work out the limitations of the tx power/rssi approach. I'd like to persuade my godson to do some R&D here!
Yes, finding distance might be difficult... but maybe this is not what you really want. You need to build a risk estimation based on the signal strenght and duration. If you pass by someone, the risk is low. If the signal strenght is low, the risk is low. But once you have a long duration and a strong signal, then the risk increase.
I say that, but some friends in the city tell me they can see the Bluetooth signal from a lot of their neighborg, up/down/left/right. But since it's another appartment, the risk is pretty low. So false alarm might trigger if your neighborg is affected.
In preparation for the PyCon(?) or what was that conference where 3000 CLUE needed to be distributed as badge for participant, I worked (with @lone axle ?) on an application that show he colour of the badge from nearby users. That was just using the BLE colour advertisement from Adafruit. It would be super simple to show a spreading by having all the participant "green" and one with a "red" badge. Then see how long it take before everyone turn "red". And that would be very educational.
[adafruit/circuitpython] New branch created: jepler/2\.8\-cflags
[adafruit/circuitpython] New branch created: stm\-linker\-scripts
oops, sorry about that ^^^ (branches deleted now, I guess that doesn't warrant a notification)
@thorny jay I think I remember discussions about that app, where is it? I just stuck what I was reading in https://forums.adafruit.com/viewtopic.php?f=53&t=164851 And on the subject of city vs less crowded space, when I first got an Amazon Firestick (WiFi only) I plugged it in and it told me I didn't have enough bandwidth to use it. What is was actually telling me was the 2.4GHz wireless was way too busy where I live!! I run it now on 5GHz which happens to be less crowded.
@thorny jay the nRF52833 and some other newer nRF chips have Bluetooth Direction Finding support, which is not present in nRF52840: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/Direction-finding. I'm not sure how applicable it is to contact tracing, but we did just have an nRF52833 port added to CircuitPython. That chip has less RAM and flash so it's a bit of a squeeze for CircuitPython.
@tulip sleet Agreed, but there might me some very clever stuff to refine the estimates if you have a smartwatch and a smartphone.
Or even for the simpler case it could provide a small amount of extra information of correcting for attenuation from different angles. This is all guesswork, of course.
I just stumbled onto this board which looks extremely interesting to me. I have sent a message to the seller to find out the exact M7 chip Toasty uses. I so want one of these if it can be supported by Circuitpython! https://www.tindie.com/products/webtronics/toasty-480mhz-stm32-usb-development-board/
I will add
it is an H7
STM32H743VIT6
already supported, stupid easy
I do need the flash chip tho
@simple pulsar @tulip sleet @thorny jay @slender iron Wow, lots of great ideas here. I should have come here much sooner. At Covid Watch we are talking about a Tile-like device for childret that depends on the parent's phone for memory and Internet. I too was thinking that CLUE or Circuit Playground Bluefruit could do that and mentors could help people get their devices started. That is very cool. I think that DP3T has a limited version in Python and that might be a place to start tinkering (I have not looked at it). A/G seems to be based on the DP3T work. I am on the Covid Watch team, and I lurk in the CoEpi, SafePaths and TCN Coalition Slack workspaces. (Covid Watch is part of TCN Coaliton). Besides the channel for making such gadgets, I'm also on the channel for distance measurements which is generalizing to exposure discernment. There we will be using CircuitPython for measurements. Well, two of us are getting up to speed on that. If anybody's workstyle allows, I'd encourage contacting a team that fits and jumping in. In the mean time, I'll be around.
@ionic elk @timber mango the 2MB flash is just the figure for internal flash on STM32H743VI isn't it?
@onyx hinge on the Toasty? I wasn't actually going by the stats, I was going by the physical IC I see on the board that looks like a Nor flash chip
I do see that 8-pin package near the USB connector too
I don't know what it could be, other than flash
the stm32duino port doesn't seem to have any information about it either
agree
I will add
@ionic elk Wow, cool! ๐ I will see if I can find out what the flash chip is.
I designed a board recently, there is some ESD protection for the USB that was in an 8pin package...
I don't see why they would add flash to that board, 2mb on-chip and an SD card.
@bright aspen I'm lurking on coepi. I'd suggest lurking on https://github.com/simmel-project/ too. It's bunnie and xobs making a trace device.
I am hoping to order at least one Toasty when I get paid. I am hoping I can order two. I will just have to see how much money I have left after getting necessities.
This looks good to me generally, I can't think of any way it could impact actual chip performance but I'll test it anyway when CI is done. I've got two minor style requests.
Can we indent the other lines to match style?
While we're here... is there a particular reason why we show only the remaining free bytes, rather than simply the amount of flash used? I use this metric the most often to gauge the results of optimization or to see whether it will fit in a low-flash board or a certain sector on a board, but I have always had to reverse this operation to get that info - I have never needed to know the remaining amount of flash as a raw number. Maybe that's more interesting to others, though?
@timber mango don't forget to get a cheap multimeter re our convo weeks ago; will be useful for testing
I often need to know just how tight it is, so it sounds like both numbers are useful
@ionic elk does the ribbon cable have a number on it? you can compare with the 2.9s on here: http://www.e-paper-display.com/products_list/pmcId=29&pageNo_FrontProducts_list01-004=2&pageSize_FrontProducts_list01-004=15.html
Good Display is a professional E-ink Display (E-paper display) and OLED display factory in China, as market leading supplier,we have more than 10 years' products experience for both Standard and Custom Products.
This OK as is, but fine if you address @hierophect 's style requests and I will re-review.
don't forget to get a cheap multimeter re our convo weeks ago; will be useful for testing
@tulip sleet A decent DMM is very high on my aquisition list. I can not get by without one any longer. I had one of these before and it was excellent. https://www.digikey.com/product-detail/en/flir-extech/EX330/EX330-ND/6149613?utm_adgroup=Test %26 Measurement&utm_source=google&utm_medium=cpc&utm_campaign=Dynamic Search&utm_term=&utm_content=Test %26 Measurement&gclid=Cj0KCQjwhZr1BRCLARIsALjRVQOohqBI9gKi7cy2OuRuvg0m6cE3kV__00_JvHrk2xq-0_zin9e62bUaAr_lEALw_wcB
Order today, ships today. EX330 โ Auto Average Handheld Digital (DMM) Multimeter 3.75 Digit LCD Display Voltage, Current, Resistance, Capacitance, Temperature, Frequency Continuity, Diode Test Function Features Auto Off, Hold from FLIR Extech. Pricing and Availability on milli...
@timber mango sounds good but if you are pinched a $20 one would be fine too. I managed to get a Triplett 1401 locally for a very good price. It has probe holders which I like a lot. I have the Extech also
sounds good but if you are pinched a $20 one would be fine too. I managed to get a Triplett 1401 locally for a very good price. It has probe holders which I like a lot. I have the Extech also
@tulip sleet I will keep that in mind. If I can only get one thing, it will be a multimeter.
Digi-Key has lots of 'em, including $20 (not autoranging, but that is usually OK with me): https://www.digikey.com/product-detail/en/flir-extech/MN35/MN35-ND/7322804
Order today, ships today. MN35 โ Manual Average Handheld Digital (DMM) Multimeter 4 Digit LCD Display Voltage, Current, Resistance, Temperature Battery Test, Continuity, Diode Test Function Features Hold from FLIR Extech. Pricing and Availability on millions of electronic comp...
@tulip sleet That does look like a decent little meter. If I can not get the Extech 330, I will go for the MN35. ๐
Looks good to me, no potentially breaking changes here until the TRNG stuff goes in.
Jumped the gun a little. Please add support for the H7.
Please also enable for the H7, this change applies to both.
Can you make this STM32_SERIES_LOWER, to maintain clarity? Case doesn't matter that often but it sometimes comes up between mac/linux builds, and I'd rather not have two STM32_SERIES variables that have opposite case.
I can't test on a H7, and I don't like to enable things without testing them.
Ran a double check on the F4->F7 migration appnote and Micropython implementations, looks good, no gotchas that I could find. H7 should also be easy, but takes some register renames so we can do it later.
Looks good to me. Removing on Espruino-pico is a fine choice.
Thanks for the edits. Looks good.
"330104 bytes used, 718472 bytes free out of 1048576 in flash firmware space"
"330104 bytes used out of 1048576 in flash firmware space, 718472 bytes free"
@ionic elk the 2MB flash is just the figure for internal flash on STM32H743VI isn't it?
@onyx hinge This chip has 1MB of on chip flash with the possibility of adding up to 1MB of external flash.
@timber mango ah yeah I missed that it's a VI, rather than a ZI
so does the Toasty come with the extra 1MB included? I don't know why it would be restricted to "up to 1MB" when could plop any old flash chip on there.
Toasty has 2MB Flash, so has the 1MB external flash also, and 1MB SRAM which gives 864KB SRAM for users.
@slender iron wowzer that is a lot of almost completely identical 2.9" boards
I don't see any particular matches in the FPCB, seems like the silkscreen on it varies a lot even in the product photos. mine only has TP0-TP6 markings, no serial number.
How does the build script know what files to freeze into a firmware for some given directory? Does it do all py files except for setup.py?
Looks good to me. Reminds me to re-check -flto, I can't remember why I didn't enable that last time but it may have been resolved by other recent makefile/linker changes.
@thorny jay the nRF52833 and some other newer nRF chips have Bluetooth Direction Finding support, which is not present in nRF52840: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/Direction-finding. I'm not sure how applicable it is to contact tracing, but we did just have an nRF52833 port added to CircuitPython. That chip has less RAM and flash so it's a bit of a squeeze for CircuitPython.
@tulip sleet Just a heads up, the Angle of Arrival (AoA) and Angle of Departure (AoD) that you can do in BLE 5.0 is not possible in phones or phone to phone. It requires a much larger antenna. Last I looked into it the antennas which could do it were more like ceiling tiles.
I was super excited about this approach until I learned that. ๐
@marble hornet there's a list of what to freeze in the mpconfigboard.mk for each board (see CircuitPlayground Express for an example)
oh, sorry, the answer to your q is in tools/preprocess_frozen_modules.py
Thanks for the edits. Looks good.
Thanks! I will take a look and see where I can go from there.
And I had some trouble figuring out: do you have to make clean every time you add or change what modules are frozen in?
Or can you just re-build?
@thorny jay and @simple pulsar Do you know if the circuitpython ble library can control the output power of the BLE radio? Since you want to track shorter distance interactions you can turn this down. I worked on a project where we had hundreds of BLE Beacons in a building and one issue was the beacons were transmitting at a power that you could see beacons from so far away, and it was too noisy\ hard to determine location.
@idle wharf I don't think we can now but it could be added
@idle wharf sorry, I am not an expert... that would be for @tulip sleet but he is in a meeting now.
CircuitPython Weekly in ~45 minutes. Everyone is encouraged to attend - you can always attend and listen in if you don't want to participate. Hope to see you there! Here is the notes doc. Please add your hug reports and status updates even if you'll be attending - it's super helpful! Thanks! https://docs.google.com/document/d/1hcf6M5Xfg-LgcnLCO06eExrDE44b1aTNV_eSqdDRjRE/edit <@&356864093652516868>
Do we have any existing library (or builtin?) for parsing XML?
no, sorry
@idle wharf there is skeletal power support but it's not really implemented. It would not be hard
Thanks @tulip sleet if I get far enough down this road, I can bring a C dev to the table to help.
it's only a few lines of code
ha! You're not supposed to admit that. ๐
I'm pretty deep into looking in this (contract tracing with BLE) for a client and specifically the suitable Adafruit boards.
I'm choosing circuitpython for the proof of concept because the MicroPython boards I've used have incomplete libraries, lack of inventory or the development seems to have died off. So huge kudos to this community for the awesome momentum around CircuitPython!
I wonder if there is any interest in having one created? I got to thinking about some way to define interface layouts within their own file more like how mobile development handles them. I thought about possibly using JSON for it for a bit over the weekend but I think XML may be able to express them in a more clean and easier to understand way.
i would say that json and xml are equivalently functional.
for both it's harder to write an incremental parser
which would save memory
Definitely both functional but the hierarchical / tree like nature of UI Layouts lend itself to XML a bit better I think. Maybe I'll go ahead and try mocking up some ideas for possible layout code with JSON. Perhaps it will work out nicer than I am thinking.
There's also YAML ...
and TOML ๐
This blogpost: https://engineering.instawork.com/when-xml-beats-json-ui-layouts-53c7f1d3fdb7 has some thought put into JSON vs. XML for use with interfaces. I'm not familiar with the "Hyperview" platform but they do raise some pretty good points about the differences between the formats and pro/cons of each for layout building.
@idle wharf What is the nRF52833 board? Concerning power, I think that is possible, thre is a soft device interface. Unless you beat me to it, I'll add an issue for that.
YAML I am less familiar with. I should read up on that one some.
@bright aspen the different Nordic chips just have different specs. Some add NFC as well the Floating Point Module
https://www.nordicsemi.com/Products/Low-power-short-range-wireless
https://developer.arm.com/docs/ddi0439/latest/floating-point-unit/about-the-fpu
I've used it for fairly simple configuration files in the past.
both xml and json can be processed incrementally, it's the SAX model vs the DOM model. However, when writing to the SAX model you often end up with assumptions about the order of data encoded in the reader and writer (when the data formats may even specify that e.g., mappings in json can be arbitrarily re-ordered without changing meaning) that hinder interoperation with other generators/consumers
@idle wharf That is a cool table! Thanks! But, I asked my question poorly. You mentioned "but we did just have an nRF52833 port added to CircuitPython". Is that something available?
Ah.. gotcha. Sorry. I was quoting someone else who mentioned the nRF52833. But no, on Adafruit there no boards with the nRF52833. I do see the 832 come up though. https://www.adafruit.com/?q=nRF52833
Adafruit Industries, Unique & fun DIY electronics and kits : - Tools Gift Certificates Arduino Cables Sensors LEDs Books Breakout Boards Power EL Wire/Tape/Panel Components & Parts LCDs & Displays Wearables Prototyping Raspberry Pi Wireless Young Engineers 3D printing NeoPixe...
The original post was about BLE AoA and AoD for precise distance measurement and as long as the chip\library support BLE5 you could use that part of the BLE Protocol, but again, I think the antennas are pretty big.
@half geyser added support for nrf52833. We don't have a board right now, but he does (that is, he is working on a project with one)
I see nRF52832 and nRF52840. Ah, @half geyser . I'll look.
we no longer support the '832 on CircuitPython, because it doesn't have native USB
is what xobs is working on. https://simmel.betrusted.io/
Simmel Project
Simmel is a wearable platform that enables COVID-19 contact tracing while preserving user privacy.
so you might want to get in touch with him ๐
I also see that if you search for "direction" on the Nordic page that some chips support it and some do not.
https://www.nordicsemi.com/Products/Low-power-short-range-wireless
Do any of the non Nordic boards support BLE?
Happily lurking today ๐
...or is it lurking happily? Same difference.
hello, I'll be taking notes today. Slow getting set up.
@bright aspen no
Loud and clear
thanks @serene warren it's a big help
Went fishing yesterday, got beat up pretty bad by wind and waves. Sore as can be today.
@idle wharf we are starting our weekly audio meeting if you want to join. See the top pinned message for a link to the notes
@bright aspen too
I find shaking the crumbs out occasionally helps with my keyboard
@tulip sleet Thanks for the invite, I can't today... just about to head away from my keyboard.
lurking
Hugs only today
Text only
@slender iron I'll get the links during community news
though I guess the links aren't in the doc, so it's anybody's guess:)
lurking today
On the 29th of April, the 7th Birthday of MicroPython, our team will pick a winner, who will get the Pyboard D-series (https://t.co/4Pp7zQ5WTq) and the runner-up, who will get a MicroPython T-shirt.
We are looking forward to seeing your creations :)
Good luck!
https://github.com/google/cyanobyte/tree/master/test/sampleData/micropython https://github.com/google/cyanobyte
Harvard Online Courses
Browse the latest online courses from Harvard University, including "CS50's Introduction to Game Development" and "CS50's Mobile App Development with React Native."
Stanford course expected 1k people - ended up with 80k people applying.
ooh Dresden. One of my favorite cities in Germany (family lives there:)
And flexible e-paper displays
there's lots more in the newsletter that Scott isn't covering right this second
k0d is swedish for code....but spelt differently...maybe I should try to change my github username ๐
I'll probably be lurking most of these meetings, as it's a time when my wife is home watching TV so I can't talk.
@lucid solar You can also be text-only.
Where you type your notes into the chat channel, or better yet, add them to the notes, and we'll read them off.
@idle owl yeah, I've added them to the notes.
@lucid solar Excellent, thanks!
@timber mango will you be participating or are you lurking?
This would help in developing anonymous exposure notification apps to contain Covid-19 (privacy-preserving contact tracing apps) in testing and measurementsโand perhaps even in devices.
In characterizing RSSI for different phones, control over BLE transmit power in a nRF52 CircuitPython board would be handy. There has also been talk of doing that to help with distance estimation.
Perhaps this could be a property of _bleio.Adapter. (And perhaps eventually added to the appropriate class ...
Need a minute before talking
The Nordic SoftDevice API allows separate power choices per connection and also per advertising setup. This flexibility is great, but is a complication, so we have to figure out where to pass in optional power levels.
i still maintain that Git is a strange, and magical realm we've only recently discovered. ๐ฆ ๐
Back and can talk
k, will do you last
Yeah, I was wondering about separate power. I was a little timid and didn't want to ask for too much. The separate power might be great for emulation.
@sterile bronze drop us the link again in case anybody missed it ๐
@raven canopy Certainly strange. Unsure about magical.
www.youtube.com/kingernorth and go to my Micro-controllers with kingernorth playlist
Welcome to Micro-Controllers with me, kingernorth as I talk about Arduino and CircuitPython programming.
lurking
thanks @idle owl I got distracted
@onyx hinge No worries. ๐ I understand entirely.
Folks, please if you have any last minute news, projects, events, etc. in the Python/CircuitPython/MicroPython community, please email them to me at anneb@adafruit.com as soon as possible, in the next two hours if possible, for tomorrow's newsletter.
Thanks and sorry for the hit and run post, something personal came up in the last 45 mins and I'm sorting that out also.
I'm writing a four page feature about Python on hardware. It's mostly done but I'd love to hear your thoughts and experiences. Are you making projects or boards that use Python? Why? Please let me know your best experiences, worst frustrations and show me your pics!โก๏ธ๐โจ
yes
@slender iron sorry, cater got out of order in the document
np
@timber mango any notes for status updates?
crazy clock is a fun one https://www.tindie.com/products/nsayer/crazy-clock/
Yes that one.
@lone axle have you looked at the 32blit at all? I was starting to think about games for it
the circuitpython FAT filesystem is case-insensitive, which is why 'import label' and 'import Label' both wored
Whoa neat, nope I hadn't seen that yet. I'll look into it. Definitely looks like a cool device.
I would love to know/have the electronic to control a clock from GPIO. It mean driving a solenoid with 1.5V, so to get from 3.3V and some protection for return current(?). It would make it possible to control the second hand from any microprocessor.
Ah, Thank you Jeff. That makes sense.
@lone axle they are doing some cool game asset stuff too
@onyx hinge That's a pretty nifty novelty clock
@onyx hinge I have nothing. I do not know where my brain is going to take me this week.
@ionic elk mute please
sorry!
np, just heard you mousing. not disruptive
@old smelt before next time, you may want to take a look in your discord "user settings", you can tweak the input sensitivity or use "push to talk" to prevent your audio from cutting out. When you are talking, watch for a green circle around your avatar -- if it's not steady while you're talking, then you are cutting in and out for us.
@old smelt You still cut out a little, but it was a lot better this time.
Oh sure. Okay. Using my studio setup, so that's odd.... I'll check it out.
Thanks!
Sorry... ๐ฆ
I appreciate it.
It's likely a Discord issue, not your hardware.
+1 for Jeff's suggestion, I've had that issue with each new mic I've attached to my system. And sometimes it randomly resets back to "auto-adjust" for no good reason ๐
Oh, meant to share this image.
@old smelt I think discord is pretty aggressive at its "voice activity" sensing, which is why you might want to experiment with the options
Will do.
And there's the new voice compression (on MacOS it's next to share screen and hangup), indicated by a vertical bars of various lengths. That might be causing an issue too.
@idle owl we can look at that together in the weeds or some other time soon, if you like
@solar whale that's a good looking frame!
@modern wing - I've had seemingly unending audio trouble when I run the mac app. I usually end up on Chrome, like today. But, I'm game to try again.
@idle owl it'd be good to use the same board names in the CP library as you'd get from os
@slender iron That's what it uses.
perfect!
https://wiki.radxa.com/RockpiS ROCK Pi S is so cute and small
I have a hard stop (meeting) at 2:00. Gotta go. Have a great week! Thanks all...
@onyx hinge Thanks, we can deal with it offline.
My pleasure! Always fun.
Thanks for joining us Jason!
Isn't this what setup.py.disabled is for?
@onyx hinge Yes.
๐
A Good time was had by ...me... Thanks everybody.
Thanks!
๐
@onyx hinge Quick question -- what brought up that crazy clock link? A possible CircuitPython project?
@idle owl OK, we can pick up the topic of audio in here or in DM. Don't stay stuck for long.
@modern wing @thorny jay mentioned in his "other stuff" section that he was re-flashing the clock to turn it into a "week clock"
Ahh, nice -- thanks ๐
@modern wing It's my non CP project of the week.
I had just heard about it long ago due to the Discworld "Vetinari clock" tie-in
But I would like to be able to control the second hand of an analog clock from a GPIO.
@onyx hinge Let me at least get the rest of the code functioning on CPB and see if I manage to fix it in the process.
@idle owl sure thing
Right now I try to flash an attiny45 from my Raspberry Pi. I did that years ago, so I know I can do it... but I forgotto document it.
avrdude and the (equivalent of) 6-pin header?
Yes, I just want to make sure I connect the right pin to avoid burning it.
yeah no kidding
Can you hear me?
nope
you could make sd first, and then make flash to load the bootloader after the softdevice is loaded
@marble hornet see this? https://github.com/daniel-thompson/wasp-os
@lucid solar see https://cyanobyte.dev/ ?
@pastel panther would be interested in it too
Nice!
they chose yaml
Not sure why you shared that
- hpa:
- sum:
- hpa
- division:
- sum:
- rawComp1
- rawComp2
- valueDP7
- 16.0
- hpa:
- division:
- hpa
- 100.0
return: hpa
i think a grimace emoji is appropriate here
i.e.
hpa = hpa + (rawComp1 + rawComp2 + valueDP7) / 16
hpa = hpa / 100.0
return hpa
When I detect CTRL+C inside of python on the serial, I call mp_keyboard_interrupt() as that's what happens on the USB-CDC also. But it seems to trigger a hard fault...any ideas why that might happen?
hmm, noo. Set breakpoints at reset_into_safe_mode() and HardFault_Handler() to catch this and see what the backtrace is
Are we able to disable submodules of ulab independently?
@slender iron Yes! I did for the pine time Looks neat
Here is the notes document for Mondayโs CircuitPython Weekly meeting. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1RFV1kKlyBJfJkLivY_r_a28FFKXT83av-Wr1b4RMtu8/edit?usp=sharing
that cyanobyte spec schema is going to have to be immense...
i figure I2C is the "easy" one...
Yeah, I just wonder if any manufacturer will actually write schema themselves.
This OK as is, but fine if you address @hierophect 's style requests and I will re-review.
@tulip sleet thanks for the pointers...I know why it's not working now.
@tannewt yes, we are able to selectively disable parts of ulab. I originally investigated that as a solution, but with the new ulab.comparison module deactivated it left only about 2kB (I forget exactly) of flash free. My gut said, better to fully disable ulab on this board than return within days or weeks to revisit the issue. If we get lto and it reclaims 20+kB as I suspect it would, that would be a great time to re-revisit it. However, I can change this PR to disable as little as possi...
+print("{} bytes used, {} bytes free in flash firmware space out of {} bytes ({}kB).".format(used_flash, free_flash, firmware_region, firmware_region / 1024))
Line up these but otherwise looks great.
I think this would be class Parity and ODD and EVEN are class members defined outside of __init__.
@ionic elk thanks...now I need to code faster as I have no outstanding PRs ๐
@onyx hinge Jeff, would it be OK, if we moved spectrogram to either the fft module, or something else? It was a bit silly of me to put it into the user module.
Actually, something like scipy could make sense, and then we could dump all functions that come from scipy into that module.
or sometime that works for you? about uploading the softdevice via uf2
@marble hornet you can't upload the softdevice via uf2. You can only upload it via DFU using the bootloader (if the bootloader is there), or using a J-Link.
(@gentle bronze will be working on a self-updater, but we don't have it yet)
@tulip sleet i tried make BOARD=<watch_name> SERIAL=<device location> dfu-flash and dfu-sd (just incase) and other variations/commands.
the dfu-flash seemed to work, ie update, but circuipython still crashed when trying to use the bluetooth. is there a command
how does one upload a new sd via DFU w/out wiping out the bootloader?
i'm not sure you can. So there may be some other reason why bluetooth is not working. I am about to go afk for a few hours
dinner and a movie
thank you, i'll keep on trying / researching. have a great evening!
good luck!
thanks
@lapis hemlock it's unfortunate to move it, since users are already using the current name.
Well, they have to bite the bullet, then. It is partly my fault, I admit, but it is still a mistake.
Another option could be to add an empty user module. That wouldn't upset the current scheme.
The problem is, if user functions and core functions are in the same module, then updating code from git is difficult.
If you want to revisit it, let's talk to @slender iron about it. Maybe you can lay out what you see as the trade-offs in an issue or PR and mention us ? we can make a decision there
The last observation is the sticking point, I think.
that's what "extra" was supposed to be, a place for your users to add their own functions and not get conflicts with changes in ulab?
That was my idea, and then I added the spectrogram. .
just checking - there's no I2S in support in CP yet? only out?
If you want to revisit it, let's talk to @slender iron about it. Maybe you can lay out what you see as the trade-offs in an issue or PR and mention us ? we can make a decision there
@onyx hinge Done: https://github.com/v923z/micropython-ulab/issues/111
fyi @idle owl we can't release pypixelbuf in its current state because it'll break neopixel spi
I downgraded librarians from write to triage to reduce the number of folks who can release but you still have admin permissions that could do it.
@slender iron I haven't been releasing it. I told Dylan not to as well. Did it get released?
nope! this is preemptive
๐
Ok. Was already on my radar.
epic! you are always ahead of me. thanks!
how could one check to see if there is a softdevice on the nrf52840 ?
if they aren't sure it is on there
Hi, there. I'm using TSL2591 and it's been working but today I started getting "RuntimeError: Overflow reading light channels!" and that section of code is not all that clear. Anyone have knowledge of that sensor and can help me understand what the overflow condition is?
Looks like the constant is set to 100ms but not sure why that is and if there's any problem making it longer?
I've started to create a google sheet with potential CPY ports and their statuses. You can view/edit it here https://docs.google.com/spreadsheets/d/1vxaY6Xf1FIRPTwSZc-hnc2M3lZS9EWK31rR-7ULQS-M/edit#gid=0
I'll be adding more boards/info over the coming days.
It could also help if we add who has what boards...so if we need to test something, we know who to ask.
@slender iron @ionic elk
Hi, there. I'm using TSL2591 and it's been working but today I started getting "RuntimeError: Overflow reading light channels!" and that section of code is not all that clear. Anyone have knowledge of that sensor and can help me understand what the overflow condition is?
@timber mango Answered in #help-with-circuitpython channel.
@half geyser do you plan on improving circuitpython so it can work with the google/apple ble exposure notification stuff?
@tulip sleet when you have a chance can you test m0 master for flakiness? I think I'm able to reproduce it with master
@lucid solar Nice! Note we've already got the F412 and F411 discovery boards implemented. There are definitely some other no-brainers to implement on there, anything that's already got a supported SoC is a shoe-in. I'm not 100% on stuff like the F429 yet, just since they sometimes have breaking gotchas that can take time to resolve.
It's nice to have some idea of the scale of things, how many boards exist etc, and to see if any are interesting to port to...
We're also not prioritizing anything with less than 128K of ram, so there aren't any immediate plans to add support for the F3 series and below
Oh yeah it's a fantastic list, I was thinking I needed to put one together the other day so this is great
The reason my name is grey on some boards, is because they're in my basket ready for the next order ๐
I will add the Adafruit boards on tomorrow.
@lucid solar I'd suggest a "user RAM" column if other boards are like the STM32F405, which has 256, but only 128 is accessible to user code
@crimson ferry maybe...but this is more from a porting view....and that's maybe not interesting?
https://github.com/adafruit/circuitpython-org/tree/master/_board This isn't autogenerated right? I should add info about the STM32 boards I've ported? Of course there are other files I see need data also...
@lucid solar it isn't autogenerated
Thanks...now I sleep, have a great rest of the day everyone.
This looks good to me for merging, I'll mess with it more once it's in.
@dhalbert I can't reproduce this flakiness with a Metro M0. Most of the time it works. Occasionally, I do see the boot hang very early but I think I can get the same behavior on master. I was testing it with an Arch Linux system and a Beagle sniffing the USB traffic.
I've merged in latest master which is what I tested with. Please try again and let me know if it's consistently bad for you still. I may need your help debugging it.
This PR adds a general port-wide readme with links to resources, information on port organization, and instructions for flashing with dfu-util. It also adds a flash option to make for dfu access, make BOARD=feather_stm32f405_express flash.
Can this be //| class? My editor will want to prefix all lines with //| in one of these regions, and also it means that the first character of class will be lined up like a 4-spaces-indent of standard python code.
@tannewt It's still failing on Metro M0, somewhat more than half the time. I just press reset and see what happens. Attached is a Beagle trace from a failure.
@spice crypt those graphs look cool! Do you have any information on how you generated them?
@slender iron The goal with simmel is to provide a platform to develop on. The choice of what protocol to use seems very divisive, so the goal is to support them all. It's partly why I have the AES256 module for circuitpython.
Having said that, the Google/Apple protocol assumes you have an always-online device, which is incompatible with Simmel, which is designed to run up to 6 months disconnected on a pair of AAA batteries.
As a workaround, you could set up a server to do the polling and notification, which /is/ compatible.
how does simmel check to see if it's been exposed to someone who reports having covid?
@slender iron I'm going to stop working now for the evening, but in the morning I'd like to test MIDI with the new packet length changes. Are you talking MIDI to/from an iOS device, or are you using something else? THanks.
@tulip sleet ya, using an iPad. can you test master with usb as well?
sure, you made the interrupt change?
my branch should have current master merged in
I am just testing on my very vanilla Dell desktop, USB2, but I think it was bad on USB3 also. Were you using Garageband or something else?
I think it was a mix of synth one and xynthesizer iirc. check with @split ocean. he has better apps to test with I think
i got the Moog synth app for free when they were offering it. Are the examples in the repo a sufficient test, you think?
Moog synth app is great for testing.
@half geyser it'd be nice to have an aes module that is a subset of the one in pycrypto: https://www.dlitz.net/software/pycrypto/api/current/
I'd recommend the free MIDI Wrench to see realtime messages as well as to set up virtual MIDI ports if needed. Some apps won't connect directly to BLE MIDI devices so MIDI Wrench allows virtual wiring of all that.
I've also connected BLE MIDI to mac os machine using the Audio MIDI setup settings in the OS. I gather that it may be painful to do this in Windows.
thanks, that's very helpful. I have a 25-key controller and an older digital piano but they're all DIN MIDI or USB
i could see about Linux too. I have a Bluetooth dongle
With MIDI I feel like the age of the connector standard is proportional to the ease of use and robustness.
DIN5 MIDI, bulletproof. USB, hrm. BLE MIDI, yikes.
WiFi MIDI, RUN!
i have a simple cheap USB MIDI interface. I had an older more expensive one but it had proprietary Windows drivers (circa Win98) and I think it eventually stopped being usable all together.
I've had good luck with a cheap USB MIDI interface cable as well.
I'll certainly ask if I run into difficulties. tx much
Happy to help.
@slender iron thanks, I didn't know what the current preferred cryptography library was.
I'm seeing a lot of assert errors in tinyusb with this patch. For example:
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
process_set_config (cfg_num=1 '\001', rhport=0 '\000') at ../../lib/tinyusb/src/device/usbd.c:731
731 TU_ASSERT( drv_id < USBD_CLASS_DRIVER_COUNT && drv_len >= sizeof(tusb_desc_interface_t) );
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
process_control_request (p_request=0x2001ff20, r...
add adafruit_register and adafruit_bus_device to the frozen modules in TG-Watch02A
@spice crypt those graphs look cool! Do you have any information on how you generated them?
@half geyser These are using @slender iron 's gc activity monitor code.
Video: https://www.youtube.com/watch?v=baa5ILZTRkQ
Git readme: https://github.com/adafruit/circuitpython/blob/master/tools/gc_activity.md
Live stream of @tannewt debugging memory issues in CircuitPython.
Visit the Adafruit shop online - http://www.adafruit.com
LIVE CHAT IS HERE! http://adafru.it/discord
Adafruit on Instagram: https://www.instagram.com/adafruit
Subscr...
There are other files related to that in the tools folder
It's setup in the repo for SAMD, needs some tweaks to make work for NRF
Ah, I see. gc_activity.html in tools reads allocation_history.json and parses it into a pretty graph. That's super fancy.
The visualization in the video isn't using gc_activity.html. It uses graphviz
Here are my personal notes on how to get this to run for NRF. https://gist.github.com/k3wals/d48f49050c1d1914f8f0d3fb0314c851
add adafruit_register and adafruit_bus_device to the frozen modules in TG-Watch02A
@slender iron does MICROPY_ENABLE_GC turn in all gc or just long lived?
okay, i'll leave it be then.
the bugs we've found with it usually cause crashes
add several new submodules for frozen libraries in the TG-Watch02X boards
these include:
- Adafruit_CircuitPython_LSM6DS
- Adafruit_CircuitPython_FocalTouch
- Adafruit_CircuitPython_DS3231
- Adafruit_CircuitPython_DRV2605
- Adafruit_CircuitPython_BLE
- Adafruit_CircuitPython_BLE_Apple_Notification_Center
Still PWM is not supported. Library is supported when use pin 0-9. But, Output is not generated!!!
Please check this issue^^ I tested on version 5.2.0
Still PWM is not supported. Library is supported when use pin 0-9. But, Output is not generated!!!
Please check this issue^^ I tested on version 5.2.0
Still PWM is not supported. Library is supported when use pin 0-9. But, Output is not generated!!!
Please check this issue^^ I tested on version 5.2.0
Thank you everybody...
I want to see you version 6.0.0 ^^
@slender iron, i am running your low_power branch on the watch after implementing a screen sleep, i'll report on the battery life within the next few days
Is there a way to do something like MP_ROM_LIST()? I'm working on the crypto module, and I'd like a static list of the available sizes.
Most instances of mp_obj_list_t seem constructed at runtime.
You could do a static tuple since they are immutable
No fancy macro for it though that I know of
I think that's probably what pycrypto uses.
Are there any examples of statically allocating static tuples?
I guess it's just a len, a base, and a list of items...
Ah, MP_DEFINE_ATTRTUPLE looks like exactly what I need.
@slender iron scratch that, whenever it soft reloads the watch hangs on trying to init hardware
double checking
yeah, the non - low_power verson of the nrf52840 master hangs after a soft-reload and needs to be reset before it can re-init hardware (spi lock )
soft reload via ctrl-c, ctrl-d . do you want me to register and issue on your fork tomorrow?
@marble hornet brownout?
(gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. process_set_config (cfg_num=1 '\001', rhport=0 '\000') at ../../lib/tinyusb/src/device/usbd.c:731 731 TU_ASSERT( drv_id < USBD_CLASS_DRIVER_COUNT && drv_len >= sizeof(tusb_desc_interface_t) ); (gdb)
Also, the ASSERT that gets hit is probably due to the tinyusb process not being called often enough, causing the host to send a USB RESET, which hits this bug: https://github.c...
I chose to disable ulab altogether on the espruino pico.
This brings up another issue, which, perhaps, deserves its own thread: it would be really great, if users could customise their own ulab (or any other external module, for that matter). I have come to realise that in circuitpython the main tripping point is that the makefile, py.mk, has to be modified. Would it be possible to accept arbitrary make fragments from external modules, exactly as is done in micropython? With th...
Hi, this might be a dumb question but: I plan on buying a Featherwing prop maker. But is it compatible with WS2812 and WS2812B led strip as they both use RGBW?
@half geyser it only happens with low power, and it is pugged into 5v
Ah, okay. I ran into a problem with Simmel, but that just has to do with how I'm measuring current. Also, it's not a good idea to power it off of a pair of 1.5V Li-Ion AA batteries. The power briefly dips below 2.7V.
(Also, I discovered that the ARM debug core doesn't step into interrupts when you do stepi)
@yimidi-kr please do not spam the same comment on several repos.
[adafruit/circuitpython] Pull request opened: #2823 crypto: add initial Crypto module with AESCipher
This adds initial support for the PyCrypto AESCipher module. This
implementation supports only a subset of AESCipher modes, namely
ECB, CBC, and CTR modes.
Example usage adapted from the PyCrypto README for AES:
>>> from Crypto.Cipher import AES
>>>
>>> key = b'Sixteen byte key'
>>> cipher = AES.new(key, AES.MODE_ECB)
>>> cipher.encrypt(b'Circuit Python!!')
bytearray(b'E\x14\x85\x18\x9a\x9c\r\x95>\xa7kV\xa2`\x8b\n')
>>>
This key is 16-bytes, so it uses AES128. If...
Hi, this might be a dumb question but: I plan on buying a Featherwing prop maker. But is it compatible with WS2812 and WS2812B led strip as they both use RGBW?
@full epoch
@idle owl Maybe you know?
Note that this uses the capitalised module name Crypto to be compatible with the pycrypto module at https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.AES-module.html
I've added documentation, but I'm not sure if I documented it correctly.
@lucid solar WS2812 or WS2812B should be fine. The difference is internal and it doesn't appear the timings differ. WS2813B currently doesn't work but I have a sample and will try to make it work.
But I thought WS2812(B) were straight RGB, not RGBW. A lot of our RGBW strips are SK6812RGBW. So maybe your RGBW are not really WS2812x? There is a lot of casual use of "WS2812" when the underlying pixels are not really that type.
@brentru fyi, maybe there's other crypto algs we could add that you needed? https://www.dlitz.net/software/pycrypto/api/current/Crypto-module.html
@tulip sleet that wasn't really for me, it was @full epoch
@tulip sleet thanks for your answer. Keep me I formed please
CPython has int.bit_length(), which returns the length of the number in bits.
I wanted this because it was required by a Fibonacci number calculator I wrote. However, as evidenced by the fact that upstream micropython hasn't implemented it either, I doubt it has wide applicability, so I won't be too sad if it's not incorporated.
On a CLUE I can calculate (and even print in decimal!) fib(65000) which is 13585 decimal digits long. The calculation takes about 9 seconds. Much larger ...
I see the tests failed. It's another expected change, but for some reason I didn't encounter it locally. If there's interest in seeing this included, I'll fix it up. Otherwise, we can just close this and leave it for posterity. @tannewt thoughts?
BLE: Does the softdevice API allow obtaining the channel that an advertisment was received on? Folks over at Covid Watch have expressed an interest in this datum.
@bright aspen The channel index from the last received advertisement is available, though we don't currently pass it on to Python. https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v6.1.1/structble__gap__evt__adv__report__t.html#a7620e6f82c248bc997b212037f6ce472
You could add an issue if you want this reported up.
The protocol used by the Covid Watch anonymous exposure notification app to fight Covid-19 uses SHA256 and Ed25519 sig/ver. If a "kid-mode" of the app is implemented in CLUE or CircuitPlayground Bluefruit, those would be handy. I don't know what would be needed to implement the Apple/Google protocol; that might be a little different.
BLE: Does the softdevice API allow obtaining the channel that an advertisment was received on? Folks over at Covid Watch have expressed an interest in this datum.
@bright aspen I'm curious how this information would be helpful in the solution. Is that something you can share?
@tidal kiln you around today?
yep
can you review and test https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel_SPI/pull/15 ?
we can roll out pixelbuf once it's updated
@lucid solar I haven't had time for esp yet this week. lower_power is getting in my way
sure. looks mildy urgent? things are blocking on that?
@slender iron I'm trying another approach to how you did it...adding CPY(makefiles) to CMake instead of the other way round.
@tidal kiln if we release pypixelbuf then we'll break neopixel_spi