#circuitpython-dev
1 messages ยท Page 145 of 1
@solar whale, i have not tested SPI on the pca10056, some of the pins cannot be used because they are already used by the DK, but I think PB10-PB15 are fine to use
@uneven yarrow Here's the one that will end up in the bundle, but it's obviously not ready yet. https://github.com/adafruit/Adafruit_CircuitPython_Trellis I'm still trying to find the one in progress. I thought I had the link.
@indigo wedge FYI - I was able to get a 2.4" TFT- featherwing (ILI9431) and its sdcard working on the feather 52.
nice, did you use the rgb display lib?
@indigo wedge yes - it paint the screen pretty slowly! - otherwise I was just doing some slow bitmapfont so it was fine.
@uneven yarrow Ah here we go. Like I said, though, remember it's in progress. https://github.com/sommersoft/Adafruit_CircuitPython_Trellis
awesome thanks @idle owl ๐ Yep, I'll def keep in mind that it's a work in progress. it will be cool to see it take shape
thanks for the links!
You're welcome!
@indigo wedge I tried moving CS to PB13 - so using PB10-13 but still no luck - time to hook up the logic analyzer....
cool, let me know how it goes, i want to get SPI working on the DK ๐
sure - it'll take some time since I have to reoragnize my connections. tis is my first time tryin SPI on it as well. Nice to see it worked on the feather52 board.
yes, so we know the implementation in the port is fine, maybe just the board files are misconfigured
@uneven yarrow it is working. on a trinket, you'll definitely have to mpy-cross it. won't fit otherwise. still working out some bugs on the PR to include it in the bundle. but, that's all related to documentation/non-code parts.
It was nice to beable to put the RGB display library on the SDCad since the onboard FS is pretty small. only about 80K available.
@indigo wedge Is tahte any reson not to make the FS larger on the pca10056. It has lots more flash, correct?
yeah, I just made it match the feather one, but it could be way bigger i think, there is lots of flash available
@sommersoft#0222 That's what I thought, but I wasn't certain.
@uneven yarrow and please, let me know if it doesn't work. actually, scratch that....let me know ANY feedback you have (function names suck, it's overly complicated, etc)
Is it just changing the values in the .ld file?
yes, i believe so
OK - I'll give it a try.
@sommersoft#0222 Didn't want to hand it over with the wrong expectation so I erred on the side of beta ๐
hehe. it's all good. just cause it worked on my desk...doesn't mean its past beta. ๐
@indigo wedge I increased the FS to 0x40000 (256K) and it seems to be happy
That ought to be enough for anybody ๐
>>>
>>>
>>> import os
>>> os.statvfs('/')
(4096, 4096, 59, 58, 58, 0, 0, 0, 0, 255)
>>>
``` the Circuitpython Bundle will use that up fast!
@idle owl Shoudl the adafruit_sht31 library be added to the bundle at this time of do you want the docs all updated first?
@solar whale I think it can be added to the bundle. The plan is eventually to have documentation in everything first. But we're not quite there yet. So if you want to get it into the bundle now, that's fine.
How do we do that?
Make a PR to the bundle but I'm only half clear on how to do that.
Getting some more info though ๐
You have to update .gitmodules and something else. It's the something else I'm not sure about.
yah, basically just PR the bundle repo. see the bundle repo's readme. so fork it, do what it says there to add in the bundle, and then PR that back.
but then you also need to do a relase on the actual library repo (the one being added to the bundle) for the automated process to actually bring it in
A new release? Or is the current release valid.
that i don't know. haven't gone through it enough to know what sequences work / don't work.
but as an example for one i did. here's the PR:
I'm going to assume you need a new release.
and here the release:
So we'll do that once it's done.
@raven canopy yep. that's what you'll do locally after you fork it.
lol. now i can't remember...and i did it like a week ago. ๐
@idle owl @tidal kiln thanks - I'm glad I asked ๐ I'll look at the instructions and get a PR going - then we can see about the release. No rush on this - I was just curious.
@raven canopy thanks to you, too!
@solar whale No problem. Just let me know if you have questions, and we'll get it sorted. I'm around today.
I'm trying ot get my Salea hooked up now for another issue so I'm deep in that...
That also works ๐
if it doesn't work, travis will gripe, that's how i knew i forgot to do a release
and when travis isn't happy, nobody is happy.
lint is happy, cause then it's not the only one taking flack
@solar whale do you feel like the code is done and functional and ready to be brought in?
(wrt to the sht31 library)
It is. It needs RTD/Sphinx docs added, but it's set otherwise.
@tidal kiln yes - the basic function is OK - at this point I just need to work on the ReadTheDocs stuff
it's this repo?
https://github.com/adafruit/Adafruit_CircuitPython_SHT31D
Yes
@indigo wedge My first capture shows tath CS is alive but MISO,MOSI and SCK are all flat.... at least I have something to look for.
i'd say go ahead and add it to the bundle, that way it'll be wired in, you can continue to update the library and whenever you do a new release, that will trigger the updates to be added to the bundle
you won't need to do anymore PR'ing to the bundle repo
That was my thought as well.
@tidal kiln Thanks - I try creating a PR later - once I finshing breaking my current project ๐
doc updates, bug fixes, new features, etc... that's how to roll all them in (via a release)
I'm evidenty trying to write a state machine in CircuitPython.
I say evidently because that appears to be the solution to what I'm trying to do. But I'm entirely fuzzy on the concept.
what're you trying to do?
I have a CPX. it is currently sitting flat facing up. I want to be able to rotate it 90 degrees to the right, hold it there for 3 seconds and have that work as an input. Once. Then require returning it to flat state for at least 3 seconds before I can rotate it to signal the input again.
rotate it along X or Y axis?
X. Y stays ~0 when I rotate it. X and Z change
sounds like rotation around Y, but doesn't matter too much, problem is generally same for rotation around X or Y
no... not at all. But the rest of the code already exists. It's all light changes on a CPX using multiple inputs
I was going to try to get this working separately and then add it to the rest
the rest uses shake and double-tap to change brightness and color/animation respectively.
I'm using generators for the rainbow animation and the color sequence so other inputs can be done while maintaining the state
I think I'm going to take the on/off state away from shake and give it to the rotation input
or one of the rotation inputs
so, all in one code: various forms of input -> various light changes
yes.
is this for a guide?
gotta gist of it?
not yet no
(that was a selfish question. i need a break from reading circuitpython/py/*) ๐
what are you thinking in terms of the mission (can't think of better word) for the guide? like what are you trying to teach with it?
just show something fun with cp?
this is some of the best code I've ever written, definitely in my favorites.
It's meant to be "hey I've got a lamp sitting around not doing anything, what can I do with it with CircuitPython and this CPX?" I have another one that's going to have similar functionality, but use IR for the input instead.
asking because i think there are various ways of writing that code, state machine being one, and it could pretty much be an entire guide about those various approaches
It'll have the explanation for why we're sticking with motion for the little lamp: nothing else works. Touch fails, sound doesn't get through, copper tape doesn't stick to it to make touch work in some way, etc.
will it always evaluate to this: if Y == 0 and X > 0 or Z > 0: change light? obviously, zero would be padded to account for resting drift/resolution.
and yes, that eval statement won't work well enough...just idea vomit.
the 3 secs bit is the tricky part
As far as I understand things, I want a state machine. Create a global variable that represents the state I'm in, progress between the different states I'm looking for.
and binds stronger than or
so this is if (Y == 0 and X > 0) or Z > 0:
that's the even more tricky part
not sure it's what you mean
yeah, non-blocking will be what trips it up. @stuck elbow i was actually thinking more like Y == 0 and (X > 0 or Y > 0) but was too lazy to work through the binding. ๐
@sommersoft#0222 Here: https://gist.github.com/kattni/6cb5f9cc445272375f7016ccad26e404 That's the code as it is now.
Don't know why I can't tag you successfully today.
@idle owl this sounds like a really good project that is trying to do multiple things at once, and could serve as a good guide for how to go about doing that in CP
@tidal kiln Yeah and I've been asked about that before as well.
yay! new! ๐ and I don't know why your @vernal fern's aren't working either. we can blame my discord...usually the case.
@idle owl there's a great set of arduino guides that do a similar thing:
https://learn.adafruit.com/multi-tasking-the-arduino-part-1/overview
https://learn.adafruit.com/multi-tasking-the-arduino-part-2/overview
https://learn.adafruit.com/multi-tasking-the-arduino-part-3/overview
not all of that can translate to CP, for example interrupts
Right
but a guide that is essentially a CP version of those could be cool
Agreed
it seems to me that you should count time instead of time.sleep. same way its done in arduino with delay() avoidance.
which, is where you were talking about time.monotonic, right?
without interrupts, yes, it's going to come down to crafty use of time.monotonic
@solar whale i believe i found the problem (but not tested)
if you see here https://github.com/adafruit/circuitpython/blob/master/ports/nrf/common-hal/busio/SPI.c#L58 you'll notice the pins are assigned but not the ports, so you should add something similar to this https://github.com/adafruit/circuitpython/blob/master/ports/nrf/hal/hal_uart.c#L125 except using these defines: https://github.com/adafruit/circuitpython/blob/master/ports/nrf/device/nrf52/nrf52840_bitfields.h#L10635
circuitpython - CircuitPython - a Python implementation for teaching coding with microcontrollers
circuitpython - CircuitPython - a Python implementation for teaching coding with microcontrollers
totally started typing out example code...going to be too long. i'll put it as a comment on the gist.
this explains why it works on the feather52 cause that one has only one port so no need to set the port to 1, but you were using PBx so port 1
what was the lag time on time.monotonic() i vaguely remember a discussion about it at some point. may have been in the issues...
If it's anywhere, it's in issues. I'm not sure, I've never tested it personally.
@indigo wedge Thanks! I'll follow up on that!
@sommersoft#0222 Nice, thanks for the suggestion! We'd come to a basic version of that. Yours gets fancier. I'm working through getting more towards your point.
I am curious how you envision this working. As I understand it - and I may not:
- gmtime takes as its parameter the number of seconds since the epoch and returns a time.struct_time eith the current date and time.
- The epoch is commonly midnight Jan 01, 1970.
- As near as I can tell CircuitPython has no epoch.
- Circuit Python also has no time.time(). Though on the Metro, time.monotonic() returns what appears to be the number of seconds since the last power up of the board.
...
That is coincidental timing. I seriously just had nearly this conversation ^^
@indigo wedge Sorry - I'm not seeing exactly what I need to do. Isn't that being done here already? https://github.com/adafruit/circuitpython/blob/master/ports/nrf/hal/hal_spi.c#L60
@idle owl np for the suggestion. that technique opened a whole new world for me in Arduino. but, it can get quite daunting on large programs. so many intervals to keep track of! blocking is sooo much easier. ๐ and, for your purpose, using epoch time would be needless overhead imo...but it can be easier for a beginner to understand (kind of).
epoch time isn't built into CircuitPython. So monotonic is what we have.
yeah, i as referring to the reference (huh?) to the time.gmtime.
I'm currently reading an Arduino guide to try to get a better idea on how this works. It's mostly helping ๐ I'm totally new to Arduino. Will be fixing that starting this week, as it happens
Oh, ok... I didn't know what gmtime did. I thought time.time was epoch
@solar whale it looks like hal/hal_spi.c is used by the machine.SPI class and busio uses common-hal/busio/SPI.c, which is kinda strange, but it's the busio driver that the rgb display lib uses so you need to add the code to common-hal/busio/SPI.c
@indigo wedge 0k - thanks - I'll admit I do get lost trying to follow the various paths. I'll give it a shot.
Yeah, I'm new to this codebase so trying to wrap my head around it too
@tannewt You should be able to remove stable from displaying at all through the RTD UI. You should be able to activate/deactivate each build as needed. If you send me screenshots of the UI settings, I can see the config.
You can add warnings on the top of files by using rst_prolog. You may need to write a bit of code in conf.py to select a subset of source docs if desired. [IPython's conf.py](https://github.com/ipyth...
i know machine is more of a MP thing and now circuitpython uses busio, so does that mean machine is deprecated? Cause if it is then some of the hal/ code could be removed since it duplicates the common-hal code
@indigo wedge Hopefully @slender iron or @tulip sleet can comment on deprecating machine.
are they in Europe or in the US?
they are in US both coasts ๐
machine is not completely deprecated. well, it's only current use is on ESP8266
Ah, too bad discord doesn't show user's local time like slack
@raven canopy yes, so I'm not sure how it should be treated on the nrf52's
right now it's not available in the nrf port but i think there is functionality that only machine offers, even as simple as soft_reset(), I might be wrong though
that is the confusion for me - it is not compiled in as a module, but I'm not sure ifa any of the code is "in use"
Just an FYI for future docs, you may want to check out sphinx-gallery for examples: https://sphinx-gallery.github.io/index.html
I am going to have to put this off until tomorrow - @indigo wedge thanks for the guidance. It does not look like a fundamental problem.
current makefile shows machine being compiled... https://github.com/adafruit/circuitpython/blob/7c6adaa661aa066aca27457b966f5168189186c5/ports/nrf/Makefile#L163
yes, especially since it works on the feather, probably just some nrf52840 specific thing
@indigo wedge where are you located - I am in US - New Hampshire.
i apologize if i'm coming late to the convo and re-hashing....
@solar whale I'm in Sweden ๐
i'm about to jump off anyway too. not sure why i'm going to watch the super bowl...they can't both lose. ๐
@indigo wedge You'll be more likely to cross paths with Scott and Dan during the week then. All of us try to be around throughout the day so we can try to get to everyone.
@indigo wedge Nice! - I have several friends in Stockholm - at work we have been colaborating with folks at (KTH - Royal Institute) for many years.
@raven canopy you're right, it's defined as enabled in mpconfigport.h
i got confused cause @slender iron mentioned wanting to disable it
@raven canopy I'm about to do the same -- too close to Boston to sit it out ๐
definitely possible. it's mostly about how much they want to stay inline with upstream, i think.
It's midnight here so gonna sign off soon as well, but will lurk more from work tomorrow and then continue the conversation after work ๐
note - import machine does not work on nrf52
WAIT A SECOND!!! I'M PURPLE!! (and of course discord picks now to disable server emoticons...no blinka)
there she is!
@solar whale right! cause it's not added here https://github.com/adafruit/circuitpython/blob/7c6adaa661aa066aca27457b966f5168189186c5/ports/nrf/mpconfigport.h#L261
so I wasn't crazy ๐
@indigo wedge whew! me either -- good night/ eveing all
Later, all of you ๐
yes, enjoy your superb owls and all that
The owls are lovely. It's true!
@indigo wedge I think I just missed you
still here
I'd love to deprecate machine in circuitpython
its not well defined so I'd rather replace it with APIs defined in shared-bindings
i see, so if there are SPI classes in both machine and busio in the nrf port then the machine one could be removed?
yup
if we ever support stm then I think we'd leave machine like we have on esp8266
but since nrf52 isn't in upstream yet I think we could set precedence to not have it
nice, i could look into what is duplicated in machine and remove, that way we would also get a list of what APIs are missing in shared-bindings, if that's ok
@fogmansac Its meant as a simple conversion from standard Jan 01, 1970 epoch designation.
It came up in Discord chat because someone was fetching the time from a website that returned it as seconds from epoch.
@indigo wedge I don't think there is much missing. We have 60+ libraries already built on top of our own APIs. Its just a question of whether they are all enabled on the nrf52
there is an existing issue for soft_reset() https://github.com/adafruit/circuitpython/issues/184
(We call it reload so its not confused with pressing a reset button.
i see
i find it confusing that the ports seem to share some modules and some code but are still very much their own things with many inconsistencies between ports
like, it looks like most ports have their own main.c but the nrf uses the main.c in the root directory of the repo
This idea was pulled from a Twitter post about someone using an old Ikea lamp and a CPX to create a colorful lamp. That lamp was no longer available, so we've chosen 3 more to work with to see what we can do with them.
I have obtained the lamps, and am working on seeing how the CPX fits into them and what different ways I can interact with them. One is meant to try to use sound, light, motion and touch if possible to to different things. The other two are meant to use with IR.
@indigo wedge yup, shared main.c is the future
ah, so nrf is paving the way? ๐
in circuitpython anything besides esp, samd and nrf52 are basically ignored
and esp isn't on shared main yet
yeah, totally
the more we share, the better. but its a work in progress
i see
and yeah, i agree, the more is shared, the easier it is to make new ports also
consistency is ๐
yes I want to help but need to learn more about the whole project to see where I can help, also working on my own board with nrf so want to polish that one
awesome! I'm happy to coordinate a time to video chat too if you like
I try my best to disconnect on weekends though
i only can do this in my free time so weekends and afternoons ๐
I'm flexible so I can do weekends if thats what works
just gotta know ahead of time
not sure if i have enough material for a video chat but I'll keep posting here ๐
later @slender iron
<@&356864093652516868> Normal time for our meeting tomorrow (Monday). 11am Pacific / 2pm Eastern here on Discord.
bye @idle owl
The smaller lamp consists of a silicone mold (shaped like a little creature!), and a hollow hard plastic bit that fits inside containing the electronics. When the plastic bit is (easily) removed, the Circuit Playground Express fits exactly into a groove along the bottom of the silicone mold, and the USB cable fits through the charging port. Thanks, Ikea!
After experimentation, the first lamp is limited to motion as an input: tap, shake, and acceleration. I'll be documenting in the guide th...
basically a trinket or gemma with only dotstar LED + IR Receiver
@ladyada I looked at the new files and compared with Trinket and they look OK by me. Do you want a review and merge?
@tannewt ok by you?
hiya yes plz review and merge if acceptable for 2.3
LEEKS!!!
@raven canopy I think your rogue any reference is from here: https://github.com/sommersoft/Adafruit_CircuitPython_Trellis/blob/master/adafruit_trellis/trellis.py#L23
Are the shared commits required for your dev setup? You could use rebase to remove the shared commits if not. Waiting is ok too. I'll do the review Tuesday when I have time if @microbuilder doesn't get to it.
For pin naming I think PX_YY for microcontroller.pins always and for board on dev boards. For Feathers lets use the notation in the silkscreen + common uses like SDA/SCL and TX/RX. If the silkscreen says only a number then lets use the P0_XX notation. We'll likely have a feather for the 840 so it'll make sense with it.
Could we specify it by mount point? That's consistent with remount I
believe.
On Sat, Feb 3, 2018 at 2:16 PM Dan Halbert notifications@github.com wrote:
It would be nice to be able to erase and re-create a damaged filesystem
from the REPL or a program. Currently on non-Express boards we need to
erase all of flash and then reload CircuitPython. On Express boards we have
a special Arduino program that erases SPI flash, and then we need to reload
CPy.Something like storage.for...
@slender iron you were exactly correct. Now passing Travis after a few more hiccups. getting late, so I'll finish it up tomorrow.
g'nite. ๐ค
I do some changes in these commits to the pca10056 files that i added in the other PR so I think I'll wait, no hurry TBH ;)
Sounds good, if you don't mind then I can unify the pin names in the nRF port in a new PR.
Are there any cp examples of programming a trinket as a hid?
I am currious about "pIRKey"... Is there something this can do and that cannot be done with CPX?
I don't think so
well, ok, actually there is something cpx can't do and pirkey can
fit in your mouth
(or your computer's usb port)
Maybe a few exposed GPIO would have been fun. Here it is BlinkStick + Flirc.
Or more like "+ IRKey".
Actually seems to be a few mm smaller.
That would be the reset button and some things to go from 5V to 3V I guess...
For some reason the pdf version of the documentation says MP: https://media.readthedocs.org/pdf/circuitpython/latest/circuitpython.pdf
But I am ready to learn now ๐
ah, it's because the sphinx settings for latex are not updated
right, looks like this needs updating https://github.com/adafruit/circuitpython/blob/master/docs/templates/topindex.html
and further down
I don't think that template you linked is used
ah
A custom linker script would perhaps be better here, following the feather52 example, since we will need to use a modified version of the serial bootloader in addition to the J-Link. I guess we don't technically need the serial bootloader on the PCA10056 since it has an on board J-Link, but we can still test the serial bootloader as an option on this board until commercial modules are available with the final silicon.
Adding a ?= like this: SOFTDEV_VERSION ?= 2.0.1 will make it easier to override this from the command line.
Should this be larger? The linker script has _minimum_heap_size = 128K;, and there is plenty of free SRAM on this SoC for the heap.
How much do you recommend?
Not sure how to proceed, should I leave as is until a new bootloader is available?
The question I had was whether we can identify the mount point name if it's not mountable due to corruption. But I haven't looked at the code yet.
Don't worry about it ... I'll put the new linker script in myself when I generate the custom bootloader, since I'm not sure of the exact sizes right now anyway. I've only built it against s132.
@indigo wedge SPI is working on the PCA10056 - I can mount an SD Card!! I made teh following change .. ```diff --git a/ports/nrf/common-hal/busio/SPI.c b/ports/nrf/common-hal/busio/SPI.c
index efce356..a773774 100644
--- a/ports/nrf/common-hal/busio/SPI.c
+++ b/ports/nrf/common-hal/busio/SPI.c
@@ -55,9 +55,22 @@ void common_hal_busio_spi_construct(busio_spi_obj_t *self, const mcu_pin_obj_t *
// 1 for I2C, 0 for SPI
self->spi = NRF_SPI0;
+#if NRF51
self->spi->PSELSCK = clock->pin;
self->spi->PSELMOSI = mosi->pin;
self->spi->PSELMISO = miso->pin;
+#else
- self->spi->PSEL.SCK = clock->pin;
- self->spi->PSEL.MOSI = mosi->pin;
- self->spi->PSEL.MISO = miso->pin;
+#if NRF52840_XXAA
- self->spi->PSEL.SCK |= (clock->port << SPI_PSEL_SCK_PORT_Pos);
- self->spi->PSEL.MOSI |= (mosi->port << SPI_PSEL_MOSI_PORT_Pos);
- self->spi->PSEL.MISO |= (miso->port << SPI_PSEL_MISO_PORT_Pos);
+#endif
+#endif
}
bool common_hal_busio_spi_deinited(busio_spi_obj_t *self) {
~
Here is the whole file
While you are modifying the linker files, would it be worth making the File System larger for the PC!10056? I tried increasing it from 0x19000 to 0x40000 ( 100K -> 256K ) and it seems to be working fine.
@indigo wedge I think there is one error in my fix - either I should remove the if NRF51 block or add a similar one to the deinit section. I think it is neeed for the NRF52840 so I'll add it so the de-init works properly for the non NRF51 cases.
@indigo wedge simplified it - this work s on both the pca10056 and feather52 - let me know if you see any problems with it.
i think you can use PSELSCK and so on for both nrf51 and nrf52 because there is a compatibility file that will just replace PSELSCK with PSEL.SCK https://github.com/adafruit/circuitpython/blob/master/ports/nrf/device/nrf52/nrf51_to_nrf52.h#L92
yes - I finally saw that and that is how the second version works.
@indigo wedge I now have the tftdisplay and sdcard working on the pca10056 - -thanks for the guidance.
since you re making many mods, do you want to put in the ultimate fix for the SPI.c or do you want me to generate a PR for it?
I'm good either way, either you do one, don't think it has to be on top of my nrf52840 changes or i add it to my PR
I think it will be cleaner for you to just add it if it is not too much trouble.
cool, I'll do it in the afternoon
Thanks! Hopefully, I did it correctly in the second version I posted, but you may have a better way.
@meager fog I was playing with a TFT Featherwing https://learn.adafruit.com/adafruit-2-4-tft-touch-screen-featherwing?view=all#tft-control-pins attached to a fearher52 https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide?view=all but I noticed the warning not to use pin 31 since it is used for the battery monitor. Would it even work? It looks like the TFT_CS would be feeding into the VBAT. I used a different pin for the TFT_CS and it all worked fine, but I did not try using it in the default configuration. If the default configuration is to be avoided, perhaps a note should be added to the tff guide warning that the TFT_CS pin has to be moved. It says you "can" move it, but for the nrf52 is it a "must move it"?
@solar whale you dont have to move it, in fact for outputs, it doesnt matter at all
i've updated the text
Ok - good to know - thanks!
@meager fog I plugged the tft into the feather_nrf52 with defaut pinouts and it works just fine! Thanks for clarifying it.
BTW - this is all with Circuitpython 3.0 !
@solar whale CP on the nRF52 bluefruit :O!?
@tawny creek yes!
@solar whale is it easy to switch between firmwares?
Easy is a relative term ๐ see https://github.com/adafruit/circuitpython/tree/master/ports/nrf/boards/feather52 for details. It takes a bit of effort, but it works.
do you have the featherwing nrf52 ort the "pro" version?
the both work woth CP but the "pro" also has a J-link connector installed so that is an option.
I aslo added the J-Link connector to my "standard" nrf52 feather and it works well, but I have used the "dfu-flash" option as well.
hiya @kattni put the updates in the basecamp thread. thanks!
@tawny creek - I assume you are referring ot going back and forth between CP and arduino on the feather52. I'm not sure I have ever tried going back to arduino on mine but I don't think it is a problem as long as yo use the dfu-bootloader. If you use a J-Link, yo uhave to reload the bootloader to go back - but that is easy to do. - I think @raven canopy and @idle owl have put CP on the feather52 as well. Perhaps they can also commment on the "ease" of switching
Ah good point! We could hard code it but that'd be a bit weird.
Have any other ideas? We could fake /dev/disk/* but thats probably overkill.
On Mon, Feb 5, 2018 at 5:03 AM Dan Halbert notifications@github.com wrote:
The question I had was whether we can identify the mount point name if
it's not mountable due to corruption. But I haven't looked at the code yet.โ
You are receiving this because you commented.Reply to this email directly, view it on GitHub
<https://github...
Testing this on the actual HW, and OUCH ... the core firmware file is HUGE!
Running make V=1 board=pca10056 SD=s140 I get:
LINK build-pca10056-s140/firmware.elf
text data bss dec hex filename
185192 1188 239732 426112 68080 build-pca10056-s140/firmware.elf
arm-none-eabi-objcopy -O binary build-pca10056-s140/firmware.elf build-pca10056-s140/firmware.bin
arm-none-eabi-objcopy -O ihex build-pca10056-s140/firmware.elf build-pca10056-s140/firmware.hex
``...
The --format=SysV option of GNU size gives a more useful breakdown:
$ arm-none-eabi-size --format=SysV build-pca10056-s140/firmware.elf
build-pca10056-s140/firmware.elf :
section size addr
.isr_vector 248 151552
.text 184952 155648
.data 1188 536887296
.bss 67700 536888484
.heap 131072 536956184
.stack 40960 537087256
.ARM.attributes 57 0
.comme...
For the nrf52840 the .ld files have the _minimum_heap_size set to 128K while the feather52 has this set to 0. That is adding a big area to the .bss.
I won't be on the call.. didn't do anything with CP this past week. It's all be CircutiPlayground biscuits & fighting with A/V equipment & software.
hi folks - we're running a little late and will be in the chat shortly
the gang is all here ๐
teacher is late....
5 minutes. that means it's a walk, right?
having important private convo ๐
can it stop and resume after? we're all ready to go
last few sentences
<@&356864093652516868> meeting is starting!
Hug Report: Group hug to everyone, and going to echo @indigo wedge for the NRF stuff. Looks really cool!
(Also, maybe Arturo should get put in with CircuitPython Helpers?)
oh gosh, thank you
@indigo wedge You've been rocking it!
ah bummer yeah it's still not working ๐ฆ
Just a group hug. And Travis... he's picky, but makes my code better.
also, I'm sickafoos today ๐ฆ
I'm not sure what those are, I'm new here ๐
Ah I see, big thanks to @solar whale for testing the nRF52840 stuff and for @slender iron for being so cool to a oblivious newcomer ๐
scanning does writes, not all devices support writes
(but even more devices don't support reads)
yeah totally, it's either that or something else.. i still can't get it to ack a simple read too, but i need to mess with using its reset line before saying for sure it's having problems
Status: Haven't been working on CP stuff. My 3D printer is currently exploded, so that's my project at the moment as I'm upgrading to a dual extruder setup.
Exploded as in disassembled
heyyy im here! was in a meating ๐
@timber mango Hey, welcome!
i gots heckin' LEEKS
Leeks!
ROCK IT DAN!
Since I'm new to CP I want to look more into the code, I printed the docs so I can go through them and see the modules that you offer then I want to see which ones are implemented and which are missing in the nRF port and see what I can do to help there. Can also see which functionality is duplicated by the machine module and could remove that code to keep the code cleaner.
UART is the worst
yeah but python uart is >>> arduino uart
software serial is ๐ฆ ๐ฆ ๐ฆ
i know because i wrote the software serial lib like in 2007
it's one of those things everybody should write once, just to feel the pain, and then switch to a better library
to better appreciate it
In reference to CP and strings: Circuit Python handles strings. Arduino... you have to smash it into submission to do anything with strings.
well, it has String, if you don't care about memory
no more BUFSIZ. down with BUFSIZ!
STMPE hasnt been done yet and im just lazy ๐
if you wanna do it!
please do
i did the FocalTouch (captouch) version
i have hints on how to do STMPE
will dooo!
(thumbsup) STMPE has some 'unusual' SPI needs
yes!
sorry no mic
I tested out my pIRKey prototypes
they work great! i submitted a PR for support
(shrug)
๐
"perky"
porky
purrkey
its a generaly purpose Infrared -> HID USB plugin
we used to sell it! but it was very hard to use
"peerkey" ?
or apparently pronounce it "shrug" ๐
its great for multimedia installs and accessability
that is in 2.2.2
ALSO today we're fabbing the itsybitsy m0 express!
pyre key
IR is nice
right now actually, cachunk!
great silkscreen by philb - look for that in the shop by wednesday
super hot 340 *C
I say we should call the pIRKey a "Purr-key" and put it in a cat-shaped case.
im also thinking about how to do FONA library support
but will wait for UART in M4 because its very annoying
and needs a lot of RAM for debugging
however, FONA can do data so you could use it for internet as well as cellular/SMS
nothin' else ๐
I've definitely kept my eye on FONA since building a smartphone would be a cool project.
yes! we are making 250
ahhhh, ballard noises.....
Yay stickers!
Trellis is ready for bundle; PR coming tonight. Started on USB/REPL connection status issue. USB has a plan. REPL is being particularly obstinate...
I've been on twice! just need to be home at 7:30 now
@opal elk Ping me when you're ready for a review on the LIS3DH stuff, or if you would like someone to look at it sooner.
that code is on the Tester
@idle owl will do!
yah i have a zip of it on the learn guide
if its out of date let me know!
tony, do you mean -> 3.0?
honestly I'm stuck on connecting to serial via my rpi. I know there's boot stuff I have to change, and I swear I did it all, but I should just bring it up to my laptop and use putty
.cp2 .cp3
Add a driver for the resistive touch screen stmpe610. You can assign this to me.
yah we definitely know the Weird chips
clock stretch chips, repeated-start chips
the TFT featherwing tests a lot i use that for testing a wide range of 'types' of interfaces
tony, please make an issue for the drivers to check
we'll test against the guides ๐
@opal elk try adding enable_uart=1 to config.txt
hi! yep this is a good idea :) i did 'FT62xx' called "FocalTouch"
there's two interfaces i2c and spi but we tend to use SPI
and SPI is wierd on the STMPE is the 'polarity' depends on startup conditions. so you might end up in MODE1
https://github.com/adafruit/Adafruit_STMPE610/blob/master/Adafruit_STMPE610.cpp#L104
@tidal kiln I've tried that, but I will again
we should have adafruit_io library
i know someone had a umqtt success report on the micropython forum
lemme find it
oh nvmd, they never used umqtt in the end
its a good idea!
Yeah. Old school file method. I was thinking that...
Later @stuck elbow, have a good one
we have a page
(shrug)
๐
thats where i put "what you can expect"
e.g. what works, what does not
yah but kattni and i are oging to mirror it over
its ON THE GREAT CIRPY LEARN GUIDE UNIFICATION OF 2018
YES
YES!!
@idle owl do you want to open an issue on github - to get this page filled out
@timber mango sure!
add IRQ, other common Qs
Where is that Running Man gif when you need it? "YES!!!"
@jerryneedell Yeah, the heap and memory is managed differently, I noticed that after the fact.
@arturo182 If you want to push the minor changes suggested earlier, I'll merge this in, and will work on getting bootloader support in a new PR since that will require some changes on my end? Basic REPL works fine, and we can make improvements from there to make sure internal file system support is stable, etc.
IRQ vs GC is funnnn
@microbuilder I pushed the changes in the commit just before your comment.
thanks everyone!
Thank you everyone!
Thanks Folks. Go Forth and
!!
@idle owl we may want to merge w https://learn.adafruit.com/adafruit-gemma-m0/circuitpython-built-ins
Thanks, this was really cool! I was one of the people interested in IRQs, so it's good to see this was mentioned and what the solution is (pulseio), need to do some reading ๐
@timber mango yah I could see that
Expand the CircuitPython Expectations page to include more FAQs. If there are other things you are finding people constantly asking, please comment on this issue! Thanks!
Potentially combine with CircuitPython Built-Ins page.
Needed additions:
- [ ] Lack of interrupts (IRQs)
Phone dieing... I'm out. Later taters.
bye @raven canopy !
bya all - thanks!
people ask about WINC1500 + Feather M0 support - it wont fit into M0 flash :/
This is an issue to track what drivers have been validated for the 3.0 release. In discussion on 1/5/18 we decided this is an important release criteria to gate a 3.0 release--validating popular drivers that exercise many code paths. In particular with 3.0 we have some big changes to memory management and numeric representation/range so validation of drivers that deal with those issues is a priority.
A few to consider:
- Basic I2C usage: Any simple BME/BMP pressure sensor.
- Basic SPI ...
- Multiple SPI devices: TFT FeatherWing (my go-to demo is drawing a bitmap from disk to TFT but a 'touch paint' demo does STMPE + TFT)
- Clock-stretch I2C: BNO055
- framebuf: OLED
- Bi-directional UART: GPS with changing settings via NMEA sentences
FWIW - I downloaded #573 and made build for the feather52 and PCA10056 - both appear to be functional. Tested SPI on both builds (mounted SD Card). quick I2C test on PCA10056 (MCP9808 temperature sensor OK) - executed ble_scan.py example on PC10056.
Here are the build stats for the PCA10056 - removing heap helped!
$ arm-none-eabi-size --format=SysV build-pca10056-s140/firmware.elf
build-pca10056-s140/firmware.elf :
section size addr
.isr_vector 248 ...
with that irDaKey I got idea for some project
Hey I got a quick question for you circuit pythoners. How come if I do a while True for a button.value the program loops like its supposed to but if I change it to while false my program does not loop?
if button.value:
print("Button pressed")
time.sleep(.5)
else:
print("Butto not pressed")
time.sleep(.5)```
Shouldnt that work either way true or false keep looping??
I think you'd need python while True: if not button.value: print("not button")Or something like that.
MMmmmm I see let me try
yes thats strange I didnt know I would have to do it that way works great like that
Thanks
@heavy galleon while loops while it's argument is true, so True means forever and False means never.
So you negate what you're trying to make false within the loop instead of as the loop.
Ok makes sense, I have a pull up button so I had to reverse that logic somewhere. Kinda happy I had the problem so I know how to keep a while loop for a false statement
- can AVRs such as ATmega328 or ATmega2560 run CP?
- differences between "Express" and "Not Express" boards
check discord and hackchat logs for other common Qs :)
for M0, at least, we store numbers in 30 bits. that means there's a limit/range on both ints (0 to 0x7FFFFFF ) and floats https://github.com/adafruit/circuitpython/issues/572
(check me @dhalbert )
@idle owl @tidal kiln I "think" I created a PR to add the sht31 driver to the Bundle. Let me know if I did anything wrong. At least I got it by travis ๐
Looking for some guidance from other CP contributors. Once you have a PR merged, do you maintain your forked version of the repo or do you delete the fork? Is deleting the fork considered bad practice? I know github makes you take full responsibility for it ๐ It's a bit cumbersome to keep all the forks synchronized if you are not making frequent updates. Just curious how others deal with this.
Integers are 31 bits signed. Floats are 30 bits (the bottom two mantissa bits are dropped). It's a variable encoding: the lowest bit == 1 means integer; when == 0, the second lowest bit helps specifying the encoding. When two encoding bits are used, the 32-bit value is a 30-bit float or a 4-byte-aligned object pointer or a "qstr" (a static string pointer). See comment below from py/obj.h. There are multiple alternative encodings provided by MicroPython. For atmel-samd and esp8266, we use M...
@solar whale yep. it's there:
https://github.com/adafruit/Adafruit_CircuitPython_Bundle/pull/64
@solar whale don't delete the fork, but you can delete the branch you used for the bugfix/feature-add
I have one fork but many branches
most branches get deleted after they're merged into the main line.
@tulip sleet Thanks - Thats what I have been doing. So to sync your fork, you just periodically do a local pull then push back to github?
@solar whale merged
@tidal kiln thanks - do I have to do a new release?
@tulip sleet any issues with deleting the fork? i kind of just fork->mod->pr->delete
My fork has the remote named "origin" pointing to dhalbert/whatever_repo), and a remote named "adafruit" (canonical name is "upstream") pointing to adafruit/whatever_repo. I do git fetch adafruit; git checkout master; git merge adafruit/master to bring it up to date with upstream. Then I do git push to keep my GitHub fork repo up to date.
@tidal kiln - no issue, but no need either.
i'm lazy i guess. too lazy to make branch, have multiple remotes, do all the fetch syning, etc.
Scott and I use branches where you are using forks. You'll see in our PR's we might want to merge dhalbert:issue_123_fix_spi with adafruit:master.
@tidal kiln for tiny repos not an issue, for a big repo it takes a while to clone and re-setup.
@tulip sleet thanks - I've been following that guide. I'll keep doing that.
good point. yah, i'm mainly dealing with realatively small repos.
and i have created issue branches before, but most of the time it's just a pr from my fork's main.
This is pretty much our workflow, maybe with name changes: https://gist.github.com/Chaser324/ce0505fbed06b947d962
yah, like you said, i think i'm using fork like you use branch.
i've always wondered why github doesn't have a button for the "Keeping Fork Up To Date" stuff
Yeah, I wish they did too. I usually follow this guide: https://gist.github.com/CristinaSolana/1885435
@solar whale I use branches, and update when it makes sense. Sometimes it gets so flustered that I'll delete and reclone at that point.
@solar whale Keeping your clone up to date is pretty simple once you've done it a few times. It sets in as habit.
@idle owl thnaks -- yeah _ do a lot of clone syncing _ especially for repos I use, but dont usually contribute to. I also have gotten used to installing PRs to my clones in a new branch - that has been very useful.
Ok yeah. That's how I do it. All my PRs are branches. Then if the branch gets fuzzy you can delete that and you still have the simpler time updating master.
Thanks for all the comments. I just wanted to make sure I was "on the right track" Sounds like it....so far
@solar whale In the end, it's what works best for you. But if you're new to all of it, it's nice to have a place to start. My workflow closely follows the workflow of the people who taught me most. But it works for me so I've stuck with it. ๐
OK cool! just got my forked Bundle repo synced after my PR was merged ( accidentally did it from master, but it all worked out )
@solar whale my guess is you don't need to do a new release
@solar whale i've been struggling with getting the workflow down too. I mentioned to tannewt that a "here's the
workflow" document might help; especially since they've decided to go with the merge strategy vs rebase/squash (complete with flow chart, for the visual folks). branches are life savers on forks...i'm slowly learning. @tulip sleet, if that workflow you posted is the "defacto", I can start working on said document/visual aid.
@solar whale got my display working too :D https://media.giphy.com/media/xThta6tw5vyUlrKT28/giphy.gif
not the fastest thing ever ๐
wow
awesome work @jerryneedell - you did great!!! :)
for the return values, i think a dict with 'x' 'y' and 'pressure' might best
https://github.com/adafruit/Adafruit_CircuitPython_FocalTouch/blob/master/adafruit_focaltouch.py#L96
that way its somewhat compatible with focaltouch?
Thanks for the pointers. Iโm looking forward to getting this going.
Found it! We "cleaned" the stable copy and deactivated 1.x. Thanks for the tips @willingc!
Good evening all! I'm wondering if Ampy is still the thing to use to communicate with my Feather Huzzah, as far as making directories, moving files etc? Is there a newer version than 1.0.1?
I finally got the newest version of circuitpython installed on the Feather
@heady dove I checked mine and I'm running 1.0.3. As far as I know that's the way to communicate, yes. Great job getting CircuitPython installed!
Thank you, I wasn't able to get 1.0.1 talking, but I wasn't sure if I was banging my head against a wall
I need to access the "Adafruit bus device" lib, which is a folder, in which nothing is actually called "adafruit bus device", the calling program is using the folder name as the reference?
and that would be the same for any of the folders in the "lib" folder?
Not necessarily, a lot of them are named as they are imported.
But for some that have mutliple libs within, yes, that's how they're referenced, although if you write your code a certain way, you could call some of them directly.
I was able to move the files, but not create a directory, and the sample program didn't recognize the call
I haven't worked with ampy. Can you copy a directory that already exists? You could make a custom lib directory and copy that instead.
well thats what I was trying to do, but I couldn't get ampy to do it, and it didn't seem like I could make one with the webrepl
Hmm ok. I'm not sure, it was a guess
I'll keep working on it, at least I know I'm headed in the right direction. I'll get 1.0.3 also, just incase
You might get a better answer too from someone who knows, when they're around
will do, who's the guru of 8266?
There's a few, I know @solar whale is one. But I'm not sure when they're around.
A lot of people are really good about reading through for previous questions. So you may get a ping in the morning from someone running back through everything, etc.
@heady dove have you been using TonyD's guide for loading modules?
It was written for MicroPython, but ampy directions should be the same.
<@&356864093652516868> Here is the recording for this week's weekly! Let me know if you have questions/comments. https://youtu.be/WhmzkX9RwGI
Meeting notes + timecodes are available here: https://gist.github.com/tannewt/287d8a74b411b61043f2bfc1757bced8 Join here for the chat all week: http://adafru...
I am currently evaluating moving to CircuitPython from vanilla MicroPython. Slave I2c would be perfect for my needs too.
I wonder if it won't be a little confusing to have to use a library named gamepad for key matrices, maybe it would be better to keep the Gamepad class but rename the library and add the Keypad class in that library. Both classes are pretty close in functionality so they would reuse a lot of the code, like the key scanning and the timer tick stuff.
Thanks for putting up the recording of the meeting yesterday, @slender iron, gave me a chance to see what I missed before I joined in!
excellent @indigo wedge ! glad you appreciate it
this is cool, i got a couple sino:bits (naomi wu's microbit but for the chinese market) and am getting the micropython port to work on it.. basically just ripping out all the display related code since the sino:bit has a dedicated HT16 charlieplex controller vs. the micro:bit doing it with its GPIO
if you have a sino bit i'm finding they're pretty flakey to program over USB with just USB bus power... you really need to plug in a battery or power source to make sure it has enough juice or else it fails to flash about 75% of the time
no real harm since it has a dedicated USB firmware flashing chip--it seems pretty robust
Hey All!
I got bit of a noob question, but was thinking maybe its actually possible.
Is the there a way to send a Float or an Int from a CircuitPython board to the PC via USB without using the Serial Print?
To avoid the whole Char parsing and conversion procedure.
Maybe something like OSC that works over USB?
In other way, what would be the best way to send values from a sensor connected to a board running CircuitPython to another script running on my PC via USB?
Thanks!!
@nocturne sluice can't think of anything like that
@nocturne sluice serial is the easiest way
๐
you can use the struct module to pack the float into bytes and then unpack it, it's super-easy
yeh was worried that would be the case
is there a reference to to the struct module?
ah cool also found this: https://circuitpython.readthedocs.io/en/latest/shared-bindings/struct/__init__.html
awesome thanks!
@stuck elbow so after I pack it i send the bytes via the serial print then unpack on my pc? right?
precisely
awesome thank you very much!
good luck!
@heady dove did you get ampy to work for you? Here is how I copy the adafruit_bus_device folder from my host machine to an esp8266: $ ampy -p /dev/ttyUSB0 put ~/projects/Adafruit_Circuitpython_Bundle/2.x/lib/adafruit_bus_device lib/adafruit_bus_device
@heady dove if you need to create the lib filder on teh esp8266 then use" ampy -p <your_port> mkdir lib
I'm looking to replace a RPI project with CircuitPython. I'm looking at the Feather ESP8266 for the networking. I need to be able to send ASCII data via RS232 to a serial printer. What are my options for serial to RS232 (TTL to RS232?) ? Thanks in advance.
@cunning notch This is not encouraging - see notes at the end - the UART is used for the Circuitpython REPL. https://learn.adafruit.com/welcome-to-circuitpython/circuitpython-for-esp8266
yeah, esp8266 only has one uart, and it's already used for the repl
but I wonder if there are any spi or i2c chips that do rs232
@solar whale Yes, I saw that. I also see that the Tx and Rx, though connected to USB, are still available. I'm looking to convert basic serial to RS232 (voltages, etc.). Any options for using SPI or I2C for this?
I have half a dozen RPIs running in read only mode in an industrial production enviroment. They are working great but I would like to see if I can do the same application with a MicroPython device.
I own a Trinket M0, Feather M0 Express, and a Feather HUZZAH ESP8266. Plus an original PyBoard. ๐
looks like MAX3110E/MAX3111E could potentially work
the max ones already convert to rs232
Both good options. The MAX series already have the RS232 circuitry builtin. But the SCI may get job for another RS485 project I'm looking at this summer. Thanks! ๐
SparkFun has a similar breakout but appears to be discontinued.
I saw that.
As a CircuitPython shout out, I have a new project that I think the Trinket will do nicely. I need to send a series of millisecond pulses to select a vision system's current program. I think this is an excellent task for the smallest of the small. ๐
since it recently has pulseio included, that should work
I hope so too. Just kooked it up and updated CP.
Wow, AdaBot told on me. LOL ๐
no secrets here ๐
@timber lion I (and others) have found the sino:bit to be sensitive wrt USB. E.g. it will work on one hub and not another. In my experience, if I can talk to it, itโs been stable without the need for additional/alternative power.
@timber lion Also, awesome about micropython!
a776c2a nrf: Fix errorneous indent - arturo182
d0b451b nrf: Use the right SPI registers on nRF52840 - arturo182
616cbc6 nrf: Use more generic header - arturo182
fed9087 nrf: Add flash section for fatfs for no SD pca1... - arturo182
c6a542d nrf: Add SD 6.0.0-6.alpha to the download script - arturo182
The nRF52840/PCA10056 support merged in via #573 currently only works with nrfjprog and a J-Link. A new serial bootloader needs to be implemented similar to the s132-based feather52 platform, but based on S140.
As an interim solution, this should ideally work with the USB CDC interface on the PCA10056 development board until an internal board is available (pending commercial module availability and final release of the nRF52840 from Nordic).
Easier to use helper classes on top of the current low level BLE library are required for the following:
Peripheral Mode
Core Classes
- [ย ]ย GAP: Advertising
- [ย ] GATT: Characteristic Wrapper
- [ย ]ย GATT: Service Wrapper
- [ย ]ย GATT: Description Wrappers (CCCD, etc.)
Service Wrappers
- [ย ] Device Information Service
- [ย ] BLE UART (NUS)
- [ย ] Physical Web (formerly Eddystone)
Central Mode
TBD
Requirements
These helpers classes should require no pa...
USB support should be added for the following classes as a minimum:
- [ย ] USB CDC
- [ย ] USB Mass Storage
- [ย ] USB HID
A review is currently pending on the best solution for the USB stack, whether to use the Nordic provided stack or another open source alternative that can be used across platforms.
The DK can also be flashed with OpenOCD via ST-Link or CMSIS-DAP ;)
Are we talking about Python classes here? Are we following the bluepy (http://ianharvey.github.io/bluepy-doc/) API? I would like to help but need to decide on the API first.
Closing this issue with the merge of #573, but for follow up see #585, #586, and #587. Issues with the port itself can be handled in a new thread, such as improving ampy support for stability, fixing support over the USB CDC interface if possible, etc.
In the future we could also look into adding HID and ANCS support, they are quite useful.
IS it still the case that AMPY will only work on the DK via the UART pins, and not via the USB port? This has been working OK for me, but on a few occasions it has resulted in a corrupted FS on the DK. Has anyone else seen this?
I posted this to the previous PR but here are the details:
lib
boot_out.txt
ubluepy_scan.py
jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ ampy -d 1.5 -p /dev/ttyUSB0 put i2c_scan.py
Traceback (most recent call last):
File "/usr/local/b...
Traditionally the UART peripheral on the nRF5x chips has generally required HW flow control for reliable communications, which might be what's happening here. I have to do some further testing myself, and I don't know if the peripheral on the nRF52840 is more robust than previous UART blocks at the silicon level, but I've generally always had problems with them without CTS and RTS being used. Or it could simply be an issue with the USB stack and pass through running through the on board d...
I have been using UART on the nRF family without HW flow control for a long time and never had any problems. I believe the issue here is that the UART is passed through the JLink chip which seems to corrupt the data coming into the nRF.
@microbuilder Thanks - I do have an "FTDI Friend" that support HW Flow control. I will try connecting that instead of the cable I am using now that only has TX/RX and see if that makes any difference.
I have been using a external USB to UART board with only RX/TX and had no problems with ampy.
Yeah, the goal is ideally something sitting on top of bluepy (for portability reasons), and I'm talking about Python helper classes, I'll clarify that in the subject line.
The current bluepy API assumes a reasonable amount of knowledge at the packet level and about BLE, and helper classes can make working with things like indicate/notify and advertising properly much less error prone for end users.
dmesg on my laptop is telling me "Volume was not properly unmounted." Do I need to run fsck on the Trinket M0?
I can access the REPL, drive, and it runs my code fine.
@cunning notch UNless it is giving you trouble, you should be able to ignore this.
@solar whale Does reflashing create a clean partition?
@cunning notch no - you have to use one of the "erase" tools - looking for the link
@arturo182 We already have helpers for a lot of useful services like ANCS for Arduino ... the goal is of course migrating similar helpers over to Python, though the API will obviously be different on a different platform and language: https://github.com/adafruit/Adafruit_nRF52_Arduino/tree/master/libraries/Bluefruit52Lib/src
If we want to only support s132 and s140, does that mean we drop support for s110, s120 and s130? I see there are many defines for those SDs in the ble driver and I'm not sure how well those have been tested, does CP even run on those 16K/32K RAM nRF51 devices? Maybe we should remove the board and linker files for the nRF51 family and only support nRF52.
And another question, is the pca10040 supported? Because I couldn't build it, was missing a board.c file, how did you test the ble code w...
@solar whale Oh yeah, the erase image. Thanks
@cunning notch I often see the "not properly unmounted" setting since after flashing, it dses a reboot and does not "gracefully" unmount.
Does it hurt to fsck anyway?
I think we should also have an issue for more advanced BLE features like security, bonding (and we need somewhere to keep the IRK), advertising whitelists, and connection interval management (important for power efficiency).
@arturo182 good to know. I'll keep track of the issues I have with ampy and see if I can find a reproducible issue.
@cunning notch I have not tried it.
Personally, S132 and S140 are the only targets that I think have a lot of value moving forward. The older devices are too small to be useful. As part of the next PR, I was actually planning on removing a lot of boards, and focus on the micro:bit, feather52 and PCA10056 boards exclusively, or anything similar enough to those to easily maintain without stretching ourselves too thin. The combination of S132/S140 and nRF52832 (32+512KB) or nRF52840 are all that really make sense to me.
@solar whale 'sudo fsck.fat -a /dev/sdd1' Removed dirty bit. No more errors.
Logical size was not decreased so there were potentially no orphaned chains. Makes sense considering there isn't much on it yet anyway. ๐
That sounds good, If we remove the older SDs from the ble driver i think it will become way cleaner and since s132 and s140 SDK is fairly similar, there won't be that many ifdefs.
I think it's worth leaving the pca10040 in, but remove all the nRF51 boards.
Let me know how I can help, don't want to step on your toes.
@indigo wedge just curious - how are you powering your PCA10056 DK board when you use the UART cable - I am still powering via the USB conenctor - so only have TX/RX/GND connected from the cable.
I think we should rename the pins to PX_YY instead of PAYY and PBYY, so we can match the naming used by Nordic and the silkscreen on the DKs, this issue was also discussed in https://github.com/adafruit/circuitpython/pull/575#issuecomment-362990100
If it's no problem, I can be assigned to this issue.
@arturo182 They redid the entire UART block migrating from the nRF51 (which didn't work reliably without flow control and had a tiny internal FIFO) to the nRF52, which improved things, but we had to fix issues in this fork to get paste mode working 100% reliably, for example. It's a combination of firmware and proper use of the HW, but I've been bitten enough by the UART blocks I don't trust them. :P The problem here is almost certainly the chip with the J-Link firmware, though, but the more...
@solar whale yep, exactly as you describe
good - just wanted to make sure the setup was similar.
I'm OK with this personally.
I'm seeing my CPX as a drive on windows but it isn't in device manager as having a COM port
@opal elk Is teh CPX running CircuitPython or the "pre-installed MakeCode Demo?
Does the Makcode demo show up as a serial port - never looked.
well something happened and my board was wiped (not going to bother diagnosing it; I had it hooked up to a pi for a while doing i += 1 so I probably did something naughty)
it has my main.py now
@opal elk Dont' worry, It'll probalby happen again - at the most inopportune time - you can diagnose it then... ๐
Good afternoon all, in one of the 'learn" columns it says " Remember if you're using a board that doesn't support hardware I2C (like the ESP8266) you need to use the bitbangio module instead:" but the Feather Huzzah has SDA and SCL pins, do I need to use bitbango or busio? I'm talking to a BNO055
@heady dove as part of the feather form factor, i2c pins are provided in the same location, how that is done varies from board to board depending on what the chip is, so it may end up being either HW or SW i2c
cool, thanks guess I'll use bitbangio
the feather huzzah is just the esp8266 broken out in the feather form factor, so whatever you're reading w.r.t. to an esp8266 should apply
what learn guide are you reading? (just to make sure it's not saying anything confusing)
yeah ESP dos not hvae hardware i2c
you have to bitbang it, just use pins 4 and 5
it works fine tho ๐
Awesome, again Thank you ALL, I love this community and I LOVE Adafruit
@heady dove yep, what it says, the second recipe:
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/circuitpython-code#usage
although i see another bug in those examples...is itadafruit_bno055.BNO055 or adafruit_bno055.Adafruit_BNO055 ??
the former:
https://github.com/adafruit/Adafruit_CircuitPython_BNO055/blob/master/adafruit_bno055.py#L88
@heady dove so that should be:
import board
import bitbangio
import adafruit_bno055
i2c = bitbangio.I2C(board.SCL, board.SDA)
sensor = adafruit_bno055.BNO055(i2c)
Again, thank you all .... lets see if this works ๐
@slender iron can I request a review from someone when I create a PR or is it only people with special access like you that can do it?
@indigo wedge I think you can. microbuilder will be doing most of yours
ah it seems I can not https://help.github.com/articles/requesting-a-pull-request-review/
Note: Pull request authors can't request reviews unless they are either a repository owner or collaborator with write access to the repository.
@arturo182 Do you have a feather52 on hand, just to do some testing against on the nRF52832 as well? I'm happy to send you a pair of them, just send me an email at kevin AT adafruit.com and I'll send you the details on how to go about with the order.
ah ok
I only have Nordic DKs for nRF51 and nRF52832 and nRF52840, so no feather, I'd be happy to test the code on both before I push :) I'll send you an email then!
So I got this error, when I ran the test code "Traceback (most recent call last):
File "main.py", line 5, in <module>
File "adafruit_bno055.py", line 125, in init
RuntimeError: bad chip id (0 != a0)
@heady dove how do you have the BNO wired in to the feather?
@heady dove Just incase you stumble across this like I did... on the esp8266 I2C is "bitbanged" but the "busio" module actually uses the bitbang interface, so you can uses either "import busio" ot "import bitbangio" This had me very confused for ahwile....
Vin to 3V, gnd to gnd SLA to SLA SCL to SCL via 4 conductor Canare quad star
@solar whale yeah, I changed how that worked with 2.x I think
@solar whale I'm importing bitbangio
so busio does either HW or SW?
on esp8266 yes
if there is no hardware support then it'll bitbang
on samd21 it'll be picky about the pins, it won't silently bitbang
interesting
so no longer a need for two different setups? like guide is showing now?
@heady dove is the cable soldered directly, or are you using it as a jumper with a breadboard? can you post photo?
it's on a breadboard, not sure how i would post a pic
though I guess discord is on my phone, can I log in from two devices?
@heady dove - yes you can
@heady dove google says that cable is essentialy 21 AWG solid core. correct?
looks like you soldered on some header pins to get it in the breadboard
I did
what's the total length of cable?
from your arm to your back ... about a meter
wrist actually
atempting to get positional data off a dancer into a Max for Live rig
I had it working via the arduino IDE but wanted to try it in circuitpython
same cable?
yes
same board? just using arduino instead of CP?
exactly yes
hmmmm
it has been in one of my carry cases, I suppose it could have been damaged
try again with arduino, see if you can repeat success
ok. try that and report back.
will do, again thanks for the help, I love this community
It sounds like the bluepy API will work to build the higher level helpers on top of. The current ubluepy is slightly different from the proper bluepy API and it'd be great to redo ours to be an exact subset (or identical). The biggest difference I know of is that ubluepy doesn't use properties. That's a MicroPython design decision that we don't follow. (We pick consistency over memory optimization.)
Here is an example of a difference: [bluepy](https://ianharvey.github.io/bluepy-doc/s...
I'd love to be involved in the USB stack discussion. We're not very wedded to ASF4 at all for SAMD21 and SAMD51.
So, after a few more days crawling around the core, I think checking for a live REPL connection isn't currently possible. One exception to that is WebREPL; that would be doable by checking for the file stats. Of course I caveat all of this with "I am very possibly wrong", but here is how I've come to that conclusion.
- Starting at
circuitpython/main.c:L#119, the boot code checksserial_connected(), and if it is, it prints out the startup info to the REPL. (there is at least one othe...
I'm a little confused about the module naming, in the docs it says "No module aliasing. (uos and utime are not available as os and time respectively.) Instead os, time, and random are CPython compatible." but then the ble module is called "ubluepy" not "bluepy".
@indigo wedge it hasn't been fixed ๐
to the PR cave!
we inherit a bunch of u* from micropython and have only fixed so many of them
if I could wave a magic wand they'd all be fixed ๐
ok, i'll keep that in mind when going through the code
@indigo wedge i think you can check off some of these line items now: https://github.com/adafruit/circuitpython/issues/526
thank you!
not quite, the gamepad is on review and struct will be next, i just gotta test some github stuff on a dummy repo to understand PRs better cause I'm still unsure about dependencies in PRs
also it seems i don't have rights to check off anything if you meant me doing it ๐
hrm, I thought you would
added you as a collab @indigo wedge so you should be able to now
yep, so many new options
and push access, that's scary, need to make sure i push to the right remote ๐
this is all happening so fast ๐
I'd love to be able to get @hathach to spend a bit of time updating https://github.com/hathach/tinyusb since we'd have full control over the design decisions there, and it was designed from the start to be vendor neutral (which clearly isn't the case with most other stacks out there). Other options may make more sense after some digging, of course, but I think tinyusb is a strong option with a permissive license.
Use serial_connected to determine whether serial is connected. Rename isREPLconnected to isSerialConnected in your brain. Many folks confuse REPL with serial.
I think USB enumeration status would be a bit more difficult actually. I don't believe we track it at this point.
@microbuilder I'm on board with that. Do we expect much difference in timeline to get USB on nrf52840 going between the two options?
@raven canopy looking at your trellis PR now
It seems some of the examples in the nrf port are not valid anymore, for example the seeed tft one uses framebuf and machine, neither of those modules is available in the port.
Shouldn't the examples be better structured, the ones in the root directory should work on "all" supported ports, the ones inside the port directory should work on all boards that port supports and examples inside a board directory should be board specific and only work on that one (for example if some boards have b...
Yes! Examples in the repo aren't critical because we have detailed tutorials and how-tos on https://learn.adafruit.com.
As mentioned in #586, let discuss what to do about the nRF51 boards, at the moment they don't build because they lack board.c files (a requirement added in 60a23f0fb65bebe91ab8b6da4a32ed0b012e9313), we could either fix them and keep them, although I'm not sure how well they work and if the ubluepy module even works on them, or we could remove them.
That would mean removing pca10000, pca10001, pca10028, pca10031 and wt51822_s4at. The last one would be somewhat of a shame because it was...
Oh no, I just noticed the microbit uses a nRF51 chip, and it was mentioned that we want to keep support for that one, so this whole issue might not be so useful. I guess we can still discuss removing the other DKs, but the driver ifdefs might have to stay. Either that or we separate the driver into two files, one for nRF51 SDs and one for nRF52 SDs.
the nRF MCUs don't have analog out but the analogio doesn't allow disabling just the AnalogOut class so right now we have empty dummy functions, what's the best exception to throw if anyone tries to create a AnalogOut instance? NotImplementedError seems closest but not quite right
@indigo wedge I have in another lib, that had things that weren't compatible with the current version of CPy, RuntimeError.
micro:bit is the problem at the moment, yes. It's a popular platform and worth continuing to test against. I think that situation will likely change at some point in the future, but perhaps the suggestion of two interim radio files is the right one to at least keep the more similar nRF52 code clean and easy to update?
Not sure it's the same thing though. https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground/blob/4df91b8ddf05bc5918ec9b1282b50cae4055e6af/adafruit_circuitplayground/express.py#L211
I'll have to ping Thach for an estimate here since he's the one who will be doing the brunt of the USB work, since he knows it best.
exception RuntimeError
Raised when an error is detected that doesnโt fall in any of the other categories.
That sounds about right. Thanks @idle owl
@indigo wedge Sure thing!
Sounds good to me, and what about the other DKs and the wt51822 board?
@indigo wedge @idle owl we can #ifdef out AnalogOut as necessary. We just need to add another #ifdef like the ones in mpconfig.h and mpconfigport.h and ...board.h.
That's handy.
https://docs.python.org/3/library/exceptions.html#NotImplementedError: Note It should not be used to indicate that an operator or method is not meant to be supported at all โ in that case either leave the operator / method undefined or, if a subclass, set it to None.
yeah i thought of that but it felt like a larger system decision that I'm not ready to take on just yet ๐
you'll get there -- those #define's are not sacred!
yeah but don't want to break all ports on my way ๐
ifdefing out the AnalogOut would be perfect cause that functionality is not available on the nrf platform so no class should be accessible
Break and fix, that's how this has worked all along. ๐
make an issue to remove it at some point if you don't want to do it now
can do!
a exception in the constructor works quite well too cause then you can't create an instance
The nRF MCUs do not support analog output. Throwing an exception
in the constructor will stop users from creating an instance of
the AnalogOut class.
In the future we can ifdef-out the whole class so it is not available
in the module at all.
Some MCUs, like the nRF do not support analog output so it would be best to not have the AnalogOut class available on that port, right now it is no possible and the constructor just throws an exception, which will at least inform the user that they are trying to perform a unsupported operation.
The key boards in my mind that we should be testing against and considered 'supported' are:
nRF52
- [ย ] feather52
- [ย ] pca10056
nRF51
- [ย ] microbit
With the goal of dropping nRF51 support entirely once micro:bit comes out with an nRF52 option (?), and people can always go back to previous releases for legacy support?
Those are just my personal opinions, though, since I think the nRF52832 is a far more flexible chip for a project like this. Obviously I'm interested t...
is Kevin/microbuilder available in this channel?
@indigo wedge No
Ok, thanks ๐
@timber lion @slender iron Just tried rfm69 and aio (using urequests) on CP3.0 with much better results. basic test is working. gc.mem_free shows >15K bytes before urequests call now - looks like it was just marginal with 2.x.
If I understand correctly the audiobusio module offers a interface for I2S which the nRF52 family has so that module could also be implemented in the nRF port! :)
oh that's excellent @solar whale!
@timber lion I do have the response stuff stripped out of urequests. I can see if it makes any difference to put it back, but glad to see it working.
also good validation that SPI is working well enough to talk to to it too
yeah i bet the response is ok now, it's good about lazy loading the data i saw
so only if you read it will it start buffering
hmm - putting it back fropped memory to <15K and it reset on the first try!!
oh wow haha
maybe it's not as smart as i thought
i saw it seemed to only start reading if you parsed the results
but yeah if you don't need the response then maybe best to keep it out
at least for now - One step at at time!
what's the deal with bitbangio, is it deprecated or not yet implemented? because i see it's used in the esp port but that one is not built on travis, so is it officially supported? it's not used in the samd port. I'm trying to get it working on the nrf port and I can't get it to compile cause dest used here https://github.com/adafruit/circuitpython/blob/master/shared-module/bitbangio/SPI.c#L143 is not defined anywhere. i could try building esp to see if it even builds there but iirc esp need a special compiler and i don't want to spend time on setting that up ๐
@indigo wedge It is used on the esp8266 port, but I ahve also stested it on the SAMD boards so I know it works.
hmm, I'll have to look more into it then
there was just s recent PR fixing some issues with the SPI
i guess the problem is none of the boards in CI use that module so if it gets broken no one would notice until they try to build themselves
see like this dest variable, it doesn't seem to come from anywhere https://github.com/adafruit/circuitpython/pull/564/files#diff-4c50a0fe8b1265e4ac799b34e0047542R268
ah - just saw the note about it not being compiled in master - I was testing it on 2.x
I think you'll need @slender iron or @tulip sleet to clarify the status
I'm back from climbing!
@indigo wedge We need to reenable it in atmel-samd on master
esp8266 isn't in the CI because of the toolchain stuff
we should get it there sometime ๐
I'm trying to build samd now to verify, i don't have a board to test but can at least see if it builds
that dest is in an #ifdef that I think is false
we disabled a bunch of modules with the switch to asf4 so its possible its disabled
it may still need some implementation in asf4 before it works
ok it builds for whatever the default target in samd is
hmm
the search for the dest continues
i might be wrong but bitbangio should be port-agnostic since it probably just toggles GPIOs
I prefer throwing an exception instead of removing it. I only want to remove things at the module level, not the class level. We have a chart for module support here: https://circuitpython.readthedocs.io/en/latest/shared-bindings/index.html#support-matrix
I understand this costs a bit of code size but would prefer a specific error message over a name not found exception. The ESP port raises an OSError: https://github.com/adafruit/circuitpython/blob/master/ports/esp8266/common-hal/analogio/...
Ok, I see, I will update my PR to make it consistent with the ESP port.
@indigo wedge I think there is a mp_raise_OSError to use now isntead of the nlr_push directly
I believe so, yes
anything else I can help with before I go heads down?
I think I'm good for now, will post if I come up with any more questions, thanks ๐
kk, great work @indigo wedge
@indigo wedge The code in the #ifdef MICROPY_PY_MACHINE_SPI_MIN_DELAY is derived from extmod/machine_spi.c, which we don't use. That old code had a dest. So it's a latent bug which is not in compiled code right now.
oooh
and in the nrf port it's defined as 0
in samd it's not defined
๐คฆ
I'll try removing and then building, thanks Dan
@indigo wedge what are your thoughts on the bluepy API?
does it cover most of what you think we'll need?
I haven't used it that much and I tried reading the docs now and I can see that we try to follow it but I think we also implement more
cause nowhere in the docs there's a mention on how to advertise
but we have a basic advertisement API
I think it's a good starting point but might not be enough
kk
its open source so we could expand it
it'd be weird if we were a superset though...
we kinda already are, with that advertising function
we have it, bluepy doesn't seem to
yeah, we're not calling ourselves exactly bluepy yet
looks like pybluez is the alternative
650 stars on github vs 600 for bluepy
"experimental ble support"
i think i prefer the bluepy API more
the problem is there is no one de facto python ble API
right
and none of them are complete
yeah but bluez is not so much fun to work with ๐
top result for "bluetooth python" on google is tony's guide: https://learn.adafruit.com/bluefruit-le-python-library/overview
stupid google
maybe we just come up with a new name
right, to not claim compatibility
cause it's really hard to say how many people will come from RPi expecting their code to work
and then if we want to port it to CPython we for bluepy and rename
I'm more interested in the opposite, allowing people to grow into rpi code
right, CP as a starting point
yup yup
then yeah, someone would have to port whatever we do to RPi/Linux
yeah, we can always suggest trying bluepy if we preserve the overlap
sounds reasonable
there is also bluezero
hmm, the documentation is lacking but looking at the code it seems like a pretty reasonable API
did you look here: https://bluezero.readthedocs.io/en/0.0.6/overview.html
yes, that's what I meant, if you look at https://bluezero.readthedocs.io/en/0.0.6/level10.html#module-bluezero.peripheral
it mentions classes but nothing more
although the naming is still a little bluez-dependent:
>>> app = peripheral.Application()
>>> app.add_service(your_service)
>>> app.start()
quite a mouthful ๐
that's a cool name
not to be confused with super()
blue like a jazzman's soul
maybe we can call the blue module tobias ๐
way over my head
To comply with the one thrown in the ESP port.
will wait for travis before merging
It's a Arrested Development reference ๐
ah, I've only seen a smattering of them
annyong!
Hello
yay, with the define removed bitbangio builds for nrf, not sure if it works but it builds ๐
Hey, it's progress, right?
works for me
as in, I'm ok if it builds
master is still pretty early in the dev cycle so we have time to find and fix issues
need to visit my hackerspace to get some i2c boards to test
@indigo wedge order it with the nrf52 feathers from kevin
order anything you need for testing
they're already shipped ๐
next time!
Heh, I'm just grateful I was offered anything at all ๐
you are being a huge help, we just want you be more help ๐
It's true!
doesn't nrf have hardware SPI?
yes, but maybe someone wants bitbang as well
yeah, probably not a display ๐
yeah, yesterday i used the HW SPI for the display and that was faster
obviously ๐
cool cool
it was the only spi device i had on hand
Gah, the helper takes an opaque OS error number. What do you think is best?
Damn, I didn't get the warning locally and I did compile it before pushing.
Maybe we should leave it as is and drop this change then? Because if we merge this with whatever errno then the user won't get any friendly explanation.
Otherwise I'm not sure which errno to return.
ok, past midnight, time to go, ttyl
@indigo wedge have a good night!
@tidal kiln It looks like it must be a bad sensor, didn't see find the BNO055 on a different Huzzah programed via Arduino IDE , I shortened the cable to check if it was a length or cable issue ๐ฆ
Hmm. Did it ever work?
yes I had it running last time I was working on the project (May?) but the sensor has been rattling around in my carry case since then
It doesn't look damaged, but maybe it is static sensitive? it wasn't protected with static foam or bag
I'm not sure with that one.
Works for me. We have an issue for better OSError messages in the future.
im ok with dropping nrf51 completely and not doing any work to support, its ridiculously small + slow, and customized and nordic is clearly trying to kill it off :) microbit people can stick to micropython which is the official standard for them anyhow
i do want to support both nrf52832 and '840, even tho 840 is way superior, if its feasable
why would an analog read range from 360 to ~3820 when its 12 bit?
@slender iron could be 12-bit accuracy as opposed to value? And then mistakenly a signed field?
its a tilde not a minus
Oh
so its 360 to 3820
hahaha That's slightly less confusing.
sorry, I realized its confusing
4096 is 2^12, so makes sense?
on 2.x the range is wider
wrong voltage ref?
@heady dove so no luck repeating the previous working config. bummer. hard to say, but, yah, maybe damaged from the tour of duty in the carry case.
just found a Adafruit 9DOF breakout on my bench, not seeing CP lib for it it's using a LSM303DLHC and a L3GD20
those haven't been ported as of yet?
I have the one from a few days ago and didn't see it
they don't ring a bell so I doubt they've been added
no biggie, I'm about due to place a Adafruit order
discount code tomorrow night!
please post two issues if you have time
we should add support in the future
will do, where do I post issues?
@heady dove https://github.com/adafruit/circuitpython/issues
@idle owl Thank you, you read my mind
It happens ๐
tannewt asked me to put a "lib request" in on the two chips used in the Adafruit 9dof breakout
tannewt asked me to put a "lib request" in on the two chips used in the Adafruit 9dof breakout
here is the 2nd chip
thanks @heady dove !
@slender iron You beat me to the label update. ๐
It makes me happy to be part of a coding community
@heady dove We're happy to have you ๐
๐
well I'm definately in over my head, but have been most of my life, so why change now
@slender iron my apparent ASF4 USB descriptor issues were my own fault. I commented out my UART code temporarily and the new ASF4 code works fine and I get CIRCUITPY. So something wrong with my UART init, but not in ASF4 (hopefully); that's actually a big relief -- much easier to dbug.
@tulip sleet That's good then
glad you got past it!
I just dumped the adc state and asf4 hasn't loaded the calibration register
ha!
[can you explain that emoji? person with glasses looking at something] --signed, culturally ignorant
its a table flip
OH.
someone flipping a table out of finding somethign ridiculous
๐
I'm familiar with real table flips. Jesse has done that, unfortunately. Not recently.
let's all debug asf4
so you understand the motivation
oh, yeah, he was mad
m0 or m4?
m0
i happen to have a kdiff3 of the entire tree open... sadly, no changes in adc code.
kk, I'll do it myself
looks like there are hri routines to deal with the calib
dastels wrote one for us, please try it?
https://github.com/adafruit/Adafruit_CircuitPython_LSM303
wow, that was quick.... I'll see if I can make it work
w00t! calibration made it much better
nice!
thanks! if it doesn't please open an issue on that repo and we'll see what it could be!
night all! I'm off to dinner with a friend
later @slender iron, have a good one
There are a very small handful of places that assume that if you're using a SAMD51 that you're using a SAMD51J. We should support the SAMD51G to allow us to pack the SAMD51/CP wombo-combo into an even smaller package.
From looking at the datasheet, the differences between the 51J and 51G are
- Number of TCs
- Number of 16bit TCCs
- I2S support
- Number of GPIO
- Number of ADC channels on ADC1
- Number of PTC channels
- Number of tamper pins
The only problems I've found so far are...
Just mailed out two new StringCar CPy controller boards to the other side of the state. The final code consists of an abstracted main.py of 89 lines and a stringcar-specific library of 180 lines. Both fit on the Trinket M0 with 9600 bytes free. I am completely enamored with CircuitPython, particularly for this project.
๐
awesome job @errant grail !
I just put two and two together and realized that I should make the string racers I'm planning wth my neice
It's a pretty good STEAM opportunity, for sure. When I taught a basic stringcar racer class to an all-adult class at our local makerspace, it brought out the giddy third-graders in them. The race at the end of the class was very competitive.
awesome
also, I need to buy some more m4s now that they're available again
"need"
I experience that "need" way too often for my budget. Oh well.
How's the livewell project coming along? Did I see a random post about blue smoke?
hah, yea I had a janky setup with overly long and overly stripped wires for my SWD connection and shorted SWCLK to a huge lipo 
blew a hole in the case of the D11
$1 down the drain ๐คท
I've since made a tighter, longer SWD teather and put on a new chip. Started playing with JLink RTT which is cool
Back on course, then?
yea, I wanted to commit my SAMD51G fixes for my m4 board though because I'm going to use the same basic design on a new board for the controller for the neice's jacket
Very cool.