#circuitpython-dev
1 messages ยท Page 261 of 1
do they recommend that you tag the action in the .yml?
i think that's what you just said
ya
Looks great! Thanks for the cleanup.
If you merge from upstream and push, it will run the checks. That has worked for me.
@slender iron Would you like me to store which stm32 pins are 5V tolerant in the pin table?
@ionic elk I wouldn't bother. I'd suggest starting with just the info you need
otherwise you are using up flash space for data you'll never use
@slender iron On that note - since STM32 has all the communication devices separately, rather than in sercom units, it'd save some space if I made a new object to store the peripherals and their possible pins separately, and then had macros to whether pins exist in the peripheral object, rather than a bunch of empty slots per pin. I think that'd be more intuitive for how the pins are assigned, and it'd save kbs of space (though I guess we're less worried about that for the STM32s).
Do you think that'd be viable?
Doesn't have to happen now, just looking at all these UART1_CTS, SPI3_MOSI etc scattered everywhere and thinking it'd be nice to just have them in one condensed table.
looks at a datasheet
ya, I think it's fine to factor that info out as long as it looks the same from the API perspective
I'm having an issue with using evals. Do they work in CircuitPython?
@dull kestrel they should, but we don't use them in general
@ionic elk could you suggest a due date for the new PR. this is an estimate not a sweating deadline
Analogio?
@tulip sleet I imagine its similar to how they're used in JS. The issue is, in my current setup, I need them I think, but I tried asking over in #help-with-circuitpython and no dice
@dull kestrel I thought you meant the eval() function, which should just work, as it does in "regular" Python
@ionic elk the pin table task
Probably by tomorrow but I think it'll evolve a lot with analogio and busio
@dull kestrel I answered in #help-with-circuitpython
Analogio can function with just a per-pin definition, but busio I think is going to need a separate peripheral sorting table.
yah, that's fine, if you rough it out and do an initial PR we can kibitz on the design, maybe just add analogio and i2c or something like that
hey <@&356864093652516868> does anyone have an issue with adding kwargs for shift and lsb_value to UnaryStruct in Adafruit_CircuitPython_Register?
not me ๐
STM32 pin assignments are annoying. They skip lots of peripheral numbers, (like having only UART1, 2 and 6), the same exact pin may or may not have multiple copies across pins (SPI1_MOSI/etc all have two pin options, most others don't), and the peripherals can and frequently do exist on the same pins as others of their category (lots of SPI2/SPI3 pins are shared).
it sounds even more irregular than SAMD
Bigly
๐
I saw one CPU that was fully flexible, any pin (aside from the power pins) could be assigned to any function.
nrfs are like that
yes, they're either dedicated or any pin (but there's the dreaded "use this pin only for low speed I/O or else you'll add noise to the radio reception"
So anyway I'm thinking the peripherals go in their own table. Otherwise I'm going to either have a bajillion empty slots per pin, or skip options for pin selection that ought to be available.
Oh, good point: it would be good to have a compact, but fully generalized method of pin description, but I can't think of one!
@ionic elk why don't you do enough for analogio pins, and PR that, and then implement AnalogIn. Yes, it sounds like it has to be mapped in reverse from what we did
there is only ADC, not DAC?
Well, probably only for the communication peripherals. The ADC and timers should be ok to go in the regular way
So I can easily implement the ADC pins and timer pins and get Analogio out of the way, and then go back and make a separate comm peripheral table that'll be more space efficient.
we had a long discussion before about pin numbers vs addresses, and whether to add a level of indirection for that. Is that a little moot due to using LL?
I'm probably going to go ahead and add the indirection. My indecision about that was just some C confusion on where to add the helpers so they apply everywhere I need them.
i think that would be more straightforward in the long run
But I think a single macro that just does an address shift for these GPIO banks should do the trick in the pins.c
"by friday", did you mean tomw or next friday
Really the issue is that the STM32 hal doesn't acknowledge "pin numbers" or "pin names" at all, so a lot of the existing stuff you and Scott use has to be rewritten.
it acknowledges them in the #defines but not in the code?
It has no defines of the "#define PIN_PA4" variety at all.
It uses exclusively GPIO ports and masks
can you assign a periph function to more than one pin?
So the hal would use "I2C2_GPIO_PORT" and "I2C2_GPIO_PIN" as a pair for all the I2C2 dealings, for instance.
Yes, sometimes, sorta
wow
and that reflects the hw registers? I should read the datasheet but not before eating
If you're referring to the define pairs, yes, the first is a pointer to the GPIO port location, and the second is a 8 bit mask of that port.
Anyway, I'll probably have analogio in by monday
i'll add the due dates but you can change them as necessary
Never read datasheets hungry.
@matthewnewberg multiple color converters should work. I'd prefer it as a property and constructor argument there. That way bitmaps with solid colors can be exempt from the dithering. Thanks!
thanks for the merge @gilded cradle ! Now I can release and then bundle
Of course. Thanks for making the changes.
np, it makes the examples clearer
Yeah
@slender iron Would you rather have issues filed on GitHub that turn out not to be issues and you need to close them, or would you rather people mention it here on Discord first and then we tell them to file an issue? Trying to decide how to word an alert in the guide regarding 5.x being currently in alpha.
good question. I don't mind 1 but 2 is a good way to direct them to a better place to get help
Yeah, kind of where I was at with it too. I'll direct them here I guess and if Limor wants it changed, change it up then. The alert won't be there forever anyway, it's temporary.
kk
I'll put Discord first, and then link the CP issues anyway
I've seen #1629, saying porting the esp32 is a big task, challenge accepted.
I've start and run into a few compile issues I couldn't figured out
machine_pin.c: In function 'mp_pin_make_new':
machine_pin.c:176:30: error: passing argument 2 of 'mp_arg_check_num' makes pointer from integer without a cast [-Werror=int-conversion]
mp_arg_check_num(n_args, n_kw, 1, MP_OBJ_FUN_ARGS_MAX, true);
^
In file included from machine_pin.c:34:0:
../../py/runtime.h:80:6: note: expected 'mp_map_t * {aka struct _mp_map_t *}' but argument is of type 'size_t {aka unsigned int}'
void mp_arg_check_num(size_t n_args, mp_map_t *kw_args, size_t n_args_min, size_t n_args_max, bool takes_kw);
^
machine_pin.c: In function 'machine_pin_call':
machine_pin.c:200:30: error: passing argument 2 of 'mp_arg_check_num' makes pointer from integer without a cast [-Werror=int-conversion]
mp_arg_check_num(n_args, n_kw, 0, 1, false);
^
In file included from machine_pin.c:34:0:
../../py/runtime.h:80:6: note: expected 'mp_map_t * {aka struct _mp_map_t *}' but argument is of type 'size_t {aka unsigned int}'
void mp_arg_check_num(size_t n_args, mp_map_t *kw_args, size_t n_args_min, size_t n_args_max, bool takes_kw);
^
machine_pin.c: At top level:
machine_pin.c:333:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.make_new = mp_pin_make_new,
^
machine_pin.c:333:17: note: (near initialization for 'machine_pin_type.make_new')
machine_pin.c:414:13: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.call = machine_pin_irq_call,
^
machine_pin.c:414:13: note: (near initialization for 'machine_pin_irq_type.call')
cc1: all warnings being treated as errors
../../py/mkrules.mk:55: recipe for target 'build/machine_pin.o' failed
I've looked over at the esp8266 port, and this code looks identical around those two functions
yeah now I've seen the message when trying to compile esp8266
"CircuitPython 4.0.0 and later do not support esp8266 boards."
Question: What libraries should I be using to test 5.0.0 alpha2? Using the latest bundle on a pyportal I still see a call to refresh_soon(), which fails the initial call to setup the Pyportal (i.e. "pyportal = PyPortal(default_bg=BLACK)" ) SHould I open an issue on this?
@idle owl re: pointing ppl to discord over issues -- maybe put something in the issue template?
@exotic pumice We've avoided issue templates because they often result in issues containing only the template and no new information. We're quick to point people to Discord where it makes sense, so we've made it very visible.
re: @timber mango 's question... There's probably a plan already, but maybe one issue (perhaps with a checklist like featherwings had) to handle the bunch of libraries, examples, guides, etc. that need their displayio updated to the refresh() model? (Dave, for now I believe you have to download the .py of the library and remove any calls to wait_for_frame() or refresh_soon() ).
ok, will do. Thanks
For 5.0.0-alpha, see: refresh() and auto_refresh here: https://circuitpython.readthedocs.io/en/latest/shared-bindings/displayio/Display.html
@exotic pumice a question, wouldn't be clearer to remove esp32 and esp8266 directories, if it's not supported anymore ?
Probably, not my call
Pro tip: when your code is being ignored, and you know it works, maybe check that you didn't somehow add a space to the beginning of the name code.py. ๐คฆ
@lapis charm Having the directories available makes it easier when merging from upstream. We merge from upstream MicroPython when it makes sense, and having the same directory structure keeps it simpler.
@idle owl ooh, those upstream merges must be painful anyhow, I can see how this can elevate some of the pain.
Quite.
that's a shame, I wanted to take circutpython for a ride after hearing more about it in test&code pod cast
but I only have esp32 / esp8266 / pyboard v1
You could get an ItsyBitsy m4 or something. Pretty cheap
What's smaller than a Feather but larger than a Trinket? It's an Adafruit ItsyBitsy M4 Express featuring the Microchip ATSAMD51! Small, powerful, with a ultra fast ATSAMD51 Cortex ...
Cheaper than an arduino uno and 1000x the power lol
esp architecture is pretty whack
the esp wer'e cheaper and had wifi built-in. if i'm putting a bit more money, i'll go with https://www.adafruit.com/product/4242
anyhow, that's for the help. have a good day/night
I may have seen this on one of my custom boards that has no on-board status led but the board defs are set to use a normally attached dotstar string. If I recall correctly when I fill'd the strip the first dotstar would remain a status indicator.
@lapis charm we're pretty close to supporting the very basics of the pyboard
@idle owl do we need the debug_bus_device and debug_i2c repos? they are empty
@slender iron Yeah, they are still in the works, but aren't a priority so Limor had me waiting on them. They will eventually be a thing.
Right on. Thanks!
np, addin einks
@slender iron Any reason why analogio wouldn't work the same on nRF? The potentiometer example isn't working on Bluefruit. Works on CPX with the same hardware.
It's running, but it's acting like nothing is connected. It's returning the same thing as if it's simply floating.
Not sure, will check now
Light sensor appears to work.
Temp sensor uses thermistor?
Hold on.
Yes, light and temp sensors work.
hrm, weird
Tried on multiple pins.
I'm not home now but I might be able to try it on a cpb in an hour or so
@onyx hinge That would be great. I have two here, I'll try it on the other one.
I might not be around, but please let me know what you find.
I'll report here
https://learn.adafruit.com/adafruit-circuit-playground-express/circuitpython-analog-in is what I'm using.
Make faster and easier than ever with MakeCode, code.org CSD, CircuitPython or Arduino!
Same results with both.
@idle owl seems to be working for me? just testing analog in on a CPB?
Adafruit CircuitPython 5.0.0-alpha.2 on 2019-09-04; Adafruit Circuit Playground Bluefruit with nRF52840
>>> import board
>>> from analogio import AnalogIn
>>> pot = AnalogIn(board.A2)
>>> pot.value
96
>>> pot.value
20096
>>> pot.value
29920
>>> pot.value
44544
>>> pot.value
54112
>>>
@tidal kiln Yeah... I tried on two separate boards. The potentiometer works on a CPX fine...
weird. do you have an early board rev?
Got it in the first batch from the store.
same here
Then unlikely to be a different rev.
Ugh.
The potentiometer is soldered to alligator clips. There's so little to it, why would it work on a CPX if it wasn't going to work on a CPB, and why the same results on two different boards. Does analog work differently on the nRF and for some reason would render this potentiometer useless? I'm confused.
I need to head out for the night.
I'll pick it up again tomorrow. Thanks for testing, @tidal kiln
ok. np. gotta be something simple.
yah, all seem working for me, tested A1..A6, all good
@onyx hinge FYI ^^ worked for @tidal kiln. So it might be a me problem. Please test it anyway and report back what you find. Thanks!
I'm seeing 0 or a value close to it when I connect A2 to GND, and 60000 or a value close to it when I connect A2 to 3.3V
and seeing intermediate values with a potentiometer
so in that configuration, I connected the outer legs of the pot to GND and 3.3V, and the middle leg to A2
I ran a manually typed in program like cater did fwiw @idle owl
Excited to see this! Will test tomorrow (hopefully) and then share w/friends in the XAC community!
@dhalbert is there a version of Gamepad that matches the XAC gamepad?
@ATMakersBill Yes, see the top post. You can do (in, say, mpconfigboard.mk
USB_HID_DEVICES = XAC_COMPATIBLE_GAMEPAD
and get a single XAC gamepad without a report ID. Use your XAC-compatible Gamepad.py. I plan to test this soon.
Sorry, I meant was there an updated HID library with an XAC gamepad. I can test with mine, but was wondering how that would be added to the libs
morning
Building the current master yields this warning for stm32f412zg_discovery.
Is something missing in the bsp?
Build stm32f412zg_discovery for en_US took 29.02s and succeeded
make: Entering directory '/home/jerryneedell/circuitpython_master/ports/stm32f4'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
GEN build-stm32f412zg_discovery/genhdr/moduledefs.h
QSTR updated
../../supervisor/stub/internal_flash.c:52:16: warning: 'conver...
Nope, I didn't add anything yet - just use your library for now. It will probably be a separate library, because adding it to frozen HID will make HID even bigger and take more flash, which is a problem on CPX.
Piggybacking on (@crimson ferry and @timber mango)'s thread regarding displayio and 5.0.0-alpha, I am seeing the "wait_for_frame()" error. @crimson ferry , you recommended grabbing the .py library and removing the calls, but isn't displayio a core module? How can I do that? Thanks!
Those calls appear in some bundle libraries like PyPortal, PyBadger, etc (and if people have grabbed examples from the libraries or Learn guides).
I see.
A-HA! Perhaps I should read the stack trace more closely.
Right there in adafruit_pyportal.py. I am back up and running. Ugh. I'll be more diligent next time. ๐ Thanks!
grep of Library Bundle shows those two calls (wait_for_frame, refresh_soon) used in:
pyportal (drivers and helpers)
miniqr/examples/
turtle (drivers and helpers)
display-text/examples/ (drivers and helpers)
pybadger
pyoa (drivers and helpers)
slideshow
``` issue submitted
Yes, I commented the wait_for_frame() calls out. Interestingly, it's not choking on the refresh_soon() calls.
Your code is definitely hitting the refresh_soon() calls? I wonder if it's aliased or something. It's not in the latest readthedocs: https://circuitpython.readthedocs.io/en/latest/shared-bindings/displayio/Display.html
Hello. ๐
@crimson ferry - Looks like it is not executing those calls. The only call to wait_for_refresh() I had to comment out was in the play_file() function. There's no refresh_soon() call in there.
Resolves #2122. Removes an unnecessary function in the new flash stub file that causes a compiler warning for boards that use it.
Why don't you just comment it out, because it will need to go back in when the stub is implemented, I think?
Why don't you just comment it out, because it will need to go back in when the stub is implemented, I think?
It isn't strictly universal, the implementation and naming differs across the nrf and atmel ports. It also isn't a part of the API. We could keep it, but should we also update nrf to match?
@tulip sleet the reason I posted the stm32 waring issue was that it only appeared for that one BSP -- did that make sense to you?
is that build the only one that uses that file?
OK, seems fine. I'm not sure why the build isn't throwing an error on the warning. It's worth doing -Werror in the makefiles for stm32f4: we do that for the other ports, because a warning indicates a possible problem, and ignoring them on builds can miss errors. If we need to turn off a bogus warning, we do (for example):
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wcast-align"
// code giving a warning
#pragma GCC diagnostic pop
That's a good reminder. I removed that a while ago since it was getting in the way of very early port work. Now that things are cleaned up it should go back in.
@solar whale makes sense, and I think it's good to fix - tnx!
@trail pike hey hey... fancy seeing you in here. ๐ How're things..?
@plucky flint g'day! Things are good. Reading circuitpython.
Nice... are you doing PyWeek?
@trail pike BTW it was the ldnpydojo 10th birthday last night.
Are you? (hoping to! Let's see if the freelance gods line up to let me have time off)
We hacked together a bunch of Instagram like filters using pillow and numpy in Jupyter notebooks. ๐
I was trying to get OpenCV to identify eyes in faces so I could automatically stick on googly eyes. ๐
We used our current PM as the test subject in the photo. Which was pretty hilarious.
ldnpydojo is something special. Haven't found a group quite like it.
Yeah... we had about an hour of reminiscences before we actually got to coding. Lots of really cool stories, memories and some emotional moments too.
Drifting on topic a little bit... is there a doc which answers the question (or part of)... "How is circuitpython tested?"
I'll be doing PyWeek - I want to use it as an excuse to make a game with my goofy hack on PyperCard. I'm thinking of making a Myst clone (originally created in HyperCard FWIW) called "Missed". ๐
@trail pike CircuitPython is a friendly fork of MicroPython. There are docs on micropython.org for devs which contain details of how it's tested.
Oh... a myst clone would be grand.
As for CircuitPython specific stuff I'm less clear (at the moment), but the folks here will be able to point you in the right direction
Does PyperCard have a zen mode? I really liked the black&white look.
Hah... you should check out the Adafruit original.... https://learn.adafruit.com/circuit-python-your-own-adventure/writing-an-adventure <- very cool hack. If you'd watched me while reading this blog post you'd have seen a lightbulb flashing above my head, just like in cartoons. ๐ ๐ก ๐ค
...and then I got a bit carried away making something similar for desktop and mobile (it's a simple shim around Kivy)
Ideal for beginner programmers.
Anyway...
Coolest hack. I remember you mentioning you were going to make it at EP.
Yeah... well I need to get the docs finished for next Friday, I'm trying it out on a class of young coders in an evening class. Let chaos reign. (Actually it'll be really useful to see the bumps in the road, get feedback and check the hunch about such a simple model for UI work is easy to both teach and learn).
Did you consider removing some capital letters?
Can't really find any documentation on the release process or how micropython is tested either. But the travis file has a bunch of interesting bits in it. https://github.com/micropython/micropython/blob/master/.travis.yml
Capital letters..?
@trail pike start here..? http://docs.micropython.org/en/latest/develop/index.html <- links to guides and other fun docs.
Ah, there's not that many Capital letters in there, because mostly it's done through json and python classes are avoided?
OK... I've lost context. Capital letters where?
(because, I think python made the mistake of using Capital letters as is done in Dutch for nouns, so many sentences have lots of Capital letters in there if classes are used)
Ahh
But also typing capital letters is harder.
But capitalisation makes reading easier. There's some sort of karma going on there... ๐
@trail pike we keep the micropython unit tests going but the hardware apis are only tested by hand
I was just on the Test and Code podcast and we talked about it there a bit: https://testandcode.com/84
Adafruit enables beginners to make amazing hardware/software projects.
With CircuitPython, these projects can now use Python.
In this episode, Scott Shawcroft, the project lead, talks about the past, present, and future of CircuitPython, and discusses the focus on the beginner.
@slender iron interesting. Thanks ๐
@tidal kiln @onyx hinge I'm at a loss here. It worked for both of you. I have two boards exhibiting the same behavior. I eliminated the potentiometer and jumpered A1 to 3.3v. It acts like it's grounded, returning 0.01ish or 500 depending on whether I'm using the helper function or the raw value. If I ground it, no change. If I connect it to VOUT, it returns 2.2V or 44k. I tried it on a different laptop with a different USB cable. I've tried both with code.py and the REPL.
You're both also using board from the same batch as far as I know.
Ok, I just tested it on A2-A6, and it works.
Are you sure it worked on A1 for you?
I think I tried A2, but let me scroll back....
you can see from my photo last night that I used A2
I think it's what @tidal kiln used too
@tidal kiln Said he tested A1-A6.
(โฏยฐโกยฐ๏ผโฏ๏ธต โปโโป
It's got to be something with A1.
I'll ask Limor.
is there a pdf or png schematic? which pin is for SDA/SCL?
okay so it's nothing to do with i2c pull ups
The schematic is in the guide but the guide isn't done yet.
on the schematic I only see the connection to the microcontroller and the pull down resistor
I was going to check but figured it was going to be too complicated for me to grok
I'll trust your take on it
Conclusion: it doesn't imply anything is weird
Yeah
So either there's an issue with these boards I have which is possible, or A1 is weird.
what I did was, open it up in eagle, go to the scmehatic, and in the commandline type "show a1"
all the wires and pads on A1 get highlighted
I've never used the command line in Eagle. I should probably look into that.
I usually click "info" and then click the thing I want to see
GUI TOWN.
like all commandlines it can make SOME things a ton faster
I won't be home until later this evening, but if I haven't updated you with findings about A1 on my device, please ping me about it
OK folks... I'm stepping AFK for the weekend. Thankyou for your help and advice about circup this week. ๐
@plucky flint Have a lovely weekend! I'll try to take a look at it soon and give some feedback.
also confirming from the schematic it looks like the "TX" pin is maybe not digital capable -- it's called "D1/TX" as a net name
@onyx hinge Yeah, I noticed the silk doesn't say A7. Need to verify that with Limor and change the guide because I copied most of it from CPX.
@idle owl ๐
Bit of a noobie question here but is using binary constants via gcc frowned upon? Doing a lot of mask work so it sure seems like they'd be nice for visualization.
I've used them occasionally in personal projects where I wasn't worried about portability, but it sounds like they could cause damage in larger projects.
Hi Melissa,
we updated the picture.
Ready for merging. Thanks
Would it be possible to make the images a little smaller? Here's a page that describes preparing the images. I just want to make sure your product looks great. Thanks. https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/preparing-the-images
@tidal kiln A1 doesn't work right. The pin assignments are wrong. Dan and Bryan both had the same results I did.
@onyx hinge ^^
@tulip sleet that werror hotfix has passed CI by the way
@ionic elk You mean writing numbers like 0b10110 ? As far as I understand it, these are not a part of the any C standard. However, in practice, CircuitPython is only buildable with gcc. It looks like there are already a few uses of this extension, see PixelBuf.h
@slender iron might have a preference to avoid it though .. comments?
@onyx hinge good to know. I'll check out the PixelBuf. Don't have any current urgent use for it but it'd be nice to know the precedent.
@idle owl sry. i'm afk for the most part today. got a sec right now though. let me double check it's working for me...
@tidal kiln No worries. There's nothing to try. We found the issue. Testing the update right now.
A1 and A5 were assigned to the same thing, A1 wasn't useful for anything as it was.
ok. yah. i'm seeing that too. A1 is wonky.
tested real quick the other day...must have thought the changes were real.
and this makes sense then...
>>> pot = AnalogIn(board.A5)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: A1 in use
sry for the mis-info. glad it's been found at least.
Thanks for checking again.
- A1 was mistakenly mapped to the same pin as A5
- A7 shouldn't exist: we don't have enough analog-capable pins.
Tested successfully. Thanks for sorting out what was going on!
@slender iron where can I find docs for using a ssd1305/6 oled with 5.0?
@ionic elk I'll merge #2123 after the latest PR finishes. We are running into the problem that check runs can have their commits disappear out from under them if there's another merge while they're running. Did you see that further back here.
@tulip sleet that's right we ran into that yesterday.
@pastel panther https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SSD1306/blob/master/examples/displayio_ssd1306_featherwing.py
@slender iron thanks; looks like this particular display needs a different setup as it's lighting up a few random pixels but not displaying text that is printd
Had a similar thing on arduino so I'm pretty sure it's not CP
which display is it?
I take it back
it's the large oled bonnet
I think my "hello world" scrolled off the screen when the script ended
which display module is it?
kk
ssd1305 is the controller ic. usually the display has its own datasheet to describe how it's all hooked up
there are a few rebellious pixels on the right side that I'll have to figure out how to address
oh right, sorry
๐
Smarter Shopping, Better Living! Aliexpress.com
the pixels are probably do to the width being wrong
I have it set to 128x32; do you think it's not working?
try setting colstart to 4
that did it ๐
the ram of the ssd1305 is 132x64
I wouldn't mind having a separate driver for the 1305 too
it'd make it easier to find
ya, that sounds good
Will merge after @kattni finishes testing the rest of the board functionality.
Has external ram for circuitpython ever been considered? There's a couple of STM32 Discovery boards that include it.
@ionic elk we would certainly consider it for chips that support it. Up to now there haven't been some. It would be for F7 and similar chips.
in a lot of cases those chips have minimal on-chip RAM so it's basically required
An F103 Bluepill with 2MB of ram ๐ค ๐ค
can you execute from the external RAM?
That I'm not sure.
It just has a FSMC controller
I'm not sure it can extend directly off system RAM. Might be why micropython hasn't done it
sounds like it would be OK, but I don't know how fast it is
ah, ok, it's serial, so it might be pretty slow to use as regular RAM
Some (not all) STM32's have FSMC mapped to an address space (at 0x60000000).
good for displays without their own ram
^yes that seems to be what it's primarily used for
I wonder, though, if there'd be some way to have it link into the core, given that CPy has to store everything in RAM
_Note two serious problems with running from external SRAM:
It's going to be slow. Like 6...8 times slower than running from flash or even internal SRAM according to this. This microcontroller architecture simply isn't optimized for this kind of use.
Some STM32 chips have a silicon bug where FSMC access by two bus masters crashes the chip. This will basically preclude you from using DMA. This concerns STM32F103 revision Y IIRC, probably other chips too._
it is an interesting q about how much slower it would be to use as a destination for importing code, since a lot goes on after reading a bytecode
@tulip sleet I'm guessing I'm conflating two things, but doesn't samd51 support execution in place from qspi?
yes, it's "XIP". We don't execute code from RAM very much if at all, though MicroPython has ways of including assembly code, so it's possible. But here I'm talking about import an .mpy into the FSMC memory, where it would be read as bytecodes to execute.
<-- attempting to take that as a learning opportunity rather than "I has the dumb".
I think I understand, mostly
thanks
@slender iron will you have time later to give me the high level of what would be needed for a displayio ssd1305 driver?
A couple minor documentation/API things. Otherwise, I think this is very close! Let me know if you'd like to make the changes. I realize it's been a lot of back and forth. Thanks!
Please rephrase for ColorConverter
Please swap the arg parsing here to mp_arg_parse_all. It will allow it to be a kwarg rather than positional only like this code. Here is an example: https://github.com/adafruit/circuitpython/blob/master/shared-bindings/busio/I2C.c#L66 This dither arg would be like frequency in the example. I'd do it as kwarg-only too so it's always dither=True rather than True on it's own.
Please also document it in the //| section above because it is used for our ReadTheDocs documentation.
@pastel panther I'm headed out early for a party so the next hour or so is all I have
basically it's copy and rename ssd1306
@slender iron that's easy enough. I was thinking some more init tweaking needed to be done but I can figure it out
ya, I usually get the init sequence for a datasheet flow chart or sample code
remember that things like colstart are not a property of the IC but rather how the IC is hooked to the display
ah, interesting. I did not know that.
I shall consult the 'duino driver and datasheet later tonight. thanks!
@pastel panther the only thing you have to do is to reset, switch off, enable charge pump, and switch on
All the rest are just fine tuning and tweaks
@stuck elbow fair enough, but in my case it's the "fine tuning tweaks" that are the issue ๐
Why?
Is that a reflection?
no
I didn't know those displays had grayscale
I'm not sure that's what's happening
when I saw something similar with the arduino driver, it was smearing "down"
Too high contrast?
possibly, I'll have to dig more later. thanks
@tidal kiln hihi
@idle owl do you need any more info from me about the CPB analog in, or did you solve it?
@onyx hinge We solved it! The board def was wrong. A1 and A5 were on the same thing.
@meager fog ping
@idle owl yeah! good test / good catch
@tidal kiln ah i assigned it on basecamp
this person fixed the neotrelis but didnt do a PR
ok. seeing it in basecamp. is there a related github issue?
is not!
where's the fix? not seeing any link?
In one of the SSD1675 examples, epd_reset (D5) and epd_busy (D6) are used, but not in the other. But aren't those EPD pins really for SRAM and SD on the FeatherWings?
@ionic elk ihii
i just got a discovery '412 ๐
tell me what to do and ill test! do i upload with st-link?
exciting
You actually won't need st-link at all
it's mbed compatible so you just drag it on in there
the bin file from s3?
Is s3 a release? behind on lingo
I think that should work. There's a chance that it might have been broken by Dan's HID update, I didn't have the chance to fully test that out. But it should work with the defaults.
ok so then what ๐
Sorry, double checking things, it's been a little while since I got to work on it.
Ok. For now, compile the board using USB=FALSE. Then, you can use the built-in UART available on the CDC line to the st-link.
You should be able to view that with a standard terminal. I'd just ignore the "user USB" until Thach and I get a chance to hack at that again.
Sure.
๐
OK, here you go. Just tested it, should be good. Baud is 115200
Note: there's a buffer bug that deletes every 10th character when copy-pasting into the repl, and can even crash in extreme cases. It won't bother you if you just type. Wasn't a very high priority fix since the whole system gets replaced by USB later anyway.
@meager fog just let me know if you have any issues and I'll check it out.
@ionic elk ok burning!
when i drag over the bin it doesnt reboot
is that normal?
looks like red, orange, green leds are lit
how do i get to the repl
thru the stlink USB?
Yes, there should be a CDC line with the UART interface
Not sure what terminal you use - it's tty.usbmodem1411203 for me
HOORAY
are the 'duinoy headers like D12 in board?
ok great, whats keeping USB from working?
We're not sure - I was running into kind of obscure register differences between the F412+ and the ones under it.
ok so to be specific, F412 does not work for USB at all even with tinyUSB
yes
F405 and F411 do work with tinyUSB
I haven't gotten the F405 BSP in yet but it shouldn't be a problem, and the F411 is done, yes
for f411, you have the circuitpy build and USB enumerates and you get USB repl?
Thach needed to make a new BSP for the F411 before that one worked as well.
F411 has full CDC and MSC flash support - it'd have HID too, but the F411 doesn't have enough endpoints for it
ahh ok
fascinaing you cant program the F411 firmware in and have it 'just work'
odd but ok
is there an issue for the F412 tinyusb failure?
Yeah it's a pain! As are... many things with ST
I'm not sure we've made one I could throw one up there. But I think Thach was planning on wrapping that up pretty soon.
Will do.
https://github.com/hathach/tinyusb/issues/103 looks like the existing issue
?
please add a note it doesnt work at this time ๐
Where would you like the note? Github, comments, documentation?
@ionic elk now that i htink of it, it should be an issue in circuitpython and link to that tinyusb
so you get a notice when thach closes it
and then you can re-try
ook good news i have a low cost stm32f411 dev board
Should be updated once https://github.com/hathach/tinyusb/issues/103 is completed.
theres no bootloader for the stm32f411 i have, can i prog the bin with stlink? what address does the bin go to, 0x0?
@ionic elk ^ if ya know lemme know
This PR reorganizes pin storage on the STM32 boards to be more space efficient, and includes analog pin information.
rockin' out those fast & furious PRs!
@meager fog yeah the F411 doesn't have mbed so it needs a tool. I use https://github.com/texane/stlink, but ST also has a flash utility tool https://www.st.com/en/development-tools/stsw-link004.html
@ionic elk all good we stock 'em
i use them a bunch ๐
btw there's adalink if youhaven't seen it yet
makes it ez
Gotcha - to be clear the board still has an stlink on it, you just gotta use the command line since it doesn't have the mbed boot filesystem. Do you recommend most users to the official ST tool?
st tool works great - i think its win only?
yeah
yah adalink is python so great for automation
ill test the stm32f4 PR
good excuse ๐
I actually JUST found a new bug on it so it might be better to wait until tomorrow.
Somethings claiming pins incorrectly. Only happens for some of them though so I missed it at first.
Gotta head out for the night but I'll be back at it tomorrow.
@ionic elk ill just try it for the sake of tryin
@gilded cradle do you know if having two Displays works? like one on SPI and one on I2C?
I'm assuming you mean in CP and I'm not sure. I haven't really touched the I2C displays, but theoretically yes since you can do it in arduino.
ok, thanks
I gotta learn how to upload a fresh .elf file from within gdb, resetting my session because I have to exit gdb, stop the j-link gdb server, perform the flash, and then put everything back together .. is no good. Anyone have a recipe for commandline / terminal gdb? I'll read back after making breakfast, this is just a drive-by question.
you mean I have to research it for myself ๐
maybe it's just "load"? I'll try it next session.
yeah it's just load
nRF I2S.CONFIG.MCLK looks kinda-sorta like it's an integer clock divider .. but .. it isn't.
16MHz * (0x80000000 / 0x50000000) isn't 10.666667MHz (it's 10MHz), but programming 0x50000000 gives you 10.66667MHz anyway!
smh and taking a break
Would it be a reasonable issue to add to imageload for support of True color BMPs? Or is there a better way than doing everything within a with open("/truecolor.bmp", "rb") as bitmap_file: construct? (I need it in memory and I don't think we have deepcopy)
hm, I have my world clock and bit clock clocking like I would expect for a 44.1kHz, 8-bit stereo signal
but the supposed data out is not synchronized to them. It's just a square wave at close to 1MHz
bit clock, left/right clock, but not i2c data
also, when I cleared out the PSEL for that pin, the scope didn't change, so .. where's this 1MHz signal coming from? Not I2S I guess.
okay, hm, still not sure, but a reset fixed it. now it looks like we have data and it's stable in relation to the clocks.
looks like maybe there's a bug where a soft reset can leave pins associated with PWM instances
and I guess maybe PWM takes precedence over I2S in whatever the output pin switch matrix does
alright, I'm just "DMA'ing" the same single sample over and over again, but when I change it via the debugger it changes on the scope so the next step of playing an actual sample should be pretty quick.
2nd of a larger series of very simple apps working with the BLE to help spur development on the Bluefruit. https://github.com/mytechnotalent/CircuitPython-BLEThermometer/tree/master
FYI I made the requested change https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/pull/39
This is an implementation of json_transform (was json_transforms) described in #38.
Developed for and tested with nasa.py a new version of NASA image viewer from Adafruit Learn: PyPortal NASA Image...
I have a CircuitPython / REPL question:
I am trying to read back the console through the USB COM port (COM2). This is not an issue. I just use pyserial on Windows and it reads back.
The bit I am struggling with is sending commands to the console. I think my issue is that I am sending encoded data to the console and it doesn't know what to do with them. Does anyone know how I can send text to the REPL / Console for the CircuitPython board over a serial-like connection?
Windows:
import serial
test = serial.Serial("COM2", baudrate=9600)
while True:
test.write("\n".encode('utf-8'))
status = test.read()
print(status)
CircuitPython:
while True:
data = input("Data: ")
print(data)
I cracked it! The REPL expects /n/r as the return character!
@craggy galleon you can also use the "raw REPL" that's designed for machine-to-machine. example of usage: https://github.com/adafruit/circuitpython/blob/master/tools/cpboard.py
Automated Libraries update for 08-Sep-19
ugh that's not a sine wave! ๐
okay, THAT is a nice pure tone
๐
there is a little bit of scratchiness on top of it that I wish wasn't there, but I don't know what to expect of this i2s amp. I should test it on a samd part.
well that's the first time I lost progress with git in quite some time. My computer hard-locked very shortly after doing a WIP commit ๐ฆ
error: object file .git/objects/7e/b3549cd8b21c9429dcc1e4a33bfc1b1707023a is empty
error: object file .git/objects/7e/b3549cd8b21c9429dcc1e4a33bfc1b1707023a is empty
fatal: loose object 7eb3549cd8b21c9429dcc1e4a33bfc1b1707023a (stored in .git/objects/7e/b3549cd8b21c9429dcc1e4a33bfc1b1707023a) is corrupt
git log, git reflog, etc all fail
@ionic elk stm32f412 discovery board is ported https://github.com/hathach/tinyusb/pull/120 It has more endpionts than 407,411 on Fullspeed core. Therefore it could work with cpython hid ๐
sorry for the wait, being a bit busy lately ๐
forgot to mention, you need to put jumper to JP3 (USB) on the board, it is left open by default.
sigh, why am I stuttering when playing 22050Hz samples. Surely my code's not that inefficient.
SD card delays?
it's the QSPI (I assume) internal to the particle xenon
I would have also assumed it was plenty fast enough at this task
<@&356864093652516868> Here is the notes doc for tomorrow's CircuitPython Weekly meeting at 2pmET/11amPT. Everyone is welcome! Please add your hug reports and status updates before the meeting, even if you'll be attending - it's super helpful! If you're missing the meeting and you'd like to include your updates, add them to the notes and we'll read them off. Hope to see you there! https://docs.google.com/document/d/12p4adKbmLf-2QIu2vdvnRw98MfD1jh-mLwq-OXcXxRY/edit?usp=sharing
@onyx hinge re: "computer hard-locked" - are your hard disks/ssds healthy?
@simple pulsar well, it seems to be mostly correlated with circuitpython hardfaulting and dmesg implicates USB
Oh, unfortunate, is this on linux?
"Sep 8 12:40:58 soba kernel: [80072.030802] RIP: 0010:usb_clear_halt+0x16/0xc0 [usbcore]"
yeah
I'm thinking out loud here but it feels like the driver should be robust for any usb badness going on. Have you got the CIRCUITPY drive mounted?
sometimes, and/or I'm using the serial console
I've nothing useful to add here. I only asked about SSD/etc because I was surprised last year when my first one failed after reaching EOL. Not surprised that it failed just surprised by Windows (on a desktop) doing a wide range of bizarre things with no user notification of impending doom or first signs of doom. I thought in 2018 that might have been basic functionality.
instead of actually characterizing the problem I just complain on chat ๐
smartctl data all looks OK
I do intend to replace the whole system later this year so if it is the HW so be it
and I appreciate you trying to make me be systematic about a problem I reported ๐
hm would an attached j-link affect performance if no breakpoints are being hit? I can't reproduce my choppy audio anymore ๐
I might have had a hardware watchpoint and certainly some breakpoints set "before"
Testing performed: I used a Particle Xenon with a HDA1334 I2S DAC. I played a variety of mono 16-bit samples at 11025 and 22050Hz nominal bit rates. With this setup, all the 11025Hz samples sound good. I tested play, pause, and loop functionality.
During some runs with 22050Hz samples, there were glitches. However, these may have only occurred during runs where I had set breakpoints and watchpoints in gdb.
I also tested with a MAX98357A I2S amplifier. On this device, everything sou...
how likely is it that doing "a lot" of read activity from CP (I2SOut) would "starve" the device so badly it couldn't USB-enumerate?
I'm seeing that when my code.py starts playing such a file, linux just can't enumerate it
just using a different (e.g., 22kHz mono instead of 44kHz stereo) file "fixes" this
@onyx hinge we've encountered this kind of problem before: https://github.com/adafruit/circuitpython/pull/901 but this was on atmel-samd before tinyusb. nevertheless the usb irq prio may be an issue. I remember adjusting this myself as well, I think in a different situation.
Run till exit from #0 audioio_wavefile_get_buffer (self=0x20008280,
single_channel=false, channel=<optimized out>, buffer=0x20008210,
buffer_length=buffer_length@entry=0x2003ff74)
at ../../shared-module/audiocore/WaveFile.c:210
0x0005e4a8 in audiosample_get_buffer (sample_obj=<optimized out>,
single_channel=single_channel@entry=false, channel=channel@entry=0 '\000',
buffer=buffer@entry=0x20008210, buffer_length=buffer_length@entry=0x2003ff74)
at ../../shared-module/audiocore/__init__.c:110
110 return audioio_wavefile_get_buffer(file, single_channel, channel, buffer, buffer_length);
Value returned is $8 = GET_BUFFER_MORE_DATA
(gdb) p *buffer_length
$9 = 0
``` hm now I am having a problem with audiosample_get_buffer returning 0 bytes at a time.
f_read from the wavefile returns 0 for some reason
oh it's another corrupted wav file
cp: error writing '/media/jepler/CIRCUITPY/stereo44.wav': No space left on device
I think my problems were bad wave files mostly. What a pile of wasted time
I bet for other audio outputs this was not a "fatal" error. Mine calls over and over again until a desired number of bytes are made available.
When given a bad (truncated) wave file, audioio_wavefile_get_buffer can return GET_BUFFER_MORE_DATA but set buffer_length to 0.
Run till exit from #0 audioio_wavefile_get_buffer (self=0x20008280,
single_channel=false, channel=<optimized out>, buffer=0x20008210,
buffer_length=buffer_length@entry=0x2003ff74)
at ../../shared-module/audiocore/WaveFile.c:210
0x0005e4a8 in audiosample_get_buffer (sample_obj=<optimized out>,
single_channel=single_channel@...
I'm considering buying an Arduino Nano 33 BLE (based on nRF52840 with a 9-axis IMU) - I want to experiment with sending IMU data via BLE. I would like to develop using circuitpython, but on circuitpython.org I see that the Nano 33 BLE is not a supported board. Is anyone working on providing support for it?
@shy kiln good question -- I'm not familiar with the module. I don't see any signs that support for this module has been started. I suspect that someone familiar with circuitpython and uf2 bootloaders would be able to create support for the board, but there could always be unanticipated problems.
In the "good" case it would be less than 300 lines of code to write
based on the amount of code added in CircuitPython for the Particle Xenon
hmmm I think all the CircuitPython boards may have QSPI flash modules, reserving the full 1MB for CircuitPython code. checking..
@shy kiln @onyx hinge all our boards do have flash. We have a build for PCA10059 which does not have external flash, so that could be adapted to the new board. Could also buy our board and a 9-DOF breakout
the accelerator is supported https://learn.adafruit.com/adafruit-lsm9ds1-accelerometer-plus-gyro-plus-magnetometer-9-dof-breakout/python-circuitpython
@tulip sleet I was just checking that. What defines the amount of storage reserved for CIRCUITPYTHON in the PCA10059 board?
ah is it LD_FILE = boards/nrf52840_1M_256k.ld ?
yes, I was just going to paste that path
that .ld file is specified in the mpconfigboard.mk file
ugh somebody needs to make a board revision to move that silkscreen label CSAG. ๐
I think the CSAG is lower deliberabtely to differentiate from the adjacent labels
or am i missing a joke?
I'm just being a tiny bit OCD, I think it would be above the pin (like the other even pin labels) but that interfered with the pads of some resistor so it ended up moved where it was and offset
so yeah it's a non-issue
@onyx hinge @tulip sleet Thanks for your comments. I can see that using Feather nRF52840 Express plus 9-DOF breakout would be much simpler. On the other hand a smaller size/mass of hardware is advantageous to me, and the nano is already smaller than a feather even without adding the 9-DOF. I'll have a think about this.
@shy kiln it's not too hard to make your own build, and you could submit a PR to us for the board (or that class of boards)
@tulip sleet How would I submit a PR?
yw
These arguments are constrained to be compile-time constants, a fact that gcc complains about under "-Og" optimization, but not in normal builds. Declare them as enumerated types
This enables the highest level of debug symbols, and all optimizations except lto that do NOT interfere with debugging, in the view of the gcc maintainers.
I find this mode to be useful when debugging with a J-Link and gdb.
@exotic pumice Thanks. I was thinking PR meant "product request" ๐
lol
This would also make sense in the atmel-samd and stm32f4 builds, I think, though -Og might not fit in a SAMD21 build. But it could at least be put in as a comment.
Yes, const (at least on a variable with function scope) errors. enum{} and #define work.
../../shared-module/audiomixer/Mixer.c: In function 'mult16signed':
../../shared-module/audiomixer/Mixer.c:269:5: error: asm operand 1 probably doesn't match constraints [-Werror]
asm volatile("ssat %0, %1, %2, asr %3" : "=r" (lo) : "I" (bits), "r" (lo), "I" (shift));
^~~
'night all! It was a productive weekend.
@hierophect This is done in TinyUSB. Please pull it in and get it going.
Yes, a way to control of which devices the USB composite device consists of is very important!
Also, a second UART CDC would be extremely helpful. I hate to use the primary CDC for communication and give the customer access to the REPL!
I had used those MAX98357A amplifiers at work and had problems with them at the beginning, by any chance did you captured the I2S traffic with a logic analyzer?
My problem was because I didn't removed the bit clock before removing the LRClock (WSCLK).
@C47D the "scratchy" audio with MAX is while a sample is playing, so I don't think this is the cause. However, I'll attempt to capture a scope trace of the end of playing and look for problems.
@jepler Noted, I did work with an STM32 microcontroller on that project and had to use double buffers to play the audio, didn't took a look at your implementation, maybe it's different for the Nordic device, which I'm not (yet) very familiar with the I2S and DMA peripherals.
@tannewt yep got the notification this morning. I notice it isn't represented in Circuitpython master yet, despite it being on the develop branch and .gitmodules not tying it to a particular commit. Is that just a git thing, that it continues to be locked to a commit until a PR goes through? How does that update process work, exactly?
I would like to use the Metro M4 as a remote controller run by a master microcontroller. I need to read A/D results and send D/A levels as well as set logic pins. I am worried that the I2C and RX/TX lines are not fast enough and perhaps not as free from errors.
Git submodules are always tied to a particular commit. To update them, sync CircuitPython and then change into the submodule directory. Once there, fetch origin and checkout the remote branch (origin/develop). Now move back to a CircuitPython folder to do a test build. git status should show "new commits" for the submodule. You may need to git add it for it to be in the next commit but I'm not positive on that. Then, commit it like any normal commit and push to a branch to PR.
@gingle It's not a high priority for us but we'd love a PR if you implement it yourself. We're also happy answering questions to get you started on it. I'd suggest looking at I2CSlave as a model for it.
This PR adds USB support to the F412 Discovery, reflecting the most recent port in tinyUSB. Includes revisions to the linker for filesystem support. Updates tinyUSB to latest develop release.
Closes #2125.
@hierophect can ya drop me a .hex in a zip here?
@jepler what's it look like with a sine wave playing? you can put an RC filter on the speaker outputs to scope it - also maybe post a pic of your setup?
hmm nope, dont see any USB peripherals come up?
Can you point me to the I2CSlave code?
hiero - those 2 work for you for sure to have a working USB CDC interface?
My tests currently give me a working CDC and MSC interface, yes. Note that the F412ZG has a jumper that needs to be adjusted if you are using only the user USB port - JP3 needs to move from STLK to USB. Could that be it?
You'll get a blinking red LED if something is wrong with the power jumper, and a green LED if things are set up OK.
Alternatively, you can power the board from STLK and plug in the user USB with a different cable. That'll give dual access to both the STLink and the CircuitPy disks.
ok i had 2 USB cables and both jumpers, i can remove the STLK jumper and try again
I'm not sure it'll work backwards like that - if you have the STLK jumper in, the USB will also be powered. I don't know if it works the other way. I'd assume it has some current protection in there but I'd probably stick with either USB or STLK, but not both.
ok for some reason the drag-n-drop hex to mbed disk technique isnt working. with st-link i can erase/program but...its till not enumerating. i gotta go, will investigate more later
@dhalbert @tannewt maybe one of y'all can try it?
@ladyada it actually looks like this is general incompatibility with the .hex format. I just tried both methods with the .hex - the mbed disk doesn't respond to it at all (.bin files you drag in there don't ever appear as a file, they're redirected directly to the MCU), and st-flash does not result in successful enumeration or even set up the status LEDs.
I'm sorry I provided the .hex file, I mistakenly assumed ST would support it. It looks like it's required to use .bin only for both met...
Thank you for your patience with this. I'm excited to see it! I did tweak the default to False but it was fine otherwise.
d87bfaf Add random dithering to ColorConverter - matthewnewberg
3ab6a23 Removed unused return value in displayio_colorc... - matthewnewberg
4604a69 Move dither parameter to ColorConverter constru... - matthewnewberg
b2fb5ac Fix comment on color converter - matthewnewberg
8e55232 Use kwargs for dither in ColorConverter constru... - matthewnewberg
@slender iron , thanks for working with me with getting the PR.
https://github.com/adafruit/circuitpython/tree/master/ports/atmel-samd/common-hal/i2cslave
https://github.com/adafruit/circuitpython/tree/master/shared-bindings/i2cslave
Want me to reopen? It's still ok to leave open for the long term.
@cerulean sparrow happy to! I appreciate you sticking with me on it
@slender iron No problem
@slender iron @idle owl @tulip sleet I'm going to have to miss this evening's meeting (I was hoping I'd be able to make it). My son has just informed me he needs taking to Tae Kwon Do. ๐
My Hug report is for @tulip sleet for his really helpful ideas last week while I was working on circup.
(in addition to a general TellyTubby like group hug)
๐
@plucky flint Thanks for letting us know. We'll add your hugs to the notes!
Thank you! ๐
Hi. Whatโs the algorithm for finding the link to the current dayโs meeting? (Scroll up hasnโt always worked for me.) Iโd settle for a link to todayโs meeting.
-> dad taxi
<@&356864093652516868> Here is the notes doc for today's CircuitPython Weekly. Everyone is welcome! Please add your hug reports and status updates before the meeting, even if you'll be attending - it's super helpful! If you're missing the meeting and you'd like to include your updates, add them to the notes and we'll read them off. https://docs.google.com/document/d/12p4adKbmLf-2QIu2vdvnRw98MfD1jh-mLwq-OXcXxRY/edit?usp=sharing
In the studio today tracking and overdubbing, so I'll be lurking. Group hug!
"(in addition to a general TellyTubby like group hug)" I may or may not return to this image whenever anybody says "group hug" from now on
status: trying to get some sort of lunch together before the meeting starts
Meeting starting soon; we're finishing up another meeting.
just lurking today
[fx: pots and pans tumble uncontrolled from the counter]
lurking
I would leave it open for the long term. I have a lot on my plate so my work on this will be intermittent. Thanks for the links.
hi folks, text only just say'in hi ๐
hi
@pearl notch The link used to be a pinned post but it looks like we've stopped doing it. For now you can search for posts that tag <@&356864093652516868>
wups
๐
lurking
@pearl notch https://docs.google.com/document/d/12p4adKbmLf-2QIu2vdvnRw98MfD1jh-mLwq-OXcXxRY/edit?usp=sharing
Ok, reopened! No worries if it takes time. Please reach out if you have questions! Thanks!
The Top Programming Languages 2019 - Python tops the charts with a CircuitPython nod!
https://spectrum.ieee.org/computing/software/the-top-programming-languages-2019
CircuitPython 5.0.0 Alpha 2 Released!
https://blog.adafruit.com/2019/09/04/circuitpython-5-0-0-alpha-2-released/
Machine Learning with Microcontrollers Hack Chat, lots of Python on Pi! 3pm ET Weds!
https://hackaday.com/2019/09/09/machine-learning-with-microcontrollers-hack-chat/
Speaking of' Hackaday turned 15, tune in to the story and more
https://youtu.be/kMkgwSLj0Uc
Hackaday turns 15 today, we are going to do a fun live video chat today at 8pm ET with some past and present hackaday folks! https://blog.adafruit.com/2019/0...
@ionic elk heya im just...not able to get this workin'
Feather STM32F405 โ How did we do?
https://blog.adafruit.com/2019/09/04/feather-stm32f405-how-did-we-do-st_world-stm32f405-stm32-stm-adafruit/
wiringPi, wiringPi GPIO library โ deprecatedโฆ Lessons for the open-source community
https://blog.adafruit.com/2019/09/02/wiringpi-wiringpi-gpio-library-deprecated-lessons-for-the-open-source-community-drogon/
@ionic elk whats weird is i totally get all the USB appearing when i use thach's tinyusb bin
Hmm maybe it's a submodule update issue?
@ionic elk did you try the binary you posted on your board?
this definitely works:
(the tinyusb test bin)
Yep, it's the same one that's working on my board right now
and you're positive its the '412 discoboard not the '411?
I just downloaded the link I posted off of github and loaded it into the mbed, and I'm getting both the Cpy drive and CDC successfully
:/
Could you send a photo of your board setup?
I mean you're getting it working with tinyusb so that shouldn't be it
Oh, could you try it on the mac? Maybe it's somehow related to case sensitive stuff, somehow
HMMM
I... honestly don't know what's up with that. Why would it affect a binary? @slender iron do you have any ideas?
it enumerates on mac but not win10?
yeah
the tinyusb demo build works fine on win10 - get cdc + msd
i could try rebooting my compy
i dont think that will affect it but ๐คท
@slender iron links plz
i'll try this on my '412 board on Linux and another windows comp a little later
https://github.com/microsoft/pyright @pastel panther
thanks @stuck elbow ๐
@meager fog @ionic elk I'd start by looking at a beagle trace for it
I'll check that out after the meeting. otherwise it'll mess up my headphones -___-
๐ @inland tusk
@ionic elk do you have a windows computer to test against?
I do I'll need to set it up
@pearl notch I can't edit the spreadsheet to add myself
ok thats a good idea - i can give you a trace later if ya need
its got promise! at least it works on mac
you'll figure it out ๐
Sorry, I just expanded the access to the https://docs.google.com/spreadsheets/d/1NWwiUuQnam_abdv02ugLxz9uFrvhtMfy8U306HJ4_qU/edit?usp=sharing
@meager fog can confirm does not work on my win10 machine
I'll run a trace once the meeting is over
Amazing! The directory appears to be filling out itself. ๐
@pearl notch it is impressive to watch
hug reports to the documentation
@pearl notch Looks like that was just an image if it was supposed to be a link to a video
A give a brief demo of a program that can read messages from the light patterns on a Circuit Playground Express. Source code: https://github.com/dcbriccetti/...
I would love to talk FPGAs too
@old smelt have you looked at migen at all? I'm hoping to get those folks building datasheets for shared SoC files that are easy to load
Yes - a little bit.
once we have that, we can port circuitpython to it like any other mcu
Great interview on The Amp Hour podcast with Tim Ansell, Sean Cross and Michael Ossmann.
We've been historically Intel-focused, but I am intrigued by the open source activities
@ionic elk good to hear you had the same non-enum! that means its not just me ๐
...mostly on Lattice.
Canoe: awesome!
@solar whale whitewater? Touring? All of the above?
@meager fog AHA. I was restricting the usb endpoints to only CDC and MSC, since that's required on the F411. When I turned off that setting (enabling HID) I got full enumeration.
It seems like windows has some kind of required relationship between the CDC and HID, which isn't required on mac
This may be obvious to those more experienced with USB?
@solar whale thx for looking into the RFM issue, im curious about your future findings
I will update the PR to represent the change but it does mean that the F411 will continue to not work on windows... I wonder if there's a way around it?
@ionic elk @meager fog there is a bug in the "turning off USB devices" PR, which I found yesterday and will submit a fix for soon.
the interfaces get numbered wrong
it's related to the interface numbers in the descriptors, not the hid report ids
As in, are the excluded endpoints still pushing up the numbering, or something? I think I remember something like that
Windows doesn't like the endpoints being numbered out of order, or something.
yes, that was the mistake. There's a function that renumbers the interfcaes after they are concatenated, but I was renumbering over the whole possible list, not the selected sublist
Welp that's that then.
i'll submit the PR and you can try it on the stm build (or I can)
gotta run
@tulip sleet it's not that big a deal since the F412 should have the full descriptor list anyway, since it can fit it
I've pushed a commit that removes the restriction.
But it will be important for the F411
@meager fog in the short term here's a build that should work on windows.
@ionic elk tryn !
- Endpoint renumbering was done over all the possible USB devices, not the selected ones.
- Handling of no report ID when only one HID devices was incorrect.
- Reordered where to put HID in descriptor (just for consistency).
Have a great week all -- have to go offline for a bit ๐
@ionic elk @tulip sleet odd that import os doesnt work, maybe check you aren't missing something?
can import board ๐
I don't think that's supported yet
because no filesystem support
o ok
@ionic elk @tulip sleet lets get you using adafruit VID/PIDs for these boards - dan, plz assign him some
Thanks all. Have a great week!
Thank you for running the meeting, @idle owl
that way mu will detect it - and also we can have STM drivers on win7
๐
@meager fog probs the best starting point is just the digitalio example
Thanks!
yah i will just like to do os.uname() ๐
we can add it to the list!
yes
this is great so far
excellent work
next up will be the pin restructuring and analogin?
Could use some help ordering that, BTW. I've got QSPI Flash, F405 support, UART, SPI, and OS
Analogin is almost done, that should be in today
@slender iron @tulip sleet wanna chat about whats next?
QSPI flash feels like the next best thing, that way we get consistant storage
But the communication devices will need new pin stuff. Possibly a new object, since they're handled very differently than nrf and SAMD
do you want minimal F405 soon?
F405 stuff is one of those things that could be really easy or really hard depending on whether something is unexpectedly wrong
i will need that...but dont know if it makes more sense to get structure in place
so adding any boards is simpler
like some weird register change, like we had with the f412
I think some level of schenanigans risk is inevitable with STM32. Might just be a good idea if we had a place to document stuff like that
you can do external flash as SPI, not QSPI, first, if that makes it easier in some way, but since there are examples already QSPI is probably fine
well we'd need SPI then ๐
maybe thats a good next one, SPI usually is not a bonkers peripheral
which requires the com peripheral restructuring...
also the 'f405 doesnt have QSPI
Yeah that's why I was kinda pushing for the F412
Or one of the other ones
F413 has 10 UARTS
just sayin
i def have to make a F405 feather
Sounds good. Do we want to chat briefly about the comm peripherals object?
can make a 412 feather after
did you want a unified object? I don't think you really need one. nrf has separate also (unlike samd)
ya, I'm not sure what you mean by comm peripherals object
well, SPI and I2C peripherals overlap, but we're allocating them statically right now
I just wanted an object for storing what pins are associated with the UART, SPI, I2C, etc peripherals that's separate from the pin objects,
since each peripheral has a specific pins for each function, and they're pretty inflexible
Including it with the pin array would mean a ton of extra space for basically no benefit
i'll note that for better/worse the peripheral setup for stm is not as-flexible as sercom, so the table of what you can use is not as bonkers
like there's only 2 or 3 spots for each peripheral
@ionic elk I would just have separate tables for each type
on smaller chips, only 1 or 2
is there any sharing of periphs? If not, then you can just have a table per periph type
@onyx hinge @old smelt https://twitter.com/tannewt/status/1171142678962008064
@fpgahelper Do you have code to load gateware onto a MachXO from @CircuitPython ?
revamp I2C to use periph table
(i gotta go to my 3:30)
ok #1) table per chip, #2) make sure i2c still works #3) add SPI
@tulip sleet yes, periph table, test with i2c, add spi, add spi flash, add qspi flash, add 405
hows that
I'd do 405 before qspi
ok
yah good idea!
you can add all these to-dos in basecampe and we can reorder as necc
you can always use QSPI flash as SPI ๐
How about documenting all this stuff? I've been hoping to do that at some point
Setting up a learn guide for the structure of putting a port together
If I wait too long I won't remember :\
yeah but i dont want ya to have to document things after you do something and then it gets refactored heavily
how about after SPI, then document the peripheral table
because you had gotten i2c/spi to work
This would be more of a guide on how to get the barebones of a port up, then the steps you need to take to flesh it out
But I think after SPI would be a good point to do it
ok
I don't think it's worth doing a guide unless we revamp it first
it's not something we do thaaaaaaat often anyway
taking notes on what was hard or should be revamped is good. You could make a guide outline and just take notes. Don't need to make a draft guide yet
Sure, but it might be nice for explaining how ports are structured
I'm just hoping to save others some confusion - there's lots in the early port process that's pretty easily explained and could save a lot of time. But whatever structure you feel is appropriate for that I'd be happy with.
Could just be on the readthedocs for now, maybe?
i think taking notes about it even in a Google doc is fine, so you don't forget. I wouldn't spend time formatting it all up now
we can share the google doc to other porters for now
"gateware" just means the configuration image for the FPGA, "gate" because FPGAs are made of gates?
(I was not familiar with the term)
While it looks conceptually fine to me I'm not an experienced enough Python coder to notice issues with the implementation. I'd recommend having at least one other person check it out.
@slender iron Ok, circuitpython-build-tools released.
thanks @idle owl !
@ionic elk @tulip sleet @slender iron ok back - i am having photo take pix of the '412 discover
Conceptually fine but I'd double check with a python person.
@meager fog were you still having issues even with the new binary?
@ionic elk no! it works now
huzzah
i was in meetin's
is this dep on danh's PR
or is the PR compelte now
super, I was worried there we had a bug beyond what dan described!
all good - i have lotz o meetings that slice my day up
but i did try it now and it enumerate
i was going to try to blink some LEDs
The PR is done. Having all the USB endpoints sidesteps the bug and should be done anyway
if you have an example py that will save me a few mins
We'll just need dan's fix for the F411, which can't use all the endpoints
ok i have this adorable F411 board we should support after the discovery
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.LED1)
led.direction = digitalio.Direction.OUTPUT
while True:
led.value = True
time.sleep(0.5)
led.value = False
time.sleep(0.5)
Oh great what's it called?
ok please order 2 of these https://www.elecrow.com/micropython-development-board-pyb-nano-compatible-with-python.html
@slender iron lotta flight controllers use the stm32f411
@ionic elk ok get also 2 of https://www.aliexpress.com/item/4000068998794.html be sure to pick the '411 option
Smarter Shopping, Better Living! Aliexpress.com
when you get shipping, use DHL/FEDEX/UPS not postal, cause it will take 3 weeks
k
@ionic elk did dan give you a VID/PID?
@hierophect can you test it on STM32F412 with reduced USB devices to see if the Windows enumeration problem crops up? I can give you a build if you want.
PID 0x8055 # arduino
PID 0x8056 # circuitpython```
here ya go
you can use the circuitpython for this PR
@dhalbert sure can you pass me a binary?
@ionic elk i cant seem to save files to flash
thats normal?
also, cant re-use pins on reset, they aren't deinited?
import digitalio
import time
leds = []
for pin in (board.LED1, board.LED2, board.LED3, board.LED4):
led = digitalio.DigitalInOut(pin)
led.direction = digitalio.Direction.OUTPUT
leds.append(led)
while True:
for led in leds:
led.value = False
time.sleep(0.1)
led.value = True
i was out but just got back
I think there might be an issue where it isn't triggering self reset properly
can you try hitting the reset button and see if it starts working again?
yeah
i am doing that
ok just verifying
thats a different PR
wanted to verify it wasnt me
that example blinks 3 of the LEDs, LED1 seems to not blink but who knows why
oh wait i forgot LED1
duh one moment
FYI -- at the REPL the NeoPixel is white
import neopixel
pixels = neopixel.NeoPixel(board.NEOPIXEL, 1)
pixels[0] = (255, 0, 0)
turns it RED, but then it goes back to white within a second.
@ionic elk do you want an F412 .bin with restricted USB or an F411 binary as is, for testing?
restricted F12 bin
@ionic elk ok once you update the VID/PID im happy to call the USB for f412 working well enough!
pretty lights ๐
I'll hang on to it, thanks!
I do need to put in a little bitty PR where I standardize LED names
i think its ok as is, ez to blink ๐
good test of time/digitalio
good work! we're getting there
@ionic elk ok, I think this is right. It has my interface numbering fix, and it's your branch rolled back to before the last commit, which removes the F412 USB device list narrowing
I confirmed the NeoPixel is basically unusable because the semaphore system is competing with the code for control of the NeoPixel.
@ionic elk hierophect I took my '412 out of the packaging. Can I save the factory firmware load easily before overwriting it, or is it readily available elsewhere?
you mean the factory example? I think it's pretty readily available on the board page but I'm honestly not sure. I've never used it
That's the one with the display, right? Let me take a look
Yep, compiled demo binary: https://www.st.com/en/evaluation-tools/32f412gdiscovery.html#resource
@ionic elk Yes, well, I went ahead and overwrote it. ๐ I am powering the board with both USB cables, and it enumerats fine on Windows 10 and Linux with USB_DEVICES = "CDC,MSC". I can see the insides of CIRCUITPY and connect via REPL. Yay!
I'll merge my PR after this finishes building so we don't get GitHub actions skew conflicts
Great. Could you take a look at my old pin remap one too?
I tested this on a '412 board, using the commit from #2132 just before this commit https://github.com/adafruit/circuitpython/pull/2132/commits/d8251ae4ab8b9634754ddc1fe545179a609417d8. Works fine on Linux and Windows.
@ionic elk I think @meager fog meant that pins couldn't be used after a CircuitPython reload. It's super common bug to have early in development. basically all peripherals should be reset after python code is done
@slender iron @ionic elk indeed, i can open an issue
save this as code.py
import digitalio
import time
leds = []
for pin in (board.LED1, board.LED2, board.LED3, board.LED4):
led = digitalio.DigitalInOut(pin)
led.direction = digitalio.Direction.OUTPUT
leds.append(led)
while True:
for led in leds:
led.value = False
time.sleep(0.1)
led.value = True
on reset it runs, if you go into the repl and hit control-D to restart we get...

I did the same test to compare with the Feather M4 and it did way worse. I could hear the tone but it wasn't as loud or as clear as the nRF. So hopefully you don'...
Please don't use gotos. Instead, set stopping, break out of the loop and then do the cleanup if stopping is set.
What does this multiply do?
In general it looks good! I'd like to see you use the compiler's bitpacking rather than doing it yourself though.
I'd leave these separate and just mark the number of bits for each. It'll be clearer and will remove the need for pin_port and pin_mask everywhere. Instead, you'll be able to read the struct field directly.
Please return GPIO_TypeDef * which is what the API takes in.
Instead of doing the bitpacking yourself please use the : <no bits>; form when defining the struct like we use here: https://github.com/adafruit/samd-peripherals/blob/83a4759d186574d8034435cd2303def85e4ed793/samd/pins.h#L46 That way the compiler will handle all of the packing and unpacking for you and the source will be more readable.
For the ADC1, ADC2, ADC3 I'd define a macro for each and then | them together for the combinations 12 and 23.
@slender iron I'm surprised at volume/clarity differences, i2s being a digital protocol
@onyx hinge yup, seems like a bug to me on samd51 side
have you checked samd51 errata?
I'm having rather rotten luck today with using "load" in gdb
are you using openocd?
it keeps putting my device (particle xenon) in a state where I have to "make sd; make flash" otherwise it just reboots over and over again
no, all segger j-link tooling
ok good
try like monitor halt, then load, then reset or something
it might be trying to load while it's running
yeah try a halt first
I don't have a theory why it could end up so confused. I swear this same workflow worked most of the day saturday.
particularly how I could have to "make sd"
@onyx hinge it would be worth getting a real j-link, I think
@tulip sleet I do have the "j-link base" now, not the cheapest one
non-edu and everything
np
I do what you are doing all the time. I have a set of aliases
but I usually use a feather 52840
the board or the computer?
The whole computer. Recently installed Linux box, but the HW is all 10 years old
is this your startup for gdb server? JLinkGDBServer -device nRF52840_xxAA -if SWD
and you're up-to-date on the segger software?
I am using a 7010 Dell Optiplex. Both USB2 and USB3 ports work fine with this setup
drwxr-xr-x 8 root root 4096 Aug 31 08:21 JLink_V650a
-if swd -speed 4000 -device nrf52832_XXAA -port 2331
``` well this is wrong
it will be interesting to see if the device change does anything. Are you using an offboard USB hub?
Yes, a powered hub
you might try a direct connection, just to make sure
but it is not generally a problem, it's usually a particular hub that's flaky
This improves the situation where background tasks are starved by
- bulk I/O (.read())
- listdir
- printing
Testing performed: Using nRF I2S audio (not yet in master) I started a 22050Hz, mono, 16-bit sample running in a loop and then ran the reproducers at the REPL:
while True: os.listdir('.')
while True: len(open('somefile.wav').read())
This reduced the amount of buffering in I2S audio required to not hear stuttering from ~200ms to 16m, as reflected in the current state of #...
@tannewt I have attempted to address your review comments. Thank you!
regardless, it's a good evening of progress!
I am sure that I will find a routine that works for me with the j-link and/or maybe it's my PC which I plan to replace in October/November anyway
and it may be the board too, so order one or more Feather 52840's when they're available
doesn't seem likely, but not impossible either I guess
do you have a UF2 bootloader on the board for convenience?
Yeah
though j-link "load" in gdb would be even more convenient if it worked ๐
consistently
did it lock up again after changing the device?
I'm not sure the code is any different in the jlink programs
My whole PC hasn't locked up again yet, no.
haven't done "load" enough times to know if the problem is there or not, sometimes it works 2-3 times and then stops
I've had a whole raft of slightly different problems and I am not sure I've even got a handle on what the pattern is, just that it doesn't work 100% and I'd like it to ๐
yah, I really don't see that I do use my aliases for loading, so I always do a mon reset before and after
having the aliases would help me be more consistent that's for sure
but still, what can "load" possibly be doing that erases the sd?
(softdevice, right?)
right.
well, maybe there are some subtle differences between the '832 and '840 about writing flash
Hmm, since these point to the same pin, it seems like supervisor โshouldโ be well behaved..
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/feather_nrf52840_express/mpconfigboard.h#L37
https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/feather_nrf52840_express/pins.c#L30
clear_temp_status() in supervisor/shared/rgb_led_status.cdoes not check forneopixel_in_use`, unlike the other status neopixel writing routines in that file. I think maybe it should. I guess the question is whether the atmel-samd boards have the same behavior here. I looked at the uses of these routines and I don't see that the nrf port does something very different.
I just hit this problem, so I need it :)