#circuitpython-dev
1 messages ยท Page 280 of 1
Sorry for the delay, slipped my todo list today. Just needed to swap over to a CFLAG and add the redefine logic to the .h file. Works for me now (raw test with string dir, I don't have MiniMQTT set up). This whole section still needs a conceptual revamp, but we'll follow up on that in #2458.
Give this a spin and hopefully we can get it in stat.
is there a place where all the CircuitPython 2020 posts so far are compiled?
at the bottom of every post has links
and the bottom link is to last year's which has all of the 2019 ones
Hi, Thanks for adding the i.MX Feathers, I was planning on adding them soon, just took some nice photos today :D
You work too fast, I was planning to do it :sweat_smile:
@arturo182 please PR the new images when you have a chance!
@arturo182, you can update them with additional info.
I like that the bot keeps track of boards ๐
Hi, since a bit of time I had two mysterious issues (1) Mu would refuse to start (2) I discover music/images/fonts/... folder on my CIRCUITPY drive. It seems that at startup, Mu (the recommended editor) is putting file on my CIRCUITPY drive. Issue (2) is a bit annoying, but is not a problem and it took me time to understand it was Mu doing it... for a long time I believed that was the new normal when upgrading to 5.0.x. But that behaviour of Mu is a pain with a non "Express" board such as a Trinket M0. In that case it start filling the file system, then Mu get stuck with issue (1). So Mu is self blocking itself, and making filling my board.
Is this a know Mu issue? (I might have upgraded to a alpha/beta release of Mu, because I wanted to solve (1)... I don't know when this "feature" was added or if I clicked somewhere to enable that.
I have seen this mentioned in Mu issues, and am looking now.
Great, Mu is the recommended editor, so this could be hurting beginner.
Just need a documentation story: make a compatibility matrix page.
@tulip sleet Exactly my problem. Great... I can confirm that this is a mess (and it took me a lot of time to figure out. Mostly I was upgrading my board, then starting Mu. So at one point in time I started to believe that this was a 5.0 feature !!!
I don't know exactly why this is happening, as I don't think it happens to everyone in your situation.
it should only copy that stuff in PyGameZero mode - I think
No problem @arturo182. I needed to get something in place, otherwise they appear as Unknown Board.
@tulip sleet Maybe it started because I acquired and started using a PyGamer!? I had been happily using Mu before, it worked ok with my PyGamer... and maybe I started to have problem when returning to older/smaller box. As if PyGamer had been detected once, the mode enabled, and then, as a virus, contaminating non PyGaming board. I cannot guarantee this is the right sequence of event, but it is a very possible sequence of event.
At least, I am in Circuit Python Mode for the moment...
i don't think so, because the PyGamer doesn't use PyGameZero, that's for regular python. But if you upgrade to the latest alpha and remove the offending files and directories, do they reappear? If so, then maybe another comment on that GitHub issue is in order.
Doesn't look like i can request a review @slender iron
kk, will look now
btw the stm feather description says it's "upcoming" ๐
yup! ๐
right now it's super pre-alpha with the bootloader situation ๐
@tulip sleet I just made a full re-installation of the Alpha version of Mu for OSX: https://github.com/mu-editor/mu/releases/download/1.1.0-alpha.2/mu-editor_1.1.0-alpha.2_osx.dmg as long as Mu is running I can unplug and unplug PyRuler and PyGamer without side effect. But if PyRuler is plugged when I start Mu, it fill the flash... I might need to check the shortest sequence to reproduce this, not involving PyGamer and only using PyRuler.
on the peripheral side i guess it's fairly ok, spi uart and i2c are at least half-implemented
@half sedge Thanks for the testing. Please do reply to that issue, I'm sure @plucky flint will be interested. (@plucky flint scroll back to hh:06 for the start of this thread)
having this first commit in is most important. now folks can expand functionality and board support
Should've done it in one PR, sorry for extra work.
@tulip sleet @plucky flint I updated https://github.com/mu-editor/mu/issues/872 and it seems easy to reproduce (at least on my MAC mini). In practice, the only reason I use Mu is to be able to recommend (and demonstrate) it to other... for personal use, I take vi whenever I can... but I cannot recommend that. ๐
tested on feather_stm32f405_express with minimart_adafruit_io_wifi demo -- works normally !!
also verified that .encode is available for strings....
Looks good
@slender iron I did a build of Beta3 and the mimxrt builds all succeeeded but threw some warnings - is this expected ```Build feather_mimxrt1062 for en_US took 68.30s and succeeded
make: Entering directory '/home/jerryneedell/circuitpython_master/ports/mimxrt10xx'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
sdk/devices/MIMXRT1062/drivers/fsl_clock.c:24:6: warning: "ARMVFP" is not defined, evaluates to 0 [-Wundef]
24 | #if (ARMVFP >= ARMFPV5) &&
| ^~~~~~~~~~
sdk/devices/MIMXRT1062/drivers/fsl_clock.c:24:20: warning: "ARMFPV5" is not defined, evaluates to 0 [-Wundef]
24 | #if (ARMVFP >= ARMFPV5) &&
| ^~~~~~~~~~~
sdk/devices/MIMXRT1062/drivers/fsl_lpi2c.c: In function 'LPI2C_RunTransferStateMachine':
sdk/devices/MIMXRT1062/drivers/fsl_lpi2c.c:1037:31: warning: cast increases required alignment of target type [-Wcast-align]
1037 | base->MTDR = *(uint16_t )handle->buf;
| ^
common-hal/microcontroller/Processor.c: In function 'common_hal_mcu_processor_get_uid':
common-hal/microcontroller/Processor.c:62:10: warning: cast increases required alignment of target type [-Wcast-align]
62 | ((uint32_t) raw_id)[i] = OCOTP_ReadFuseShadowRegister(OCOTP, i + 1);
| ^
Converting to uf2, output size: 492544, start address: 0x6000c000
Wrote 492544 bytes to build-feather_mimxrt1062/firmware.uf2.
make: Leaving directory '/home/jerryneedell/circuitpython_master/ports/mimxrt10xx'
@solar whale I'm not surprised about the warnings; it's really early code now. Each port enables or disables warnings as errors. Those seem pretty simple, and we can ping @indigo wedge about those here.
ok -- not a problem -- just wanted to make sure I had not missed something.
yeah those are ok for now ๐
@solar whale when you have a sec can you try the new v02 apk build in the root of the repo (https://github.com/FoamyGuy/Android_Bluefruit_Playground) and send me a photo of it on your device. The selector squares and pixels dots won't match up yet, but this build contains a new asset for the density I think your device will fall under. I've tweaked the color of the board to red for now so it will be easy to tell if it is showing the new asset.
as long as it does show the new asset, and it fits the screen better I should be able to re-align the selectors and pixels dots to match it.
I have a nice neopixel demo but it is way too slow without FP. I guess I can stick an itsybitsy m4 on it instead.
@lone axle what screen do you want to see? I am not seeing a red board?
Yep, got that and few other things on the list knocked off.
I'm going to try changing out a different asset if you have another minute to check again
sure
Ok, there is a v03 apk in the repo now
hooray
nice, okay comparing back to the photo from the other day with the blue one it looks like the red one is not getting shrunken like the blue one was.
So now I can re-align them to fit the new asset and they should line up properly on all devices with the same density as that one
Yep, thanks again for the test. I'll let you know when there is a new one with them aligned.
@tannewt
@pbricmont Thanks for the link! Are the displays all on the same bus or are they different?
In the Arduino version, all six displays are on the same SPI bus. The CP SPI buses seem much faster (24mHz?) but multiple buses are required due to the 2 per bus limit. Also, I had to make all the wiring as short as possible to get it to work at all.
Would you be interested in debugging if we got you a JLinkEDU?
Yes, I would be happy to investigate further. I have reviewed the CP deb...
fyi I'm working on teensy 4 support: https://github.com/tannewt/circuitpython/tree/teensy4
Thanks Dan! I'll give it a go with Windows 10!
Windows 10 does see the device (even though not always - I had to remove the scan_response part from the advertising so that it show it on the list of pairable devices), but disconnects about one second after pairing with a "Driver error" message:

Android works well
@lone axle the picture above was from an old Moto-x Android 5.1 pretty good alignment
i have a v40 thinq i can test on
and acsess to some other phones(ie I will make my friends let me use their phones)
@cobalt dawn I think feedback to @lone axle on any phones would be appreciated.
cool pester me, after today i will be living at work till monday.. sorta
good luck with that ๐
I really like the CPB -- so many great ways to use it.
it also works well with the Bluefruit Connect App -- the one you have been using. If you have something running that it can talk to.
I hope it heals quickly !
bones do what the do....
I could not find a compatable sketch for the special neopixel sketch
hmm -- the demos I have seen have been for CircuitPython
well the one for the current bluefruit app are arduino only i think
I use it with CircuitPython all the time.
yoau are talking tho origblefruit app right?
oh im talking the other part of the app
the more refined one that needs the sketch
to set each pixel to a color
oddly mine is not showing in the list
oh -- forgot about that -- been a long time.
i have to work out why the app cant see it atm
although -- I would expect that the old neopixel sketch should work with the CPB - if you recompile it for the CPB
above my current skill
just tried and it will need some work ...
im willing to learn
tho i may need someone to type
heem, aparently my cpb has no uart atm
ah -- that sketch may not work -- it is for the older BLE chipset -- may need a lot of work....
what are you trying to do with the UART?
just connect in general
i did before
i think i have to load difrent code onto it
no biggie
i can do it latter
@cobalt dawn That would be great! I'm happy to get it tested on as many different devices as possible at this point.
@solar whale ty for the Moto X pic. Looks like that one did get scrunched a tiny bit but not nearly as much as the ZTE device. I may end up tweaking that asset just a hair as well so it won't have to shink and then it should align perfect.
good morning! I think I'm looking at simplex spi on stm32 first, then getting back to apparently more DMA hangs on samd, this time when audiomixer enters the picture. may end up pulling my hair out over that one
I used to have hair .... but a career as a programmer and raising 2 children took care of that
I don't know if this is important, or if it's different than other boards, but when constructing (or maybe try_lock()ing) an SPI object on stm32, its MOSI pin gets pulsed high for about half a microsecond
Testing performed: On a feather stm32, I used a test program to exercise duplex, in-only, and out-only SPI. write, readinto, and write_readinto worked properly in each case where they should be applicable. I scoped clock and MOSI, and hooked MISO to GND and 3.3v to observe that correct values were input.
I did notice that a short (.5us) pulse would occur on MOSI during SPI construction (or maybe activation via do_lock()) but this is almost certainly preexisting and seems like it would ...
@ionic elk just curious, and don't want to complicate things by raising it on the PR itself, is "GPIO_MODE_AF_PP" actually an input when the AF is an input?
I was surprised that MISO is set to a _PP pin mode
Yeah there's no input state for AltFunction
Thanks for addressing the requested changes, especially the coding style items!
only options are
#define GPIO_MODE_AF_PP 0x00000002U
#define GPIO_MODE_AF_OD 0x00000012U
I would say "makes sense" but that would be a lie, more like "filed away for future reference"
@dhalbert just wanted to quickly check with you whether this mpconfig.h change is ok
@onyx hinge there is no sense with STM32, only madness on this path
@ruby atlas can you take a look at https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel/pull/59 ?
I've requested a change, after which I think I can merge it
@lone axle just dm me deets
@cobalt dawn The Repo is here: https://github.com/FoamyGuy/Android_Bluefruit_Playground In the root directory there is the v03 debug APK file that you can install on your device. The APK link at the top of the readme is broken currently so you'll need to either click the file up above, or else download the whole repo. There are good links in the readme for both the UF2 firmware you need on the CPB as well as the PDF version of the learn guide for the iOS version of the Bluefruit Playground app, goal is for the Android one to behave the same so the PDF should be applicable to both.
On an unrelated note, I (@android_ninja) have finally figured out how to change my username. I go by @lone axle pretty much every where else online, so I am changing to that here. Android_ninja was leftover from the project I first joined discord for. Didn't know if it would let me change it.
Re this thread:
https://forums.adafruit.com/viewtopic.php?f=58&t=160746
Recreated underlying issue with a simple REPL test:
5.0.0 beta 2
Adafruit CircuitPython 5.0.0-beta.2 on 2019-12-20; Adafruit Circuit Playground Bluefruit with nRF52840
>>> class Foo(tuple):
... pass
...
>>> foo = Foo((1,2))
>>> foo
(1, 2)
>>> foo[0]
1
>>>
5.0.0 beta 3
Adafruit CircuitPython 5.0.0-beta.3 on 2020-01-08; Adafruit Circuit Playground Bluefruit with ...
@lone axle is there a known good sketch to throw on my cpb?
or code for mu
sorry im on pred, my brain is broken
@cobalt dawn No worries, there is a UF2 file, it's linked near the top of the readme. You can get it from here: https://adafru.it/HCh
since it's a UF2 you'll have to put the CPB in bootloader mode
(also be sure to backup anything important, I'm not sure if it overwrites your files or not)
@makermelissa I'm making this PR in order to have the Pine64 as a supported board on blinka.
Hope it's ok.
Regards.
all green is bootloader mode right?
Yes
hmm, can you grab a screenshot? I don't recall having any issues but maybe seeing it could jog my memory if it's something I've seen in the past
This may be related to changes made to support _pixelbuf. Pinging @rhooper.
weird, don't think I've ever seen that one
i think it switced to an io error when i hit try again
the board might have started switching back to non-bootloader mode depending how far it got into the process possibly?
A few minor change requests.
I see a small typo as noted separately.
Images should be a 13:10 ratio to look the best. Maybe add some white space.
We should have 3 images.
Large image should be 780x600, small should be 293x225. You can copy the large one to original.
Also before adding, let's get it working in Blinka. Right now it's just detecting.
That is weird, you might try loading the one of the official CP uf2 files to see if it's doing that for every firmware file or just the one used with the app.
ill bring it to the lab with me to try, i think the got mu on the laptops, im running a bit late to get there
Sounds good, if you want me to do something else, just let me know.
I'll do the changes now.
The BOARDNAMEBOOT drives show up after installing Arduino, right? Which is to say, the bootloader is the bootloader regardless of what software it's running? Or am I missing something obvious and it doesn't work the same once Arduino is introduced.
should be the same -- bootloader does not know what was running.
And it's still a double-tap to the reset button to get it going, right?
Someone in the forums isn't getting a PORTALBOOT drive on their Titano, and short of linking them to the CircuitPython install page, I'm not sure what else to suggest.
Which I already did, and they said they tried.
Are there issues with Catalina?
I
Thing is, it worked initially with CircuitPython and Mu.
ll try mine
They tried Arduino, and can't get back to PORTALBOOT now.
And therefore can't get CircuitPython back.
@solar whale Thanks.
are they double tapping fast enough?
The guide says something about that, but it's worth asking. I have no idea.
the LEDs they're reporting sound like the bootloader though.
got PORTALBOOT whit CP installed -- Ill try an arduino sketch -- will take a few minutes
Ok
@slender iron Someone else commented on someone else's CircuitPython 2020 post in the forums: https://forums.adafruit.com/viewtopic.php?f=60&t=160679 FYI. It's more of a hardware request than a CP request though.
@idle owl I put the blink sketch on my titano -- then doubletapped and bot PORTALBOOT
@solar whale Alright, thank you for checking.
What do the LEDs do when you go from Arduino to the bootloader
so I know
brief RED on the NEOPIXEL then solid Green -- red LED is "breathing"
Ok that's what I expected, and is what they're seeing, if I understand them correctly, though I asked for them to describe it again. Just no PORTALBOOT drive for them.
Cable worked previously so I doubt it's that.
I'll suggest a reboot as well.
reaching a point of frustration with my NEW samd dma hang. contents of DMA registers: https://gist.github.com/3bf81ce513cca1d0074bbf61d2457e42 contents of call stack: https://gist.github.com/d5ed30ac26cbcff2ca8a648bdcbb66ac
Wish I had better suggestions
@solar whale Thanks for checking, I appreciate it
YW
this one happens VERY READILY when introducing AudioMixer, which doesn't even touch DMA directly, and I've never see it otherwise.
and the trick of "disable then reenable DMA channels" does not knock it loose
I am currently trying my hands on the PyPortal, going through a couple of examples, and when I run the code from "Internet Connect!" I get "Attribute error: 'Socket' object has no attribute 'send'. What does this mean?
$88 = {CTRLA = {bit = {SWRST = 0, ENABLE = 1, MODE = 3, RUNSTDBY = 0, IBON = 0, DOPO = 2, DIPO = 2, FORM = 0, CPHA = 0, CPOL = 0,
DORD = 0}, reg = 2228238}, CTRLB = {bit = {CHSIZE = 0, PLOADEN = 0, SSDE = 0, MSSEN = 0, AMODE = 0, RXEN = 1},
reg = 131072}, CTRLC = {bit = {ICSPACE = 0, DATA32B = 0}, reg = 0}, BAUD = {bit = {BAUD = 17 '\021'}, reg = 17 '\021'},
Reserved1 = "\000\000\000\000\000\000", INTENCLR = {bit = {DRE = 0 '\000', TXC = 0 '\000', RXC = 0 '\000', SSL = 0 '\000',
ERROR = 0 '\000'}, reg = 0 '\000'}, Reserved2 = "", INTENSET = {bit = {DRE = 0 '\000', TXC = 0 '\000', RXC = 0 '\000',
SSL = 0 '\000', ERROR = 0 '\000'}, reg = 0 '\000'}, Reserved3 = "", INTFLAG = {bit = {DRE = 1 '\001', TXC = 1 '\001',
RXC = 0 '\000', SSL = 0 '\000', ERROR = 0 '\000'}, reg = 3 '\003'}, Reserved4 = "", STATUS = {bit = {BUFOVF = 0,
LENERR = 0}, reg = 0}, SYNCBUSY = {bit = {SWRST = 0, ENABLE = 0, CTRLB = 0, LENGTH = 0}, reg = 0}, Reserved5 = "\000",
LENGTH = {bit = {LEN = 0, LENEN = 0}, reg = 0}, ADDR = {bit = {ADDR = 0, ADDRMASK = 0}, reg = 0}, DATA = {bit = {DATA = 90},
reg = 90}, Reserved6 = "\000\000\000", DBGCTRL = {bit = {DBGSTOP = 0 '\000'}, reg = 0 '\000'}}
``` INTFLAG.bit.DRE is set, which should trigger the DMA
er, no, this is a receive. RXC is clear so there's nothing for DMA to do?
MODE=3 is weird, datasheet defines MODE=0x0 and 0x1 only
whaaat, setting MODE=1 busted it loose ?
Ok so there are a couple of features of the Circuit Playground library not present in the Express module. I want to raise a friendly error if someone tries to use them on Express. Is this the best way to do this? ```python
def sound_level(self):
"""This feature is not supported on Circuit Playground Express."""
raise NotImplementedError("This feature is not supported on Circuit Playground Express.")
def loud_sound(self):
"""This feature is not supported on Circuit Playground Express."""
raise NotImplementedError("This feature is not supported on Circuit Playground Express.")``` Or is there some better way to do it.
That's included in the Express module. The features are present in the Bluefruit module.
There will be more Bluefruit features added eventually as well.
So if there's a better way to do this, I'd like to start it now since we will need to do this more.
no, the magic did not repeat itself
@idle owl I think this is probably more clever than useful, but just in case: ```class K:
@property
def _unsupported(self):
"""This feature is not supported on Circuit Playground Express."""
raise NotImplementedError("This feature is not supported on Circuit Playground Express.")
sound_level = _unsupported
loud_sound = _unsupported
it is shorter and might make the frozen file smaller (or it might not, or not by enough to matter)
I'm not sure you're right about it being more clever than useful. That's really good.
I used @property so that it doesn't have to worry about the argument signature of each function.
@idle owl I'm on my way out for a bit, but the person with no PORTALBOOT drive, when they double-click, does the red LED (not Neopixel) pulse slow or fast (or not at all)? Slow means bootloader is working, fast means it doesn't see a USB connection, not at all means the bootloader might be smashed for some reason. Should try double-clicking on another computer. If Arduino program is crashing, then they won't be able to upload without double-clicking first
@tulip sleet I just built with that added to express, and on import I get this: RuntimeError: maximum recursion depth exceeded what does that mean is happening again? I can't remember and you knew I thought.
@tulip sleet I asked them to describe the LEDs again, so we'll see what they say.
oh it was the stack size failing.
apparently adding literally anything else to express.py hits it again. This is on master.
I'll move on to something else for now.
it means some issue with the stack depth. OK, sounds like we need to bump it up again. just trying to see how to increase it - i forget
Likely we'll have to do it again to 4.1.x if we end up releasing a 4.1.3 for some reason and updating the frozen lib. I didn't expect that we would, I assumed this would only be in 5.x, but it's worth keeping in mind in the event we have some other reason to do another 4.x release.
https://github.com/adafruit/circuitpython/pull/2393/files change CIRCUITPY_DEFAULT_STACK_SIZE by a multiple of 8, add 256 or 512
yes, I think we'll need a 4.1.3
at some point
Ok I can try changing it and see what happens.
ok, afk for 1.5 hours or so
Yeah, it would be.
I'll have a look to see if this can be fixed in tuple_subscr, or if we need to revert.
@tannewt I think we should consider switching back to the _subscr signature change approach. I believe I can get that done quickly, and it should restore the expected behaviour, but allow classes like Pixelbuf to interact with the native base during subscr calls.
We'll certainly want to add this as a test case.
@tulip sleet Thanks, Dan
@onyx hinge It works ๐
@tulip sleet Bumping it by 256 was enough.
I'd rather work forwards and fix this issue. I think it'll be better in the long run if native code has access to the subclass objects.
@onyx hinge @idle owl In terms of saving space I did a similar thing in midi module using a class variable: $ fgrep EX_VALUE *py channel_pressure.py: raise self._EX_VALUEERROR_OOR control_change.py: raise self._EX_VALUEERROR_OOR midi_message.py: _EX_VALUEERROR_OOR = ValueError("Out of range") note_off.py: raise self._EX_VALUEERROR_OOR note_on.py: raise self._EX_VALUEERROR_OOR pitch_bend.py: raise self._EX_VALUEERROR_OOR polyphonic_key_pressure.py: raise self._EX_VALUEERROR_OOR program_change.py: raise self._EX_VALUEERROR_OOR
@slender iron shall I just create a 100 issues for all mimx stuff that comes to mind?
sure ๐ tagged with the correct label and 6.0 or long term milestone
correct label being "nrf" ๐
is there something special I need to do to use jlink to load into flash?
Right now it doesn't compile because ParallelBus is not implemented, might need additional work after that part is done.
Right now if I try to enable USB MIDI, the whole USB stops working. I suspect we might be out of endpoints, but needs to be verified and fixed if possible.
The i.MX RT10xx family has this really cool peripheral called FlexIO:
The FlexIO is capable of supporting a wide range of protocols including, but not limited to: UART, I2C, SPI, I2S, camera interface, display interface, PWM waveform generation, etc.
We should investigate if we can use it as a way to provide busio classes on pins that normally wouldn't allow it.
Right now only 2 out of 3 RAM banks for on both RT1011 and RT1062, meaning we are missing 32KB of RAM on the RT1011 and 128KB on RT1062.
I think it has something to do with how FlexRAM is configured but I couldn't quite get it to work.
Copied from stm32, seems a bit buggy, only works sometimes (sets the wrong color when not working).
Need to add the SDKs, linker files and board definitions for those.
Boards:
- mimxrt1015_evk
- mimxrt1020_evk
- mimxrt1050_evk
- mimxrt1060_evk
- mimxrt1064_evk
It is implemented and I did some quick tests but I think we need more testing before we say it's done.
There is commented-out code copied from samd sprinkled around, needs to be fixed up to support the way mimxrt10xx GPIOs work and uncommented.
It's a nice feature for sanity checking designs, think we should have it in mimxrt10xx too.
Used for stuff like i2c displays, spi flash, and spi leds.
Right now both MOSI and MISO are expected, need to fix that.
Just run sanity tests on SPI, I2C and UART, I probably missed something or there's some corner case.
Right now UART expects TX and RX, need to fix that.
I implemented and tested the class, but maybe there's something hiding in the open drain or pull stuff.
Code is there, commented-out, copied from samd.
@trim elm here's what to do with the remaining repos:
Adafruit_CircuitPython_SK9822 - Empty
Adafruit_CircuitPython_MFRC630 - Empty
Adafruit_CircuitPython_BitbangIO - Empty
Adafruit_CircuitPython_Debug_Bus_Device - Empty
Adafruit_CircuitPython_Debug_SPI - Empty
Adafruit_CircuitPython_EthernetManager - Empty
Adafruit_CircuitPython_WSGI - Empty
- If these are all truly empty except for a
READMEor something non-functional, go ahead and push the โoldโ version of the workflow files so adabot can patch them without issue. You can push directly to master because there is nothing to break and no setup.py to trigger a release
Adafruit_CircuitPython_CPython - Has files but is empty
Adafruit_CircuitPython_Debug_I2C - I don't think this repo was ever discussed
Adafruit_CircuitPython_GFX - Will be deprecated soon
- Put in a PR to add the old files and add me as a reviewer
Adafruit_CircuitPython_LSM303 - Has been archived
Adabot should be ignoring this repo. Iโll work with @raven canopy to resolve this
Adafruit_CircuitPython_Display_BLE_Status - This also wasn't discussed
- Rename
setup.pytosetup.py.disabled, add the Actions workflows and push a PR, tagging me and @slender iron for review
Adafruit_CircuitPython_AdafruitIO - PR hasn't been merged yet
Adafruit_CircuitPython_BLE - PR has been made but not merged, there are currently some issues with pylint on that repo
- These will get merged
Adafruit_CircuitPython_Bundle - I wasn't sure what to do with this one, so I planned on bringing it up but forgot to
- I suspect this one is different enough from the actual library repos to not be included here; Iโll consult with sommersoft
Adafruit_CircuitPython_Motor - Has already been moved to Actions
Adafruit_CircuitPython_ProgressBar - Has already been moved to Actions
- Nothing to do here
Some of them are from the SDK and I don't know how close to original we want to keep it.
c-c-c-combo breaker
+10 points to Gryffindor for a sweet reference
Though with serpente, perhaps you'd be Slytherin
don't you hate it when people use CI as their dev env? :P
It depends; I imagine it's usually because they don't know better or know alternatives
sometimes there are no alternatives, when you are debugging a problem with the CI itself
@pastel panther What do you mean by "old files"?
@trim elm I mean the version that is currently being used in just about every other repo that adabot is going to update with the cookiecutter changes
@pastel panther Ok. Will do
you could also push the current version. the patch will just skip it. ๐
It's all commented out, I just added it because I needed it for PWMOut to build :D
lab was busy, so i did not end up working on the cpb, so before i start again, was i suposed to rename that file?
Right now it's more of a proof-of-concept.
I've seen an issue on samd where the external flash can get corrupted and either go into read-only mode or totally crap out.
We should check if this can happen in the mimxrt10xx port too because since the FW and fatfs are on the same external flash, the risk is higher.
The mimxrt10xx family has a USB High-Speed peripheral, it would be nice to see if we are actually taking advantage of that.
In mass-storage the bottleneck is probably the external flash speed, so that's probably not the best idea to test speeds.
Ideas welcome.
We have 1MB of RAM and almost unlimited (well, 8/16/32 MB) code flash, let's do crazy things!
Ideas welcome
From the datasheet:
Parallel RGB LCD interface
โ Support 8/16/24 bit interface
โ Support up to WXGA resolution
โ Support Index color with 256 entry x 24 bit color LUT
โ Smart LCD display with 8/16-bit MPU/8080 interface
It supports up to 1366x768!
From the datasheet:
Generic 2D graphics engine:
โ BitBlit
โ Flexible image composition optionsโalpha, chroma key
โ Porter-duff blending
โ Image rotation (90, 180, 270)
โ Image size
โ Color space conversion
โ Multiple pixel format support (RGB, YUV444, YUV422, YUV420, YUV400)
โ Standard 2D-DMA operation
Just imagine!
From the datasheet:
The CSI IP provides parallel CSI standard camera interface port. The CSI parallel data ports are up to 24 bits. It is designed to support 24-bit RGB888/YUV444, CCIR656 video interface, 8-bit YCbCr, YUV or RGB, and 8-bit/10-bit/16-bit Bayer data input.
umm so new error thu cp/ay_ble file is to large for the CPB
This would be awesome for really fast sd-cards or BLE/WiFi modules that speak SDIO.
From the datasheet:
โ SD/SDIO 3.0 compliance with 200 MHz SDR signaling to support up to 100 MB/sec
โ Support for SDXC (extended capacity)
Fixes #2454. @bmeisels, working on the AramCon Badge, would like to turn off testing for powered I2C pullups, due to their particular situation with a board and its matching peripherals.
This adds CIRCUITPY_REQUIRE_I2C_PULLUPS, which can be specified in mpconfigboard.mk. If 1 (the default), pullups are required. If 0, the checking is not done. Only nrf and atmel-samd current check for pullups. Tested on an nrf board.
@bmeisels please review and try.
I no longer can do this after upgrading to CircuitPython 5.0.0 beta 3: audiomp3.MP3File(f)
Rust... rusts its way to Serpente ๐ https://github.com/atsamd-rs/atsamd/pull/141
This is a basic board with some examples for the Serpente board (https://serpente.solder.party/)
The basic blinky example is included as well as a PWM example with a cheap rainbow-y effect on the b...
@bright aspen its MP3Decoder now
my gosh, i made 1.5 pages of imx issues
im trying to work out why my CPB keeps disconnecting whin trying to update the circuitpython file, any tips or reading?
From datasheet:
The KPP is a 16-bit peripheral that can be used as a keypad matrix interface or as general purpose
input/output (I/O). It supports 8 x 8 external key pad matrix. Main features are:
โข Multiple-key detection
โข Long key-press detection
โข Standby key-press detection
โข Supports a 2-point and 3-point contact key matrix
@pastel panther I've pushed the .github directory to all of the effectively empty repositories and made PRs for the 4 repositories that I missed and tagged you in them. Looks like 2 are currently failing so I'll try fixing the pylint issues and get back to you on that in a few mins
@trim elm awesome
Got a chance to try my code on the ESP32-POE and -EVB today (running https://github.com/ssube/prometheus_express/blob/master/examples/olimex-esp32-random.py), with fantastic results on both wifi and wired. Socket timeouts appear to work there, allowing me to collect sensor information in between requests. Not seeing the ENOTCONN errors from wrk either, those only appear with the Wiznet hardware so far. Chrome, curl, and most important Prometheus are scraping the ESPs just fine.
The RT1062 has a TSC peripheral, could be useful!
From datasheet:
The controller utilizes ADC hardware trigger function and control switches in touch screen analogue block. The controller only supports 4-wire of 5-wire screen touch modes.
@pastel panther Actually, could you take a look at the 2 failing PRs? They're both pylint issues so I'm not sure whether or not to fix them
@trim elm ๐
I'm done!
@slender iron Thanks! I'm still learning how to navigate to what I need. And handle memory; new MP3Decoders eat lots of memory and I haven't figure out how to convince them to give it back.
@trim elm ok, I reviewed both PRs. Did you understand what I mean to do about the BLE library?
@pastel panther Yep
@pastel panther Ok, I've reverted the changes and rebased my PR on CPython
@cobalt dawn did you try downloading a fresh copy from the guide. Yours may be corrupted
@trim elm Ok. FYI I'm starting to think that rebasing on PRs with a substantial amount of discussion is probably best avoided. I think there's a good chance it could end up with a conversation that makes no sense because intermediary changes disappeared. No worries about current ones but something to think about for the future.
@trim elm I should clarify that I mean squashing commits with an interactive rebase. I have no opinion at the moment on regular rebasing
@pastel panther That makes a lot of sense. I'll keep that in mind
@cobalt dawn you can get it here https://learn.adafruit.com/bluefruit-playground-app/firmware
I did try downloading the fresh copy - i can't get it on to the CPB
but i will try again
Is the mounted drive CPLAYBOOT
it was when i started, it keeps kicking out when i try to move the firmware file over
How are you copying the file to it?
What is the name of the file?
i did not rename it, i did try nameing it to current but that went badly as well
Donโt rename it. What file is it?
it seems to dump out after time as well, i just discoverd
the one you just linked me
cplay_ble_v5.ino.uf2
i think let me check
yeah, thats what it's named in that learn page
2019-07-13 18:07 222 INFO_UF2.TXT
2019-07-13 18:07 120 INDEX.HTM
2019-07-13 18:07 600,064 CURRENT.UF2
3 File(s) 600,406 bytes
0 Dir(s) 3,457,024 bytes free```
looks different after it kicks out of bootloader mode
I'd like to take a look at this as part of a revamp I want to do to the STM32 version.
The drive should not be there any more
the cirruitpy ? or the otherone?
What do you see after it fails?
not the cplayboot
What is it? Should not be anything
circuitpy is what i see after it drops out of bootloader mode, it's what mu uses to move stuff on to it i think
I only tested by looking at the neopixel and checking if the colors change correctly, I would like to actually connect a scope on the line to see what is really happening there, but not sure when I'll get time to do this.
Ok. I guess it is not loading the new file so the old one with CIrcuitPython is still there
i could be missing a steap somewore
Are you still getting the error message when you try to copy the .uf2 file to it
Do you have another USB port
And rebooted
yep
I give up...
rebboting was an acident...
i ment to sleep
i was like crap
i have another cable someware i can try
One last stupid question. But your sure this is the CPB and not your CPX
yeah, the cpb is not in a case
the cpx is attached to sometihng atm
i had to sanity check that one
It was worth checking. It makes no sense to me.
i could try a factory reset i guss
How?
i think it's in the guide someware, i'll have to look
i was able to do it eventualy with the feather i borked
im sure this is something simple, i'll try to deal with it latter i think
Good luck
What was the problem?
no clue, i went for a bio and came back and did the same thing over again and it worked
i blame windows
im now exploring the app to give consturctive crits
im looking at the nepixels part and trying to see if i can build my own animation
Have fun.!
i think most of what i have to say is directed at the ios app?
i dislike the light sensor ui
the number alone is not helpful, i think something else on screen should change as a better hint to whats going on
You cannot make your own animation. They are hardcoded for now.
(Unless you want to edit some java or json and rebuild the app)
There should be a colored meter bar thing
Though "normal" room light registers pretty low in my experience. Try pointing a flashlight
Or leave the neo pixels on and swithch to light sensor module and use your hand or something to reflect the neopixel light back
there is a bar, but it's uncangeing
changeing
gha
i covered it with my hand in a bright room , i got snome good looking number values, but thats the only change i saw
@gilded cradle TIL that upstream maintainers can be given permission to push to a PRs compare branch
If I'd know that I could have cleaned up my own mess!
No problem. It's nice when they do (the default setting), but you have to submit a PR to their PR if not.
It's almost like the current state of github is the result of endless iteration based on the experience of millions of person hours of open source collaboration
Something like that
@raven canopy Here's my summary of the remaining libs from your 'not actionified' list:
Adafruit_CircuitPython_LSM303 - Has been archived
- I would like to update adabot to at least have the option of skipping archived repos. Additionally I don't think it would work to patch it because it's read only
Adafruit_CircuitPython_BLE -
- https://github.com/adafruit/Adafruit_CircuitPython_BLE/pull/49
- Waiting on a second PR to add ignores. Separate so we can easily revert it later
Adafruit_CircuitPython_Bundle -
- Pretty sure it needs a different approach because it's not really a lib. Let's chat about this
Adafruit_CircuitPython_Motor -
- Has been moved to Actions but a test of how to resolve the nested examples got merged into master. Will need to be patched by hand. Good example of why we donโt want to test on a branch involved in a PR.
Adafruit_CircuitPython_AdafruitIO -
- Updated with the fix that prompted all of this. Iโm hoping adabot will just skip it
@trim elm @idle owl ^
LSM303: already have a plan. would be a quick PR... https://github.com/adafruit/adabot/issues/125
Bundle: yep, that'll be a non-standard one.
AdafruitIO: the patch will skip, since it's already applied.
I'll do the patch for Motor right now
@cobalt dawn what numbers were you seeing? a few hundred or closer to 1k? As the bar gets closer to 1024 the color gets warmer. Does your change to yellow/orange/red? as is visible in this video: https://youtu.be/33CtigJeMX4?t=49 You may have to shine a very bright light directly at it to get it up that high
@pastel panther @trim elm re: Bundle, I already migrated the community bundle repo, so those can be used as a template. https://github.com/adafruit/CircuitPython_Community_Bundle/tree/master/.github/workflows
bonus: it won't need all that gawk mess. ๐
@trim elm did you finish your homework?!
@pastel panther Almost lol
at the low end of the spectrum the blue and other coolor colors can kind of blend in with the black/grey background a bit so it's harder to tell that it's filled in.
๐ง
@pastel panther the PR has been made
@pastel panther lol
I actually just finished
@trim elm Are you done for the evening?
@pastel panther I'm fine sticking around for a bit if there's something that needs to be done, although I don't think there's anything I can really move forward on with the Actions project, and I also believe I essentially finished the learn guides library manager project today
@trim elm we still need to make the PR I mentioned against the BLE lib to move the ignores from the .travis.yml to the individual files. Do you want to do that?
Sure
sweet, Dankeschรถn
alright. adabot updates made, patch verified. i'll PR it all in a few...
.... Running Patch Checks On 214 Repos ....
.... Patch Updates Completed ....
.... Patches Applied: 193
.... Patches Skipped: 17
.... Patches Failed: 4
waaaaaw @raven canopy thanks ๐
Yeah, thank you @raven canopy
@pastel panther Do you want me to push the changes to the branch I currently have a PR open on or to push to a new branch?
@trim elm A new branch, definitely. If you update the branch for the existing PR, it'll update that PR which is not what we want. New PR, new branch
๐
@raven canopy The 17 skipped were already updated?
@pastel panther Took a bit longer than expected, but I got the PR on BLE in
@tulip sleet @half sedge thanks for the ping..! ๐ I've replied via the issue on GitHub. https://github.com/mu-editor/mu/issues/872#issuecomment-572938658
@dhalbert Tested on our badge (nrf52840) and it works. I am not sure that this change makes sense for the Atmel samd port. Does the sercom peripheral enable internal pull-ups at all and even if it does if i read correctly in the datasheet they are very weak (40-60 kohm).
After the https://github.com/adafruit/circuitpython/commit/7f744a2369a5036cadfa05575da1704f709c98bb commit, the cxd56 port did not work. Function board_timerhook was not called. This PR fixes this issue.
Could you also add this in the commented-out code in the imx port? I want to make sure we keep it consistent between ports, even if it's not implemented yet.
https://github.com/adafruit/circuitpython/blob/master/ports/mimxrt10xx/common-hal/busio/I2C.c#L101
Thanks!
@bright aspen now you can change the ".file" property of MP3Decoder objects, which for me in JEplayer eliminated problems where I'd run out of memory. Just don't do it while actually playing that MP3Decoder object; this condition can't be detected, but it'll probably do something bad. [sorry I missed the discussion yesterday when it was fresh]
I don't even want to think how much more complex CPY code base will have to get to support dual cores https://twitter.com/NordicTweets/status/1215616086709866496?s=19
Demonstrating the classic game #Doom running on #nRF5340 at #CES2020, showing that you can have high performance and #lowpower #wireless in the same package. The game is running on one core, while the second core handles communication with a wireless #gamepad ๐ฎ #HappyWe...
Unless we load the BLE core with some spi slave code like the airlift and use the big core as if it was a single one
@bmeisels I have tried to make this consistently optional across ports. Though the specific use case you're mentioning doesn't apply to atmel-samd, I can imagine a use case, such a situation where one needs to set up the I2C object before powering the pullups. I don't expect it to be useful but I may as well do it. The alternative for consistency is to turn off the pullups in the nrf case, which would make your situation worse.
@arturo182 I pushed a commit for that.
@pastel panther After BLE gets merged, I'd like to remove all of my branches. Do we already have a way to do that similar to what @raven canopy did with patching the build.yml?
Thanks, @dhalbert and I agree, even though it's not as useful in samd, it doesn't hurt anything to have it and is more consistent so +1
@trim elm you'd probably have to write up a local script for that. Either via the GitHub API, or by cloning and git-fu-ing locally. Or, an "easy" manual way would be to go through the merged PRs, and click the "delete branch" button at the bottom.
@arturo182 when it goes wrong, what happens? You said wrong color, does that mean "white" or "off" or actually literally the wrong color but with normal brightness and stuff?
@raven canopy Ok. I'm gonna try to use the github api for the sake of learning how to use it better, but after 30 mins, if that's not working, I'll just clone it and do it that way
@indigo wedge thanks for the repo! I wonโt be at my desk for a while but Iโm wondering where your flexram code is
ah, i didn't commit it cause it wasnt working so i scrapped it
using the defaults now
Looks good, but I want to wait until we get the Pine64 boards added before merging this.
@gilded cradle I'm not quite sure how to resolve that conflict, it is greyed out on my end.
Ok, @marble hornet, I'll take a look...
When you do a git pull off of adafruit, it should tell you you have a merge conflict. You then edit the file and so it ends up how you want it and then push that to your branch.
Like here, you would delete all the stuff you don't need.
ah, I edited the paren in on the web, committing it right to master. maybe it didn't function like a push even though was directly to master.
then you do git add with the modified file and git merge --continue
You can push directly to your master and that's fine, but you should do a pull from adafruit first in case somebody else changed something
trying...
so I pulled from Adafruit can it said there were no issues?
From https://github.com/TG-Techie/Adafruit_CircuitPython_FocalTouch
* branch master -> FETCH_HEAD
Already up to date.```
in case someone is interested...i got a Rasp Pi w / Blinka + Electricity monitor to read our home's power readings and store in Rasp Pi's mongo db. https://github.com/BitKnitting/FitHome/wiki/ElectricityMonitor
@marble hornet, origin is your repository, not adafruit. Did you add a remote? If you're not sure, type git remote -v.
@indigo wedge I think the linker script for the 1062 may be wrong then
I had to reduce OCRAM down to 512k to get it working
Hmm, I did work for me before, I need to assemble another 1062 Feather and test
So teensy works?
Ah right maybe they fused ram in a specific way
@marble hornet, you can find a lot of good info about using git here: https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/grab-your-fork
That would explain it, guess you could compare with their linker in arduino core
@gilded cradle I think it worked!
I think it did too. I'll take a look again once it passes checks.
That was fast @slender iron ;) https://twitter.com/adafruit/status/1215691877674049536?s=19
@slender iron great job on the teensy 4.0!
@marble hornet thanks! want to try it out?
totally! i'll grab my teensy rn
teensy40
I've never upload to the teensy4.0 is there a you suggest, i'm googling rn
use the teensyloader
print("hello world")
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.D13)
led.switch_to_output()
while True:
led.value = True
time.sleep(0.1)
led.value = False
time.sleep(0.1)
oops
๐
teensy-loader is saying the hex is too large?
@indigo wedge hihi
๐
@slender iron does the sound right?
I'm sure there will be quirks and bugs
but OLED display is not detected, its a write-only display
and i have a I2C GPS not being detect, its a read-only device
so the i2c scan thingy may not be happy with non-RW devices
@marble hornet it shouldn't be. are you using a teensy 4?
yes, It's the only teensy I bought (b/c i heard you'd be porting cp to it)
@meager fog thanks for letting me know, i will have to check with a display too, i only tested with the audio chip on the evk, havent had time to do more
could you maybe post a comment in https://github.com/adafruit/circuitpython/issues/2483 or create a new issue?
it looks like it is registering over usb, i see a tty.usbmodem14501 in/dev
that's great to hear that it works at all ๐
yep works great for many basic i2c devices - good work ๐
thanks ๐
i2c scanning does not seem to find write-only/read-only devices (?):
SSD1306 OLED, and GTOP I2C GPS are not found on bus
@meager fog this is gonna sound like an office stereotype, but I've sent you an email 30 minutes ago or so ๐
yeah my inbox is really packed right now
i will get back to it shortly- was takinga lil break to ahve hardwar fun:)
i can just ask via DM cause it's just 2 quick questions if you prefer that
ah, it wasn't detecting it through a specific cable adapter.
it shows up!
as cp!
nice!
@indigo wedge ahh i have DM's off - i will look at email really soon ok?
promise!
just finishing my ๐ต L)
@marble hornet after loading you have to unplug it and plug back in for some reason
no worries, sorry to bother but it affects my evening plans kinda ๐
is it something I can help answer?
Think it has to be Limor or pt
kk
So cool!
DigitalInOut - verified ๐
also: wow! 744336 bytes free! (i had to read it twice)
@marble hornet there you go, hehe https://github.com/adafruit/circuitpython/issues?q=label%3Amimxrt10xx+is%3Aopen
@indigo wedge ok replied!
awesome, thanks so much
arturo, mimxrt10xx?
(that is the chip family on the teensy 4)
yeah that was the hardest part of the port, not the code, the name
rt10xx was too generic, initially it was imxrt10xx but then for some reason NXP uses mimxrt everywhere so i went with that
it should work with the whole family rt1011, rt1021, rt1025, rt1050, rt1062, rt1064 ๐
Progress....
@indigo wedge I just got out all of my evks, 1015, 1020 and 1050 in addition to the 1010 and 1060
I've been excited about it for a while
๐
๐ฌ
oh yeah i forgot the rt1015
their evk naming is odd
they name them after the series
but then rt1015 is the actual chip
ya, weird
I'll do some I2C testing later w/ the chips i have here. and some spi testing with one of the chinese displays I have
and is there any discuss of canbus support?
I think there is an issue for can
pierre from my hardware happy hour crew is very interested in CAN too
Feel free to stub it into other ports if that is simpler. I wouldn't be surprised if others needed it in the future.
STM32F405 has native CAN support - that is likely the best 'native' chipset to start with
the MCP2515 can add CAN over SPI, its a popular chip
@lime trellis btw you may be interested in NXP RT series for spacestuff - its XIP from external flash which you wanted for durability - and fast as heck
Thanks for the fix! Sorry I'm late on the review.
@pbricmont Please email me scott@adafruit.com and we'll get you setup.
@meager fog I remember you mentioning you liked that about the NXP, thank you! Interestingly enough, I'm told by an old Atmel contact that the D51 have XIP capability as well ๐ฑ haven't tried to find the mysterious registers yet
Oh and it's quite likely there'll be as many as 6 spacecraft running CircuitPython in space by June โฅ๏ธโฅ๏ธ๐
@tulip sleet you should categorize and tag your blog post
@slender iron oops, I thought i did, will do now
np
btw, still debugging bonding, but making progress
cool cool. I've gotten sucked into imx rt fun
going through email and reviews now though
worth posting here at some point: https://forum.pjrc.com/threads/58943-CircuitPython-port-to-RT1062
I have the top four so I'll take a stab at it today once I'm through email and reviews.
yup, will do today. I think I'll start a new thread and link to it from that one
I emailed paul last night about it
I'd like to start marking CircuitPython code and data so we can separate it into specific RAMs. That should speed up all SoCs which have tightly coupled memory (TCM).
@lime trellis D51 can do XIP but circuitpython isnt structured for it unless you're ok having two chips one for code and one for storage. it might be easier to move chips than try to shoehorn it in.
you can mock ParallelBus, we dont have parallel on most chips - see what we did with STM32 and/or @hierophect can explain!
@meager fog the imx rt works by accessing the flash fs through the xip (its the "internal" flash)
Update on this: my current issue is that once Circuitpython is loaded via the UF2 file, SysTick_Handler is no longer called, meaning ticks_ms never updates and CPy gets stuck in the first timed loop of the program in wait_for_safe_mode_reset. This persists if the program is hard reset. I'd guess this is the result of the some issue with the vector table, but I'm having trouble pinning it down - meowbit-micropython just uses the usual startup object file, so no changes there, and there aren'...
_pixelbuf.buf doesn't have a setter, breaking some code.
See https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel/issues/65
@ionic elk how does the bootloader force us to start at the 64k block?
is that where the isr table needs to be?
I don't have much information other than that their linker file claims this /* sector 4, sec 0~3 reserved for booloader */
hrm, have a link to that?
I could omit that requirement and restrict the bootloader to Sector 0 (which is what it's own bootloader defines) but I don't have a working control to test that.
The micropython for meowbit from https://github.com/micropython/micropython - KittenBot/micropython_meowbit
Right, that's the ideal
the alternative would be to figure out the display and flash sharing issue
I'd like to do that anyway but probably later ๐ฌ
I think the best thing to do for that would be an option to disable the REPL display when resetting in DisplayIO
They're both on the same bus
So you can't flash to memory and have DisplayIO going at the same time, or even too close to each other, without getting collisions.
Big crashes, etc
hrm, they should be both using a lock to share time
Well, I can look into it more. But for right now I'd really like to get over this bootloader thingy - it's the only thing I see as really holding back this initial PR
Because people can't load code onto their boards without it, unless they solder on a SWD header and buy an STLink
so what do you propose?
If I can just get an internal filesystem Meowbit that's bootloader and display capable in for 5.0, I figure we can revisit the DisplayIO issues a little further down the line. Maybe even poke Kittenbot to put them on different buses
Does that sound OK?
they are not going to change the hardware
where are you going to put the internal fs?
Hopefully in the 48K?
how are you initing the display?
Sorry for the indecisiveness! There's just a lot of tradeoffs with this board. Display works fine if it uses the internal filesystem, it only has issues with external flash.
right, that seems like the ideal though, external flash and the display
the locking should work as long as the display and the flash are using the same spi object
I can shoot for the ideal if that's preferable and there's nothing higher priority. I'll take a closer look at what's going on there, and why they aren't properly excluding each other.
lets talk it over now for 30 minutes
sure
Hello There ....
Very sorry to bother you folks but any Pew Pew 10.2 owners here that may be able to answer a question about this device?
@stuck elbow is the creator too
@hierophect and I just chatted. He is going to focus on the Systick issue today and the start of monday and then we'll sync up on it.
Hello there i am very new at discord chat so please accept my apologies for any first-time errors! I have just received a PewPew 10.2 from MakerFab & am very happy with it. I have noticed that when scrolling or displaying from the included games,some of the ( Pixels?) appear dimmer than others even though they seem to be set at the same brighness in the source code. Is this justsomething to dio with the particular unit i have?
@cunning verge that sounds like a faulty unit
@cunning verge can you make a program that fills the whole screen and take a photo?
will do give me a couple of ticks as my last bit of practical programming was back in the last century!!!
almost there!!!
@cunning verge something like:
import pew
pew.init()
screen = pew.Pix()
for y in range(8):
for x in range(8):
screen.pixel(x, y, 1)
pew.show(screen)
while True:
pass
iJust uploading video from my phone tio my pc as no comera on my pc - Sorry to keep you folks waiting
if i just fill the entire display witha staic image i get this.....which seems ok
but if the screen is scrolling i get this..... please forgive the very poor image/video quality as the lighting here is not good
but if the screen is scrolling i get this.....
I think my analysis of why the uf2 bootloader wouldn't boot into CPy was hasty and incorrect now that it does so :)
Notice how some of the pixels appeaer dimmer. At first i thought some of them were faulty but when scrolling you can see that the dimness scrolls as well.
@cunning verge I see what you mean, and unfortunately that is normal โ if there are a lot of bright LEDs in a line, they get a bit dimmer together
@cunning verge that is because the current that goes to the line is not stabilized, it's a very simple circuit
I had to cut some corners to get it to $10 price point, sorry
Ok I thought it may be something like that . Not a problem. I am really loving this device & am grateful to you for designing it. Wish i'd bought it previously from your Tindie so at least you would have got a couple of CHF from me. No corners were cut i as far as i can see! I really appreciate the help this evening ( in the UK ). Lookin forward to the M4 version & am already singed up to the waiting list.
I'm getting money from the sales on makerfabs as well
initially I didn't want to, but they just started to put it away for me
the M4 will be only on makerfabs, though maybe they will also put it on Tindie
anyways, glad you like it
already thinking of getting another couple next time i shop on Tindie. You can never have too many
Hi, I wanted to try some BLE example apparently written for "Feather nRF52840 Express" and it use "board.RED_LED" for notification. But I was testing the code on "Circuit Playground Bluefruit" and there the red LED is named "board.D13". Would it make sense to have the RED_LED (as an alias?) also on Circuit Playground Bluefruit? I don't know, maybe there is a rule or a logic... but having exactly the same code for Blink on every board could be a goal.
Hi @tulip sleet and @slender iron, I may have found a regression in the BLE part between 5.0.0-beta.2 and 5.0.0-beta.3. It is documented here: https://github.com/hydronics2/nrf52840-LED-hat/issues/1
It might be a bit difficult to reproduce without the hardware... or there is an API change... or the code was not supposed to work in the first place.
It is not my code, I just tried => FAIL, downgraded => SUCCESS, upgraded => FAIL.
that happens when the connection disconnects
Yes but it systematically works with beta2 and systematically fail with beta3.
it used to crash in a different less friendly way
At least I tried each version twice.
Very close.
the discovery process can be slow and increase the likelihood of a disconnect
The code has a kind of discovery loop, then when found, it try to start talking to it.
But then again, it is not my code... it just feel the explanation does not match what I experience.
I will return to beta.3 and try 10 times to see if it is systematic or not.
I changed nothing to the code... and now I have 95% success rate (with beta.3). Or let's say one failure out of 20 attempts.
@half sedge that is the tricky thing about BLE, sometimes the other device just disappears. ๐
hehe, my PR gets a mention
guess I peaked early this year, time to sit back and do nothing till 2021 xD
this is just the start ๐
@slender iron Now that my success rate is so high... it is hard to reproduce, but it is NOT related to the version. Now I search for a way to trigger more frequently to write the right code to work around it. It seems that if I connect from my phone to the device, then I try from the CPB, I have more chance to trigger it. I'll update my issue to avoid unnecessary search by the author.
๐
@slender iron Is there enough info in the INFO_UF2.txt on a board's BOOT drive to tell what CP build it would need? I see the Model and Board-ID fields but I'm not sure if that's enough to identify the board.
If not, how about in the Uf2? Could one theoretically get the current build commit or tag from it?
not without pulling the whole uf2 off
ok
we could fix the memory address of that info though
or you can just let if boot up and grab it from boot.txt
right. Is there a way to force it into bootloader mode from software?
I need this for Teensy 4 so I'm doing it now.
awesome, tag me for review when it's ready :)
it'd be cool if we had a boot stub we could include in our teensy hex files but not the uf2
or we just rely on the uf2 bootloader not overwriting itself...
ahh default i2c frequency for scanning (at least) is 1MHz, should be 100khz to allow all things to respond. many devices dont work at 1Mhz :) for now, im testing with
i2c = busio.I2C(board.SCL0, board.SDA0, frequency=100000)
SPI freq is 2x faster than expected, setting it to 4MHz -> 8MHz clock speed
@indigo wedge ok leavin notes on issues as i test hardware, SPI and I2C are working other than speed setting bugs
im able to use airlift to connect to internet
@onyx hinge Thanks for the tip on using the .file property of MP3Decoder objects.
@meager fog good to hear airlift works, I tried to make a uart pass-through in CPY to flash the esp on my Feather but it didn't seem to work, will try to flash it externally and verify it's not a HW issue, at least now I know the spi part should work :)
This is all great info, thanks :)
was looking at a high def photo of the rt1060 evk and noticed it says PIMX (also, nice NXP photoshop) so i checked the ordering info again and now I know what the M in MIMX stands for
@slender iron @meager fog
@indigo wedge should we drop the "m" prefix from the port name? just imxrt10xx?
that makes sense to me
that was the initial name of the port but i changed it becuase all the names in the SDK use the M prefix
so it was a weird mix of imx and mimx
i guess it doesn't really matter
yeah let's keep it as is, can't be changed after it was a part of the beta ๐
I am opening this issue here as the error seems like it's a problem with the runtime, not the turtle library.
When running turtle_square01.py from https://learn.adafruit.com/turtle-graphics-gizmo/turtle-graphics-on-gizmo I get the following traceback:
Traceback (most recent call last):
File "code.py", line 61, in
File "/lib/adafruit_turtle.py", line 218, in forward
TypeError: 'Vec2D' object is not subscriptable
This is on a Circuit Playground Bluefruit with the TFT Gi...
I did testing of this and found that the scaling of voices prevented clipping or overflows in the scenarios I used, with 1 or 2 voices. (I did not test >2 voices though)
There was a regression in 5.0.0-beta.3 affecting subscripting: #2465. If you are using beta.3 try beta.2 and see if the problem goes away. Thanks.
@tulip sleet @indigo wedge I think my preference would be to remove the m. that way it will match the top level nxp page for it
I don't think it will impact anything public. we can leave board names the same
ok by me!
@indigo wedge you'll want to patch the "SPI is 2x too fast" issue before trying airlift as the doubled freq is too fast for the ESP32 ๐
@meager fog so you just tested with setting it half the speed you wanted?
yeah i manually edited the .py
to halve it
if you use the mpy/default the esp32 doesnt respond
Of course, .py for life ;)
I agree with @reversefold that a has-a relationship is preferable in general. I believe I ported that code over from the cpython turtle implementation. Silver lining is that it put a spotlight on the inheritance bug.
Finally figured out a way around this weird JS importing issue so now the app is allowing user to drag the 3D Model in the Accelerometer Module to move the camera around like the iOS one.
@solar whale when you have a moment can you try out the new v05 APK in the repo https://github.com/FoamyGuy/Android_Bluefruit_Playground. I've got the neopixel module re-aligned to hopefully fit the two screens on your devices.
@lone axle this is the ZTE,. Looks good but the app crashes if I open the Accel. Module
it runs fora few seconds then stops and says tells me the App stopped
hmm, I must've broken something
Nice, thank you for trying it out ๐
I'll see if I can figure out what happened with the accel.
weird. I double checked the apk in the root and It is loading on my phone. Thought maybe I just put the wrong one in there but can't be that.
you don't know of anything else that might be using port 8000 on your devices by chance do you? Part of the fix for the accel module to allow dragging the camera view involves hosting the web page that renders the model inside a webserver in the app and it's running on port 8000. I imagine if something else was already using the port it could have trouble
hmmm -- not that I am aware of, but I am fairly Android illiterate ....
I'll try it out on a few more devices around here. So far I've only tested my own phone, but I have a few others I can try.
both phone were just power cycled -- I don't think there is a lot running
If I can't replicate it here I may make a build for you to try that will save some extra logs to see what is causing the crash.
the moto-x was complaing about gboard stopping -- I had to revert the updates
until then I had no idea what gboard was...
also having trouble reconnecting to the CPB on both phones.. power cycling and trying again.
hung on connecting screen --
the pop-up with the spinny thing?
yes
you have the same UF2 still on the CPB right?
yes --- just got in ok on the Moto-x --- IOS is able to connect/disconnect -- while it is hung -- other devices cannot connect
hmm, I haven't done much testing around jumping between devices. In my testing I always explicitly go all the way back and disconnect on each device.
getting worse -- Moto-x connected, but no sounds when using tone generator....
It's possible the cleanup is not handled properly in some scenarios
weird, seems like it's not fully connected tbh, I'm not sure why it is making it past the pop-up
tones ok on IOS but not on Moto-x
no -- but nothing works with the moto-x --
You said that is 5.1 the other day I think right?
rebooted CPB -- still not working -- connects, but no responses at CPB -- yes 5.1
tryin ZTE again
I managed to get a crash on the accel screen on one of the phones I have to test
good -- Iguess ๐ ZTE is working OK now
the moto-x may be flaky -- given the issue with gboard.
I have a 5.something moto device that I wasn't able to get the BLE to work fully on either. But mine is funky for some other reasons too.
ZTE -- disconnected and reconnected Ok -- and seesm to be working OK -- have not tried accel again
is it possible that accel crash leaves it in a bad state?
Hmm it could be. To be honest I'm not 100% sure how the code on the CPB side works.
I found the source if you want it
its in the examples for the bluefruit52 libraries - cplay_ble
From the android app I think the worst case failure mode could be to turn on the notifications for accel data by writing the CCCD characteristic and then never going back and disabling the notifications (in the event of a bad crash) I'm not sure how the CPB would handle it
oh yeah that would be helpful
Thank you
https://github.com/adafruit/Adafruit_nRF52_Arduino/tree/master/libraries/Bluefruit52Lib/examples/Peripheral/cplay_ble some of the comments are a bit misleading, but I did build an load this
In my case the crash in the accelerometer module does not seem to put the CPB in a bad state
it does crash the app, but I can re-launch then reconnect and use the other modules with no issues
The crash I am seeing is out of memory during reading one of the files for the 3D model rendering web page in the new way it's being served. I think the other devices I've tested on have more memory so I didn't see it on them because the system alloted a bit more.
well -- so far the ZTE and IOS are working fine -- I'm not too concerned about the moto-x -- it may have its own issues
ok -- now on ZTE trying to connect - but in the In progress popup it says "test1" not "connecting" and it is spinning
sorry -- I have to go offline for awhile ... good luck!
No worries, Thank you
This fix should address #2465 by making sure that any native type using mp_obj_tuple_subscr gets the native instance it needs. There might be more unit tests needed to verify all instances of mp_obj_tuple_subscr work properly when subclassed:
./shared-bindings/time/__init__.c: .subscr = mp_obj_tuple_subscr,
./shared-bindings/fontio/Glyph.c: .subscr = mp_obj_tuple_subscr,
./py/objattrtuple.c: .subscr = mp_obj_tuple_subscr,
./py/objexcept.c: .subscr = mp_obj_...
Looks like that's the issue, yes. Thanks, I'll try beta2.
@solar whale no rush at all, but there is a v06 apk file now that I'm hoping fixes the accelerometer module issue. This version fixes the crash that I was able to reproduce.
trying it now
@lone axle tried V06 -- worked on both ZTE and MOTO-x -- even accel drag worked -- on the ZTE, the accel impage is solid black -- looks OK in the Moto-x -- THe neopixel demos seem "sluggish" with both -- compared to IOS --- is that expected?
the animations, yeah I think so
I don't have access to an iOS device to see it IRL, but in the video I saw the animations seemed to be able to go quicker on iOS.
other tahtn the black image on the ZTE accel --it seems to be working well.
I spent some time trying to speed it up a bit but it seems there is some limitation on android. It seems to take 200-250ms or so to write the BLE characteristic. So it can't change the neo pixels any faster than that.
ooh -- moto-x is showing the "test1" in the In progress popup now -- trying to reconnect
Ah, I see what's causing that test1 now
The dialog message defaults to that right now, and only changes when it receives the first update from he service which usually comes pretty quick
I stopped the app and it restarted ok
the accel image is normal on moto-x -- just wanted to verify
something is making it have trouble connecting, or atleast making it take extra time (I've seen pretty variable times as well) when you see that test1. I'll change the message to something more descriptive
the black CPB model is odd, I did see that at one point but thought I had it taken care of. I'll have to take another look
big improvement overall! nice job!
ty, and thanks for trying it out again.
glad to help!
the neopixel animations can speed up just a hair. Right now they are set at a hardcoded 300ms but do sometimes still slip a bit because of the write taking so long. At one point I had it working writing as soon as the previous one was complete. I intend to switch back to that way probably.
but even with that change I still think it's slower than it seems the iOS one can get.
(the fastest speed is hard coded to 300ms. The bar slows it down from there)
I forgot about the "speed bar -- much better if I speed it up ๐
certainly makes a good demo!
oh, yeah at their slowest I think it's 1 second between frames or something very slow.
do you have a sense for if the slowest speed on the iOS app faster than the slowest speed in Android?
not really -- on IOS -- slowest actually stops
Oh, just frozen on whatever the last frame was?
on the moto-x -- if I let the animation run awhile, I was not able to get it to stop...
yes -- seems t be
on the IOS at lowst speed
Ah, yeah. Right now the animation frames get stacked up waiting to be sent if the writes are taking longer than the intended speed. The turn all off button should be stopping them but it doesn't do it properly I've seen sometimes.
Switching over to "write the next one as soon as the last one is complete" methodology will solve that issue as well.
ok -- seems better on the ZTE
when it is lagging -- even moving to a different module does not help
ZTE accel screen
I've noticed a difference in the lagginess between a few of my devices as well. Seems some of the newer devices can write a bit quicker
Oooo
Ok, I had it a bit different actually
Mine was showing black board but still had the components.
That is odd, I am surprised it loaded that much of the shape without showing the components both should be coming from the same model file.
hmm
The ZTE used to show the board correctly right? Before I started working on the touch dragging.
I'm going to make an apk using the old style to check
Oh, yeah that would work
trying 03
all black on 03
trying 04
oops -- dont have 04 and 05 is the one tht does not work
so -- loks like all the ones I have ar all black
did you have 02?
Ok, thank you
You're welcome.
time for me to call it a night -- thanks for all the work on this. And for giving me a reason to play with the Android phones!
G'night
The file py.mk contained a mix of references to PYTHON and PYTHON3, and did not build on a fresh install of Ubuntu (under Windows LXSS). Converting all of these to PYTHON3 fixed the issue
@lone axle Hi, I have noticed on my phone and on screen shoot here that the Z Euler Angles was a always 0. I was wondering if that was a bug or else. (I don't have an IOS to compare nor the math to figure out if this is normal). Regards
@half sedge same on IOS
Hi.
I was writing a little program for reading 3 ADCs of a trinket m0. When I started tuning for some performance, I ran in this particular observation. Adding or removing a dummy variable influences the speed about 10%. I assume it has to do withe the internals of Python, e.g. the evaluation of a hashtable or something like that.
The code I run:
import board
import analogio
from time import monotonic
import busio
import supervisor
supervisor.set_rgb_status_brightness(0)
...
some thoughts for CircuitPython2020 https://gist.github.com/jerryneedell/f09d6db0e1689c92bde27618f4548fb7
@half sedge yep that is correct, the Z eueler angle does always show 0. I think it is supposed to work like that. Though to be honest I don't quite grok the math involved. I found the formulas in the iOS app source code and understand enough to get them translated over to work in Java, but not a full understanding of it.
@lone axle @half sedge While it is the same for IOS and Android, I'm not sure how to interpret it either but if you lay the CPB on a flat surface you will see the x,y Accel and all 3 Euler Angles read near zero and the z accel read about 10. then if you slowly rotate it while keeping it flat on the table -- none of the readings change where as if you slide or shake it still flat on the table, the measure values do change.
It is not clear to me why when you pick up the CPB and move it about, the image shows orientation, but the Z Euler angle stays 0.
Ah interesting - I just realized that the image does not rotate when you have the CPB flat. it really is not showing orientation. Something is odd about "yaw" ... or at least my understanding of it.
Yeah i think its unable to know the rotation when its flat
I think i saw something like that in one of the documentation pages. Ill see if i can find where.
rotations always make my head hurt...
Ha, I hear you there.
This is the warning I saw. Its in the learn guide for the Bluefruit Playground app: "Accelerometers cannot detect 'twisting' motion so you will see changes when you tilt the board, but not spin it."
Yes, you need a gyroscope or compass/magnetometer to detect rotation.
Do you know if the lack of ability to detect rotation is what causes the Z Euler angle to always be 0? Or is that unrelated?
OK -- so taht explains why "yaw (Euler z)" is always zero.
in my understanding Euler z is "twist"
Ah I see.
x is "pitch" -- up.down of the "nose" y is "roll" (wing tilt) -- z is "yaw" (twist)
Ah, thank you. That helps me visualize it better than I was able to before.
I think I have roll/pitch swapped -- at least how they are marked on the CPB -- fixed above
it shows y being along the JST/USB connector line and X perpendicular. If you tllt he usb connector up/dow the X euler angle changes -- that is a rotation of the x axis -- so I had it right the first time ... rats. as i said -- makes my head hurt..
a rotation about the JST/USB (Y axis) id Roll or the Y Euler angle
I think of it as flying with the USB connector being the nose of the plane
ooh -- the sun's out and it is warm here (unusaully so for jan in NH- 60 degrees F) taking the dog for a walk....
Nice, enjoy. Suns out a bit here but still got the snow from yesterday on everything. Still going to get out and about for a while as well though
Meet Mitch today at OpenTech Day Delhi. Discussed state of circuitpython with him and other community members. Ease of getting up and running with circuitpython left everyone awestruck ๐
And hereโs python 3 and pyBadge
Ok, here's my CircuitPython 2020!
I was glad get to draft this with my buddy Don Blair, who uses Circuitpython for a bunch of scientific work on ocean and agricultural monitoring.
I'm super pumped about the stuff he's doing and I hope others are as well.
Happy to chat on Monday if u want. Should be pretty easy and I can help if it isn't.
Do you have a Saleae? Hands down the easiest tool for this kind of monitoring that I've used. Scope will also show it but the Saleae is just so easy to set up and read with.
Does anybody knows the story behind pIRkey?
Was it ever officially released?
Adafruit pIRkey - a Python Programmable InfraRed USB Adapter
PRODUCT ID:ย 3364
https://www.adafruit.com/product/3364
Coming soon! We want to reprogram our stock with the newest CircuitPython 3.0 before shipping these out.
No worries, I/someone can just copy the file directly from the stm port and it will work, I'm just a bit stuck in the HW world right now, need a few days :)
I have a Chinese clone that works with the Saleae UI and I really like it, I was just worried if it's fast enough, also it's digital-only so if there's some weirdness on the line, I would miss it.
<@&356864093652516868> 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 Iโll read them off during the meeting. Hope to see you there! https://docs.google.com/document/d/1IA9bA0Inf2JrTk_CbDvENPPGOuqmmtdmfv5Nj2sbKmg/edit
Note: I didn't test on HW, just read some diffs.
My personal style would parenthesize (1<<0) and so on, but I don't know whether that's CP style or not.
While it's not used consistently, it's worth noting that there's a macro for this...
py/misc.h:#define MP_ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
Here is my last minute #circuitpython-dev2020 contribution. A secret Gist that I also linked from a Tweet with the proper hashtag (so not very secret): https://gist.github.com/dglaude/9a9ca530f2a96d6087142fcc42ac40fa
@half sedge ladyada wasn't happy with the performance of it so she's added reworking it to her backlog
@slender iron You are talking about the IR thing. OK. The thing is that it was advertised in video and in a CircuitPython Release Blog post (I know because I did read many of those today). I had some IR needs in the past... initially it was receive only, so I went for Flirc. Later I needed send and receive, so I did LIRC on the Pi. And at one point I used my CPE for learning the IR code and a Trinket M0 for the sending. So hopefully, I did not wait for the pIRkey ;-). It is just that the product description say it is waiting for CP 3.0 were CP 5.0 is almost out... so it is not consistent with reality.
was last week's recording posted?
@half sedge ya, for pirkey. It's in a weird twilight zone
Thanks to @arturo182's work on the iMX RT series in Python, we can now easily support Teensy 4!
There are many issues still to work out but a bunch of stuff does work. Check the GitHub label for relevant issues here: https://github.com/adafruit/circuitpython/issues?q=is%3A...
@indigo wedge https://www.youtube.com/watch?v=F7YWP_iHWHk
Meeting notes are available here: https://github.com/adafruit/adafruit-circuitpython-weekly-meeting/blob/master/2020/2020-01-06.md
Join here for the chat all week: http://adafru.it/discord
The weekly happens normally at 2pm ET/11am PT on Mondays except when US holidays occu...
@indigo wedge And you can follow the YT video with the text transcript with timestamp, it is in chronological order... a new things for 2020.
Thank you โบ๏ธ
By the way... the weekly meeting is very late in CET timezone. Most of the time, I am likely to follow that in "VOD" rather than "LIVE". So that's why the transcript and the video are important.
Does anyone know if the pyportal.wget function from the pyportal library supports saving the file to the SDcard?
if there's an SD card it should default to that
Does anything special need to be done before calling wget? I was getting read only file permission error
file parameter was just a name like "myfile.bmp"
@raven canopy you've got my
to proceed with adabot at your convenience
@trim elm @idle owl heads up ^
@lone axle should detect it automatically if the SD card is inserted
Ok, Thank you.
yuo can set debug=True in pyportal kwargs too
@raven canopy Is there a way to get the output of Adabot in a text file? I'm trying to get a list of all circuitpython repositories to draft releases on all of them.
Got a successful download now! Thanks again.
I would love to see a very basic download and show a bmp file example. If it doesn't exist I will try to make one once I get it figured out all the way
It seems there is something weird with the Django debug server. wget of files hosted by it on the local network seem to get hung. But elsewhere online works fine.
@trim elm sorry. was afk. running most of the adabot scripts with -o <path/filename> argument will output the results to a file. (-h for any other options)
Ah, ok. Thanks!
Who do I tell about webpage errors on https://circuitpython.org/awesome ? Bad discord link: https://discord.gg/EAeBY6x
CircuitPython Organization
@digital summit its from here: https://github.com/adafruit/awesome-circuitpython
Actually it seems my issue was perhaps the size of the file and not the server. My file was a bmp, but wasn't indexed color mode. and was ~230kb. Once converted it's about 75kb and it seems to finish downloading and show just fne.
https://discord.gg/EAeBY6x
should be
https://discord.gg/adafruit
Tried to create a branch and pull request, but I'm not authorized.
Patch
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 6e19993..2d68fc0 100644
--- a/README.md
+++ b/README.md
@@ -39,7 +39,7 @@
## Community
-- [Adafruit CircuitPython Discord channel #CircuitPython](https://discord.gg/EAeBY6x) - 24/7 chat and support on CircuitPython inc...
please submit a PR from your own fork :)
Here is a GitHub getting started guide: https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github
This is great!
I suspect the Teensy 4.0 may be difficult due to its onboard MKL02 running PJRC's proprietary bootloader code (sitting in the middle of the RT1062's debug interfaces).
I'm working on an embed-friendly surface-mount RT1062 board (see https://forum.pjrc.com/threads/58795) that has space for a Teensy 4.0 bootloader chip (when they eventually become available) but doesn't require one. They'll be sold but also released as open-hardware once the design is verified.
I'd love ...
there seems to be a built in USB loader of some sort. if so, you could use that to load the UF2 bootloader so no external chip is required
From what I was able to find out, the ROM bootloader can only load code to RAM, not to the external flash. We would need a 0-stage uf2 bootloader that loads to RAM that would allow loading the regular uf2 bootloader to flash.
General question about CircuitPython + Bluetooth support. I've seen a lot about CPY + BLE and this driver https://github.com/adafruit/Adafruit_CircuitPython_BLE
What hardware does it support exactly? It is the same as the common Arduino BT05 modules? Do they need a separate driver to communicate to their UART interface?
I just want to be able to use Bluetooth to communicate with a BT05. Trying to work out if any CircuitPython_Driver is required to be written.
So for other UART to Bluetooth modules like this one: https://www.adafruit.com/product/2479 Support for CircuitPython needs to be added/created?
yes, I'm not sure if anything exists already
but the good news is that it can be done in python, no need for C code for that
I couldn't find anything on the official Adafruit Github. All the Learn Guides seem to point to using Arduino.
@stuck elbow Thanks. I'll start working on that. They all use the same standard commands. So getting it working should be a good addition.
I'm actually surprised there is not something already out there...
Instead of using precompiled binary files, mkspk will be built from source files on the user's platform. This should solve issue https://github.com/adafruit/circuitpython/issues/2278
@craggy galleon I am not an expert, but I feel that the BT05 is traditional BT. So serial over BT would be RFCOMM protocol. But in CP we have some BLE support, a different kind of Bluetooth!
I don't know how standard is that Nordic UART TX/RX thing, compare to RFCOMM.
I don't know the relationship between the old Adafruit Bluefruit LE range of product (that only have Arduino support) that is hardware add-on for board with no BLE support, and the nRF52840 that could maybe do that with a bit of software. I hope that will one day be possible (without AT command).
@stuck elbow Running just the existing BLE code doesn't work because it expects _ble to be built into the circuitpython firmware running on the board. ๐ข
@half sedge I was hoping to just implement the AT commands and hope for the best. I was reading up on it just then and seems straight forward. I am actually looking at implementing it for a "BT07" but I couldn't find any information about them. Anything that can do a UART bridge would be good.
@craggy galleon there isa library for the BLE SPI Friend, but not for the UART Friend
@solar whale this one?
https://github.com/adafruit/Adafruit_CircuitPython_BluefruitSPI
yes
cool ๐ Thank you for this. Going to make creating a UART one waaaay eaiser.
@half sedge BLEIO-like with airlift/nina-fw is on my radar for 2020.
@indigo wedge looks like it made it to diode.zone at any rate https://diode.zone/videos/watch/19283f6b-6b82-4cdb-911e-7cd3cd76df23
Meeting notes are available here: https://github.com/adafruit/adafruit-circuitpython-weekly-meeting/blob/master/2020/2020-01-06.md
Join here for the chat all week: http://adafru.it/discord
The weekly happens normally at 2pm ET/11am PT on Mondays except when US holidays occu...
Thanks, I already got it ๐
oops I was scrolled way back again.
Is this awaiting further review?
@crimson ferry https://mcuoneclipse.com/2019/09/22/eclipse-jtag-debugging-the-esp32-with-a-segger-j-link/ < someone got the esp32 working, unofficially, with a jlink and gdb. I'm going to try this when time frees up again as it'll be useful for BLEIO/Nina-fw
@prime flower That looks promising, could help immensely with complex or intermittent behaviors.
@crimson ferry Yeah, only issue is ESP32 FeatherWings dont have these esp32 internal pins broken out, I may solder directly to pins or make a "airlift debuger FeatherWing" for myself, to stack on top of it
the wrover v4.1 kit should work directly, I have one of them but haven't tried that with circuitpython/esp32spi yet
Could even debug with a HUZZAH for Airlift targets, no difference functionally except connected pins.
Yeah, I'll need to look at that breakout. printf'ing through FreeRTOS is not ideal.
(or Feather ESP32... only material difference is HUZZAH has pins 0 and 2, but no USB)
@prime flower About airlift/nina-fw , are referring to my #CircuitPython2020 post? If we can upgrade the ESP32 and use our AirLift hardware for both WiFi and BLE (simultaneously?), that would be great!
That would upgrade the value of existing PyPortal, and AirLift FeatherWing.
I am still a bit confused by the various options: (1) the old BluefruitSPI [and the Bluefruit UART equivalent?] (2) nRF52840 possibilities (3) the potential to upgrade an AirLift to add BLElift.
I don't fully grasp the potential differences, integration challenge, cost/benefit.
@half sedge Yes, referring to your post. You can not use the ESP32's WiFi/BT radios simultaneously, they need to be used separately.
Out of curiosity - what use cases do you have if you could've used the radios at the same time?
Well, I was wondering if one board had both WiFi and BLE. I could thing of a nRF52840 + Airlift.
The idea is that you could have at home multiple BLE only device, and one device that bridge them to the internet. That device require both technology.
A smart watch is BLE only. A Smartphone is BLE+internet and bridge your SmartWatch need.
I was hoping either @tannewt or @dhalbert would review this small addition to circuitpy_mpconfig.h, since that's a micropython holdover, and I'm not always aware of cascade affects that can occur from changes to that kind of file.
@gilded cradle Do you have a minute?
Got my titano case from the printer. ๐
@solar whale Nice print! Question: do you have a minute and a mic hooked up?
Yes, except my network just went down. Perfect timing. Sigh.
And entire machine crashed. Unrelated as far as I know.
ok -- I'm available to test when you get restored.
my WIP modifications to the AudioMixer correctly saturate, including when playing multiple channels, and don't divide the signal down.
this is a combination of two sine wave mp3s from flash on pygamer, one is set to volume .7 and the other is volume 1.0
Yup, looks clipped to me
that's the goal, if the user doesn't want clipped then they can set the levels. If the levels sum to less than 1.0 then no clipping will occur, but they have to decide on the relative volume of things.
Just like in the analogue world, which I'm guessing was your goal
if there's a better technique or outcome that is feasible I'd love to hear about it ๐ before I do the other 3 cases (signed and unsigned 8 bit, unsigned 16 bit)
Laptop won't boot. Network failover did not occur. Today is shaping up to be great.
it's not QUITE analog world, the "saturation" happens after each channel is added in, so if you have A+B-A, but A+B saturates, then you don't end up with just B. In analog world with a 3-summing amplifier I think you would
You could implement a normalized or average mixer which wouldn't clip, but I doubt it would be worth the trouble.
the old code was arranged so that clipping would never occur, but with increasing number of samples/voices they would individually become very faint. I think it was partially by accident but then we started to think it was a feature
They're both valid approachs, with different pros and cons.
since each voice has a level, you can set e.g., each level to 0.33 for 3 voices and it ends up being essentially an average
Ok, back on reduced internet and still looking shifty at my laptop of dubious reliability.
@solar whale If you're still around, can you jump into the CircuitPython voice channel so I can see if OBS and Discord audio are working properly or if I have to fight with it?
Thank you!
@idle owl I'm around if you haven't tested yet
Does anybody know how to get the full Cortex register set out of GDB? It's giving me the ARM7 register set which excludes PRIMASK
what are you trying to see?
primask
The Current Program Status Register is showing the IRQ mask bit is set, but I'm not totally sure how to interpret that so I'm looking for a little more detail
Looks like "info all-registers" should do it.
I've tried that but like I said it's giving me the ARM7 register set
I found this thread but it doesn't have a good solution https://embdev.net/topic/159494
all registers just gives me f0-f7 and fps

๐ป