#circuitpython-dev
1 messages ยท Page 108 of 1
LOL my bad
Panic attack?
All systems shut down
what's going on?
lmaooooo
everyone comes out of the woodwork when some pings everyone
The all mighty ping
we're failing to discord correctly ๐
To be fair most discord servers restrict access to @everyone
I'm new at Internet. How does work?
new phone. Who dis?
@tiny thicket yeah, but we're mods. ๐คฆ
tubes, @split ocean . Don't be cloggin the tubes.
@@split ocean By removing that ethernet cable...
it's not like a dump truck
๐
to be fair, this said "channel"
and doesn't everyone HAVE access to "view this channel"? ๐
I removed @ everyone rights from @ community helpers
so now only @river quest and I can use it
Thank you @split ocean!
since we clearly have accidental @ everyones you can always disable it for this server: https://support.discordapp.com/hc/en-us/articles/215253148-How-do-I-stop-everyone-mentions-from-select-servers-
^^
@pulsar bronze Just use a reply all meme.
lord of 
Snek
danger noodle?
ah yes, another fantastic one. the former, not hte latter
Flashmob!
welcome back everyone! ๐
All it took was an @ everyone
Hello @slender iron That's probably a good idea. I just got pinged as well.
the message count on this channel just got a boost!
Look! Activity!
Hah, I'm here to accidentally rattle the cage on occasion.
imma make this my last message here, since i know nothing about circuitpython, so have no more relevant conversation to contribute
edit: No worries, but imma not replying anymore until I'm on-topic! ๐
sorry for the ping @cursive sage
I was busy reading about the OpenMV M7 camera and using Python tho access its GPIO. Then, ping. Ah nuts...
it should have being communityhelpers
?membercount
1938
295
1936
2
I thought maybe there was a webcast. Hate missing webcasts. Especially John Parks.
@timber lion whats your current compilation error?
Oh well, back to OpenMV. See ya... ><>
have fun @lofty topaz !
@lofty topaz I'll be on this Thursday, regular time :)
TY @slender iron Be there or be square @split ocean ๐
<@&356864093652516868> this is a special dedication that goes out straight to YOU (and not the entire server) Thank you for your great work on CircuitPython!
I think we all learned a lot that summer.
@split ocean You earned Internet level 1!
looking forward to getting a merit badge for this.
An update on my missing box of CircuitPython boards... UPS called..
So you didn't get your package?
No
Adafruit send new one?
No you guys lost it..
I see, so you buy new one?
No, you guys lost it!
Oh you want us to refund you, not Adafruit?
Yes!
Well we're going to have to keep looking then.
๐คฆ
bummer @formal plover ! did you let support know?
@slender iron not yet. I really wanted to beat up UPS so I didn't have to go through support.
@formal plover they probably have a process for it from their side
its worth letting them know
they keep track of lost package stats and such too
Yeah, I'll let them know. Thanks.
@slender iron still haven't gotten an M4 REPL yet. I used your latest commits (samd51 .ld with no bootloader as default) and overwrote the bootloader (no BOOTPROT set). so it now starts at 0x0. Now I get a "Press any key..." but no ">>>". Does this seem familiar?
it doesn't read anything in?
it doesn't even print the >>>. ctrl-D and ctrl-C do nothing
hrm
Limor and Dean were making tiny patches to some M4 boards when we were there, but was that just Arduino related? Do you know?
yeah, arduino stuff
let me commit my wip and load master
turning on msc is breaking cdc right now...
trying to dupe your setup: 9v wall wart so not powered from usb
๐ good to get you going
agh, now it works; second time. ctrl-C'd in gdb; mon reset; then continue. But that was what I did the first time.
it does seem like it might be a USB problem. What is Dean using for a USB stack for Arduino?
or he's not htere yet
i am almost tempted to port ASF3 to SAMD51
i see and now feel your pain
I do think this code is generally better. Its just not documented well
well, now I have an existence proof, so onward
@slender iron do you want to track GCC warnings when building master as a bug to get to zero warnings?
@timber lion I believe @tulip sleet knows about those warnings so repost them here
cool, i'll put them in a bug so they're not lost
there is an lto warning in the latest build re a USB vars; maybe that's what you saw
but that might be real - the previous lto warning is a gcc bug
I think the usb warning is also a bug because it warns that we need a feature that is already enabled
I noticed some non-fatal warnings when building the current master/3.0 branch for circuit playground express:
arm-none-eabi-gcc -Os -DNDEBUG -finline-limit=49 -DNDEBUG -flto -finline-limit=49 -I. -I.. -I../lib/mp-readline -I../lib/timeutils -Iasf4/samd21 -Iasf4/samd21/hal/include -Iasf4/samd21/hal/utils/include -Iasf4/samd21/hri -Iasf4/samd21/hpl/core -Iasf4/samd21/hpl/pm -Iasf4/samd21/hpl/port -Iasf4/samd21/hpl/tc -Iasf4/samd21/include -Iasf4/samd21/CMSIS/Include -Iasf4/samd21/usb -Ias...
@timber lion I ran down the battery running Arc Reactor, plugged in a new battery, and it started up fine. no fileystem issues. Fooey. I added a 12-neopixel ring to the CPX (don't have a 24 and the NeoPixel Featherwing did not work well as a downstream set of neopixels).
huh weird!
i can try hooking up to a bench supply and lowering voltage a bit
or maybe i'll let it run and see when it dies and measure the voltage
not sure why but it's 3/3 with repros for me ๐
in real world use at least
i did the bench supply thing quite a lot. random knob twisting sometimes caused an issue, but slow lowering did not cause a problem. I may need a higher current draw. Could you try duplicating again with the 2.x HEAD, and then try my branch (see the bug?) If my branch fixes it, then I'll push that
yeah for your pixel tests were you running them full white? i'd try that to max current draw
i did notice once when i tried a small 250mAH battery on the arc reactor as soon as it went full bright it turned off.. oops too much draw for the battery
didn't nuke the filesystem that time
I did that with the 10 pixels on the CPX. I had a simple allpixel blinky. I made them full bright for 1 sec, just had them go off for 0.1sec to show it was alive. It got dimmer and then quit, but never damaged the filesystem. I'd think that would be similar to the Arc Reactor running down with the 24-npx ring.
Maybe slow decay is actually better. Also, it does keep running for a while even when the npx's don't light up. It can keep running down to 1.8v or so.
but my impression is that you changed the battery as soon as the npx's stopped lighting (may have taken a few minutes to notice)
yeah @tulip sleet it also died with a circuit playground express and the circuitwalker sneakers here: https://github.com/adafruit/Circuit_Walker_Sneakers/tree/master/CircuitPython_Circuit_Walker that didn't have any extra hardware beyond what's on CPX. i was wearing two of them at a bladerunner thing and noticed one shoe stopped working. swapped out the battery and it never came back. at home i tried it and it had the NO NAME filesystem that needed to be wiped
@timber lion well, maybe I'll try several of them at once and see if I can get any damage of some kind - I only have two LiPo's (500 and 1200); should get a few more
@timber lion re submodule problems; did you do git submodule update as well?
not just init
ah i ended up googling the git magic to make it work, like all things git you pull your hair out until you find the magic incantation
the second part of the first answer here is what you want: https://stackoverflow.com/questions/10168449/git-update-submodule-recursive
why it doesn't do that by default... git
@timber lion the proof that git has a terrible UI is that its own commands print out hints of what to do (e.g. what git status prints)
haha exactly ๐
I have 4 or 5 CPX's so I will set them all aglowing and running down the batteries. It looks weird from outside the house at night.
@tulip sleet put them in pumpkins and you'll be ok. ๐
LOL
@tidal kiln thanks - I may tape some CPX's to the windows too, maybe with pictures of stuff in front of them
i actually used that last year for my pumpkin. worked really well.
that's like my upstream for the cp library
i'm thinking of just leaving comparator out for an initial release
@slender iron @split ocean I was wondering why I had adafruit notifications, those usually happen on Wednesday! ๐
๐ we got excited @fickle compass
๐
What's happening with circuit python these days btw? I've been a bit too busy to do any electronics unfortunately
@split ocean is making some more awesome guides for it on the circuitplayground express
๐ ๐ ๐
this is a really handy ASF4 doc for anyone that hasn't seen it: http://ww1.microchip.com/downloads/en/DeviceDoc/50002633A.pdf outlines the why of their design decisions
thanks for the link @timber lion browsing it now to see if it can help me with usb
484 pages. nice light reader. ๐
yeah the top parts are good, explains like what HRI is vs. HPL ๐
they really kinda threw everything out and started over with asf4 it seems
the basic register stuff is the same though once you find where it's at
yeah, I like the theory of it. in practice though its not well documented
np!
cool i have neopixel compiling with 3.0.. but it's quite good at locking up the entire board when I try to write ๐ have a feeling I'm not doing the cast to port group correctly
awesome! are you using jlink to load and everything?
nope just building the .uf2 for cplay express
on samd21
i don't have the 51 or anything fancy
in theory the hal functions are all the same for 51 vs 21
but i'll be curious to see if timing is diff
first want to get it working on 21 though
cool got neopixel going on samd21
w00t!
yeah i was doing some bad casts to convert from pin # to port register
ah
had to dig into their source a bit to figure out how they do it now
good work!
i'll send a pull for it to master, but yeah it's not 51 tested yet
but probably can't hurt to get in 21 at least
i have a feeling 51 will need some special timing
might need like a board specific neopixel_write implemntation
board specific? we can ifdef to change between samd21 and samd51
do you have an m4?
hrm ok. ideally when we re-enable stuff it works for both the 21 and 51
teensy isn't what I'm thinking though it is an m4 ๐
d232056 atmel-samd: Update and enable neopixel_write fo... - tdicola
ok. think i'm ready to make a pr. do i do that to the main cp repo?
for the drivers @tidal kiln ?
yep
nope, they'll live outside the repo
how to submit then?
Add driver to support the Adafruit TSL2561 Digital Luminosity/Lux/Light Sensor Breakout.
did you see my comment about my desire to get the API like AnalogIn?
ok, I was thinking it'd be nice to change the API so that you can use a single channel from the ADC in place of an AnalogIn
"in place"?
right, python doesn't necessarily check types. it just assumes you can use an object the way you want until you can't
so basically make it behave the same
right
does analogin work like that?
I have this imaginary world where every driver for a given sensor type can be swapped for another
right a would be equivalent to adc[0]
but when using AnalogIn, do you even have anything like a[0].value?
nope
i can see it could be done,
the [0] part is different but .value is the same
just create multiple and store in a list
you'll probably want a helper class to represent each channel
and the channel objects would be in the list
a=[]
a.append(AnalogIn(A0))
a.append(AnalogIn(A1))
thats how you could do it with analogin
the adc object itself would be a hybrid between a list and the adc
so len(adc) would return the number of channels
what would importing and setting it up look like?
import adafruit_CircuitPython_ADS1x15
adc = adafruit_CircuitPython_ADS1x15.ADS1015()
for channel in adc:
print(channel.value)
or
print(adc[0].value)
i'd look at adding a channel property perhaps that yields each channel, that way as a generator there's no memory hit
like:
for channel in adc.channels:
print(channel.value)
the .channels property implementation would be funky, ideally with yield in a for loop
but it could just return a list to start
you could also create the channel on item access right?
makes it more clear you're operating on the channels since the adc itself has some global state
like gain, etc
so it's more clear you're operating on channels vs. the ADC itself
but that's just my random thought ๐
right. was wondering about global state stuff.
return Channel(self, index)
@timber lion yeah, its worth thinking about whether channels should be a property
my goal would be able to do something like:
# setup analog
# import analogio
# import board
# a = analogio.AnalogIn(board.A0)
# OR!
import adafruit_CircuitPython_ADS1x15
adc = adafruit_CircuitPython_ADS1x15.ADS1015()
a = adc[0]
while True:
# change neopixel color based on analog readings from a
so it's more of an ADC channel drop in replacement
that seems easier than generalizing the entire ADC
yeah. interesting.
I'm happy to spend time with you hacking on it tomorrow or this week. I've gotta go start dinner tonight now though
yah. no worries. want to link to current repo?
what do you mean?
a link on the issue would be great ๐
when you get a chance, could you paste some of that code example in the issue comments?
my goal would be able to do something like:
# setup analog
# import analogio
# import board
# a = analogio.AnalogIn(board.A0)
# OR!
import adafruit_CircuitPython_ADS1x15
adc = adafruit_CircuitPython_ADS1x15.ADS1015()
a = adc[0]
while True:
# change neopixel color based on analog readings from a
That way all code written for one analog input is agnostic to whether its on the MCU or on a helper chip.
thanks. laters!
Hmm. Who's here that can update the "Learn" pages?
The Trinket M0 page is GREAT
Except
It doesn't list the --port=PORT command
In other news
My Feather M0 basic now has CircuitPython on it
Trying to get teh ST7735 working. There's the library that's supposed to work with it, but the only example is for an ESP8266 and ILI9341
The code is running, but the screen isn't doing anything
Hmm, probably should be in #help-with-projects
Here or there works @cunning crypt
We use this channel for both collaboration and to help others working with CircuitPython.
Useful!
Indeed!
..Well, if I had LOOKED at things, it would have been a bit easier.
I just glanced over the comment block in the ST7735 file and went straight to the init code
@cunning crypt this might help you out if you don't mind getting your hands dirty https://learn.adafruit.com/circuitpython-basics-i2c-and-spi/i2c-devices
Oh, the I2C will be super useful since I'm intending to get my Hall Array board working.
On the other hand, instead of writing a custom library for the Hall Array board, I'm likely to just re-write the board's ATTiny code to be largely functional with the SeeSaw code
Considering they're both intended to do pretty much the exact same thing
I'm following the stuff in the commented out bit in the ST7735 class
And having no results
According to the REPL, there's no errors.
Screen does nothing.
AHA
Screen I have wants ST7735R, not ST7735
"On the other hand, instead of writing a custom library for the Hall Array board, I'm likely to just re-write the board's ATTiny code to be largely functional with the SeeSaw code"
Or not. Poking at the seesaw libraries, they're written by someone with significantly more knowledge and capabilities than myself.
I'm understanding the "How it works" of about a third of it.
On the other hand, I can always write the CP library and post everything on GitHub (Like I was going to do anyway!). Then if someone with better knowedge and tolerance for programming wants to hack away at making it SeeSaw compatible, they can have fun.
Yay! A bug!
Red/Blue are swapped
goes to write bug report
Also, a question I'll leave as I go to bed: I'm seeing a number of examples with board.GPIO# and using the M0 basic, I need to use board.D# (I haven't tried analog pins). Attempting GPIO# fails completely. Is this an old method that needs to be updated in the examples, or is it something that should be addressed with the M0 basic's CircuitPython core?
@cunning crypt the pin naming is a mix - on the ESP8266 the GPIO# are used on the M0 it is D#. One way to verifyt the names is in the REPL: ```impport board
dir(board)
Here's a straw proposal for how to manage keeping ASF4 up to date, patching its bugs, and adding enhancements.
- Create a new
adafruit/asf4repo. In branchmaster, commit the latest downloaded/scraped snapshot of all the code we might want. Top-level dir isasf4, with device/family-specific directories as necessary:asf4/samd21,asf4/same21,asf4/samd51j, or whatever. (I don't know how ASF4 distinguishes variants that are only pin changes.) - Create branch
master-bugfixes....
I made the _usb_ep1_cache cache warning go away by declaring it in usb.c as:
extern uint32_t _usb_ep1_cache[];
instead of
extern uint32_t *_usb_ep1_cache;
The current declaration is a part of a hack due to some bug or other issue with the ASF4 USB stack. @tannewt is reaching into an internal data structure to get the input characters.
The other warning is explained in #248: it's a gcc LTO bug. The LTO folks are testing a fix, so we should see it eventually.
@solar whale That is incredibly annoying. There should be a unified pin scheme for all MCs, IMO.
Honestly, I prefer GPIO over D/A
GPIO4 is GPIO4, whether it's analog or digital. Although I get why wanting to keep the Arduino-style stuff around is a thing
@cunning crypt I'm just the messenger ๐ - on the Trinket M0 D0 is A2,D1is A0 D2isA1 D3isA3 and D4isA4 - lots of fun!
Yeah, figured you were the messenger.
Also figured if I'm going to voice a complaint, here would be the place.
@cunning crypt yes, it sure is.
It's probably on their radar anyway
if you find a bug, you can open an issue in the github repository https://github.com/adafruit/circuitpython/issues
@cunning crypt CircuitPython is non beta, but it's still a maturing language. The community has been really great at embracing that concept. The fact that it's so open to the community for involvement is what's also making it great. People finding bugs and adding drivers, libraries, guides; makes it special.
@formal plover Exactly. Just because it's non-beta doesn't mean it's super-perfect-finished
@solar whale I planned on it... once I'm off my phone and on my computer and have had some breakfast
Typing bug reports on a phone is... not the best typing
fyi. if anyone else is experiencing github weirdness right now:
https://status.github.com/messages
"Recently performed site actions may not appear in the UI."
Good to know
I'll have all the boards that support CircuitPython by the end of this week!
@formal plover Will you then be feeling a bit... bored?
Bwhaha puns are back! @cunning crypt
Back? I never stopped!
@cunning crypt pin names in the board file are there to match the silkscreen on the board. Its not our place to normalize pin naming
@slender iron I both agree and disagree.
Primarily, I feel like having no method for universal pin control (Be it separate from GPIO/DX) makes basic examples, and board-to-board porting, a lot harder than they really need to be
@cunning crypt I don't know what you mean by universal pin control
I do know there are names we are starting to standardize like D13, MOSI, MISO, SCK, TX, RX
Uhh.... one call that pulls the appropriate pin number.
IE, PIN13 would call GPIO13 if the board uses GPIO, or D13 if the board uses D
right but neither board calls it PIN13
I noticed MOSI, MISO, etc yesterday. Quite useful and I love it.
and 13 is arbitrary
Agreed, 13 is arbitrary, but that said - I'm coming from a largely Arduino background. pinMode(0, OUTPUT) works on the ESP arduino core, the M0 arduino core, the ATMega arduino core, the ATTiny arduino core, even if they're routed to wildly different pins.
Which allows an example code to, for the most part, work across all boards because people can be intuitive and realize Pin 0 is GPIO0 on the ESP, or D0 on the ATMega
Something like this (but with a generator instead of static list of channels in the ADC class):
import random
class ADC_Channel():
def __init__(self, adc, channel):
self._adc = adc
self._channel = channel
self._value = None
@property
def value(self, ):
#self._value = random.random()
self._value = self._adc.read_adc(self._channel)
return self._value
class Generic_ADC():
def __init__(self, ):
...
@slender iron You work on the RGB Display libraries as well, correct?
@cunning crypt Ah, I don't have an Arduino background so pin as a number is weird
I only work on circuitpython libraries
That's the one I was referencing
It's non-critical (for me)
thanks for filing the issue! @stuck elbow will hopefully see it then
And I agree, pin as a number is a little weird, but it's a bit more beginner friendly
Things don't get done without bug reports
yeah, python identifiers can't start with a number, thats with is GPIO0 on the ESP
I don't think they can in any language I know of.
If I recall correctly, Arduino has a file for each board
Which tells it which number goes to which actual pin
Yup! Thats what I was thinking.
And then replaces everything at compile time
๐ฌ
It can get away with things like that since it can afford "bloat" since all of that gets stripped away when it's compiled.
@cunning crypt looks like ladyada got back to you ๐
I see that!
yeah, compiling is nice for code size and speed
Sounds good to me!
On Wed, Oct 11, 2017 at 6:18 AM Dan Halbert notifications@github.com
wrote:
Here's a straw proposal for how to manage keeping ASF4 up to date,
patching its bugs, and adding enhancements.
- Create a new adafruit/asf4 repo. In branch master, commit the
latest downloaded/scraped snapshot of all the code we might want. Top-level
dir is asf4, with device/family-specific directories as necessary:
asf4/samd21, asf4/same21, asf4/samd51j, or whatever. ...
@formal plover whats your username on github?
@slender iron KurticusMaximus
Haha don't ask.
I tired to switch it to Kurt H and it came with like 60 warnings.
There is an older MicroPython version you can start from here: https://github.com/adafruit/micropython-adafruit-tsl2561
I believe @KurticusMaximus was also looking to cookiecutterify a similar repo.
I'm tannewt so no problem from me
Changing usernames on GitHub is not the best thing. Otherwise I'd be AndonRT like I am pretty much everywhere else now
@fading solstice ping me if you are around today
Could get a little messy trying to support all the modes the ADC can run in: single ended, differential, comparator. AnalogIn is essentially single ended only, so could make it to where that is the only mode supported for the above access method.
The ADC class will still have full functionality.
adc.read_adc()
adc.read_adc_difference()
adc.start_adc_comparator()
# etc
I could go ahead and set this up. I'll set up the initial master with your asf_update.py, then create a master-bugfixes branch, and then a circuitpython branch. I'll apply the patches to generate changes in circuitpython. Are there patches that are bug fixes now, or are they all enhancements?
Is the stuff in asf4_conf specific to CircuitPython or should it go in the new repo?
Then I'll submit a pull request to change the asf4 tree in adafruit/circuitpython to replace th...
asf4_conf is specific to our set up. I'd leave it out.
Your plan sounds good!
On Wed, Oct 11, 2017 at 10:31 AM Dan Halbert notifications@github.com
wrote:
I could go ahead and set this up. I'll set up the initial master with
your asf_update.py, then create a master-bugfixes branch, and then a
circuitpython branch. I'll apply the patches to generate changes in
circuitpython. Are there patches that are bug fixes now, or are they all
enhancements?Is the stuff in asf4_conf spe...
Sure. The other way to do it would be three separate drivers for the three
different modes. Each could be in a different file so you only need to load
the code related to your use.
On Wed, Oct 11, 2017 at 10:30 AM Carter Nelson notifications@github.com
wrote:
Could get a little messy trying to support all the modes the ADC can run
in: single ended, differential, comparator. AnalogIn is essentially single
ended only, so could make it to where that is the only mode supported for
the...
anybody besides @idle owl have PRs for me to look at? I'm going through them now and then will be heads down on USB.
Separate ADC classes?
@slender iron I don't know how to work more than one pull request at once, so I keep doing them sequentially. The next two API updates are done, but might result in feedback from you, not just an automatic merge.
kattni, you just need multiple branches, one for each
It doesn't cause merge conflicts as you merge the first one and then try to do the second one? That's what I was trying to avoid.
it will potentially, you just need to rebase the one thats committed second before its pulled.
Yup, thats what I mean. So maybe:
from adafruit_ADS1x15.single_ended import ADS1015
What do you think? The model of more, smaller classes makes sense in terms of reducing memory footprint.
Hmmm. Or if we add a mode property to the ADC class. Could then do something like:
class ADC_Channel():
def __init__(self, adc, channel):
self._adc = adc
self._channel = channel
self._value = None
@property
def value(self, ):
if self._adc._mode == self._adc.SINGLE_ENDED:
self._value = self._adc.read_adc(self._channel)
elif self._adc._mode == self._adc.DIFFERENTIAL:
self.value = self._...
Some reference info, to compare with Arduino's I2C behavior it looks like there's no scanning built-in but if you use a scan sketch (like this one: https://playground.arduino.cc/Main/I2cScanner) it will require initializing the I2C library (Wire.begin() call) which turns on the AVR's pull-ups for SCL and SDA: https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/Wire/src/utility/twi.c#L75-L77 It seems reasonable to match Arduino's behavior here and temporarily turn on...
@slender iron Sorry about that, you were right about the change you requested. It's been updated. I'm letting you know here because you said it doesn't pop back up in lists for you if you request changes.
yup! I saw. it works ok now?
Yeah, I took it directly from a file that Dan sent me. I thought the fact that the neopixel library worked differently explained why the property looked different. I just tested it multiple ways though. I have lights. ๐
๐
And for the Pi it looks like they build in physical pull-ups (1.8K on the GPIO2 and GPIO3 lines for SCL, SDA): https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/Raspberry-Pi-3B-V1.2-Schematics.pdf Seems reasonable to match the behavior and turn on pull-ups when doing an I2C action like scanning.
I like keeping ADC to just one class - or more importantly, making the CircuitPython version match the Python version as much as possible. Otherwise there would be an Arduino way of using it, a Python way of using it, and a CircuitPython way of using it.
I'm thinking this feature should be, as much as possible, a bolt on to the ADC class.
The fact that Arduino turns on pull-ups automatically is a well-known problem in the Arduino community, and the reason why the advanced users use other libraries (or just ad-hoc code) for IยฒC when the need to interact with mixed-voltage devices.
You also need to consider how the pull-ups will interact with the external resistors already included on the IยฒC lines. If high-speed communication is needed, strong pull-ups will be used, and that can be too strong fro the pins to drive when combined with the internal pull-ups.
@deshipu Is it a problem electrically if we just turn on the pullups during scan() and then turn them off again?
I agree pull-ups are a reasonable default, but I would also strongly advise to have an option to suppress them.
How about this? (mode is in channel, not adc)
import random
class ADC_Channel():
SINGLE_ENDED = 0
DIFFERENTIAL = 1
COMPARATOR = 2
def __init__(self, adc, channel):
self._adc = adc
self._channel = channel
self._mode = ADC_Channel.SINGLE_ENDED
self._value = None
@property
def mode(self, ):
return self._mode
@mode.setter
def mode(self, mode):
self._mode = mod...
@deshipu Is it a problem electrically if we just turn on the pullups during scan() and then turn them off again?
Yes, it's still a problem. If you have a, say, 5V device on your IยฒC bus, and consequently, external pull-ups to 5V, then enabling the internal pull-ups to 3.3V will result in a short โ through two pairs of large resistors, so maybe not that catastrophic, but a short none the less.
I think keeping the circuitpython version like the python version is misleading. Our hope is to go back and implement the lower level APIs so circuitpython libraries work on raspberry pi as well.
Arduino and Python are different enough that its worth redesigning the API to fit python better.
If I understand correctly, Adafruit's philosophy is to have pullups on the I2C peripheral boards, not on the master board. So our core I2C implementations do not turn on internal pullups.
I don't like mode as a channel property because modes affect the number of channels. Right?
It also changes the meaning of value which adds a ton of complexity to the API because you can't understand value without reading mode as well.
Why can't we fix this by double or triple probing addresses that are available? If its really just line noise from no pull-ups then it shouldn't be consistent over repeated probes. There is no need to turn on internal pull ups.
I don't like mode as a channel property because modes affect the number of channels. Right?
Not for the ADS1x15's. There are always 4 "channels". What those 4 mean changes with mode. For example, in differential mode:
0 = Channel 0 minus channel 1
1 = Channel 0 minus channel 3
2 = Channel 1 minus channel 3
3 = Channel 2 minus channel 3
Alternatively, we could read a value on those pins before doing anything else, and throw an error about missing pull-ups if it's not consistently high.
Let's not lose the forest between the trees. The original issue here is that I2C scanning is erratic and weird--if you're at the REPL and learning about I2C it's strange to have nothing connected but see random addresses returned. It's good to get the positive feedback that with nothing connected no devices appear in a scan, then connect a device and see it's now available. This is the same behavior in Linux with the Pi (call i2c-detect with nothing attached and you see nothing because of ...
My opinion, as a generic basic user, is default enable but with option to override. As has been mentioned previously, the biggest conflicts are when talking with other-voltage devices, something that newer users generally shouldn't be worried about, and advanced users should know. It'd be fairly simple, I think, to put in a guide "If you're using this with a 3.3v board, make sure to turn off the default internal pullup resistors"
IMHO flip on pull-ups for scan, it will make the most sense for the most users.
But you can damage your devices by doing a scan then if your bus is pulled up to anything else than the board's voltage. We don't want to damage devices by doing something as innocent as a scan.
Turning on pull ups risks changing the properties of the bus and causing other read failures.
I wouldn't multiple probe all addresses, I'd only do it on "found" addresses to confirm they are really there. The example at the top only has one phantom address so it only result in a few extra probes to confirm its there.
@deshipu That's a similar problem with the Pi and Arduino and they haven't had any issues. IMHO it's an edge case to alert folks in docs and not worry about. If you're mixing I2C voltages you're doing pretty advanced stuff and are knee deep into the inner workings.
On a different, but related, topic, I wonder how does it work when you have multiple Adafruit modules connected on the same IยฒC bus, and all the pull-up resistors on those modules stack up, potentially creating a pull-up that is too strong to drive low. Have there been any experiment about how many Adafruit modules you can connect at once before that happens?
@deshipu Lets not discuss that here.
@tannewt Not sure I follow the issue with properties of the bus? This wouldn't be in in the I2C init but only in the scan. Perhaps in the probe call it would check if pullups were previously enabled and turn them on and then off if not.
@tdicola I think that if we are going to enable the pull-ups by default, we should do it in the init, not in the scan. Otherwise people will be surprised that their devices don't work even though they appear in the scan. I would propose to simply add a keyword parameter to the I2C constructor that suppresses the internal pullups when set to true.
Yeah I was thinking about that but I think it's better raised as a separate issue. To me it seems like another odd edge case, you plugged in a device and are making I2C read & write calls but forgot to call init. In that case no matter what your code won't work since the sercom, etc. initialization was never called. The only other case is if you're using a device with no built-in pull-ups, but that's not typical for adafruit and most arduino add-ons. It might be worth discussing but I thi...
I think that if you just want to fix the scanning, then checking if the pins are really consistently high before the scan is the best option, because:
- it's completely passive, you are not sending any voltages down the wire,
- it lets you throw a very specific error with a message explaining the issue,
- it doesn't slow down the scan itself, just adds a constant small delay in front,
- an explicit error is less confusing than just an empty list,
- it will also handle the case whe...
Ah ok. I still don't like the meaning of value depending on mode.
I think back to the original issue though, person at REPL learning about I2C and calling scan with nothing connected. If they get an error vs. an empty list (which is how the Pi, Arduino, etc. all behave today) it seems weird to me. Did they do something wrong? Not really. If the proposed behavior of turning on pull-ups has been used by Arduino & Pi users (millions and millions of people) it seems safe to apply here too.
I think that an error like "Pin XXX is not high. Is your device connected?" would be informative enough both for professionals and beginners. It's really not obvious to me that a wrong connection would result in an empty list of devices. The fact that both Arduino and RPi do that doesn't mean we can't do better.
And if you really think that an empty list is better, we can have an empty list returned instead of the error after this check. No need for the pull-ups.
And error would be better also because in the case when the device is connected (so the pull-ups are present) but broken or the SDA and SCL are swapped, you get a different result โ an empty list. Then we can cover it in troubleshooting instructions.
Errors are scary--we're super experienced and don't think twice about them, but to a normal user it means they did something 'wrong' and shouldn't do that again (did I break things? etc.). I'd strongly prefer not to return an error for a common case (step 1 in learning about I2C, scan for devices). Checking if the pins are high and returning nothing seems like another good way to fix it though.
Arduino vs. Pi goes both ways--perhaps Arduino and Pi were so successful because of the choice...
@tdicola I disagree with the sentiment about errors. If everything is hidden, then it can be really annoying and frustrating to figure out what's wrong with my device.
Errors can be phrased nicely - IE, "No pullup resistors detected. Is everything connected correctly?" lets people know precisely what is wrong without the 'scary' aspect of "Error 254150: Pin is floating" or different.
How about returning None in one case and empty list in the other then? We still give users the information, but no error?
I think that "errors are scary" approach is what made PHP as horrible language as it is โ it tries very hard to not raise an error, which in turns leads to errors that go unnoticed.
Errors shouldn't be scary. They should be informative and useful. By including informative and useful errors, the scariness of errors can be eroded
Question: If I call an invalid pin, does CircuitPython yell at you, or ignore it?
Arduino ignores bad pins, which I've never particularly liked, but I know there's a few times people have (ab)used it
Or I could just take the simple solution and plug in and go to the REPL. It yells, as it should (IMO)
@cunning crypt the REPL makes it easy to answer a lot of questions with "What happens when you try it?"
Rather than write up code, compile it, upload it, open the serial monitor, make sure you're using the right baud rate...
This is true in any language with a REPL, Scheme through Erlang through Python and Ruby.
Well, you do have to set the correct baud rate on whatever you're using to attach to the REPL, but you can probably script that.
Well, yes, but with Arduino you're using a bunch of different boards with different baud rates. Once you're already in the REPL, it's "Type a line to test"
on the ESP boards with webrepl, you don't even have to connect the board to test.
At the moment, different boards use different pin methodology for IDing their pins. These match the silkscreen on the device itself, which is great. However, this can be annoying for porting code from one device to another, especially if the only thing that changes is pin designations. A special case is for examples: The "Blink" example for one board doesn't necessarily work on another board, and that's one of the most simple examples there is.
Implementing an "ID" function in the board li...
@slender iron I think that issue I just posted would, overall, be a much easier solution than unifying the pin names. Plus, it has more uses than just pins.
@floral dagger I just started poking at CircuitPython yesterday. Haven't got that far yet, but sounds great.
@cunning crypt If you have a huzzah, check it out. You can access the repl through a web browser. If you also have it connected via USB, you can watch one change as you type in the other
It's pretty cool
@cunning crypt Feather HUZZAH is where it's at. There's a few of us floating around playing with CircuitPython and the HUZZAH. @floral dagger has been doing some really cool stuff with it.
Am I correct in reading that SD cards aren't fully supported on CP yet?
@cunning crypt jerry found a bug on esp8266 with SD cards but its worked for me with an M0
playing a wav off SD also doesn't work yet I believe
Oh, cool.
I just read that the M0 Adalogger doesn't support the SD card
and remembered seeing an SD card issue
where does it say that?
Main page, under Supported Boards
๐ please file a bug to fix that
You said playing wav off of an SD doesn't work?
May want to re-open this then: https://github.com/adafruit/circuitpython/issues/105
The board is available through the os.uname() tuple result as machine.
Adafruit CircuitPython 2.0.0 on 2017-09-12; Adafruit Trinket M0 with samd21e18
>>> import os
>>> os.uname()
(sysname='samd21', nodename='samd21', release='2.0.0', version='2.0.0 on 2017-09-12', machine='Adafruit Trinket M0 with samd21e18')
>>>
@cunning crypt I'd rather open a new specific issue for the SD card. I can't remember who ran into the issue. I think it was on discord here.
Fair enough.
@slender iron getting close on the asf4 repo. Already created. I have a couple of samd21 patches that don't apply with the latest download. I'll diff the final result with the current tree to see what's new. Q: do you need to add the repo to #adafruit-github-feed, and should we add it to bot notifications in #circuitpython-dev? It's adafruit/asf4. Did you get a notification that it was created and you were subscribed to its notifications?
I don't think we need to worry too much about bots
I did get the email about it
what didn't apply? the latest patches I added I split by hand
cast-align.patch for (only) samd21/hal/src/hal_timer.c and flash-const.patch for samd21/half/src/hal_flash.c. The samd51 versions of those patches applied fine. I haven't taken a look at the diffs yet at all. Re bots: do you mean it's not worth adding all the new repos (or is that automatic)? I kinda like it, but I could get the same info from github.
On the main page, it mentions that the Adalogger's SD card is currently not supported.
Via the Pins chart on this page it appears that the SD_CS pin is linked to a pin not used by the rest of the Feather M0 versions - PA08, which is used as D4 on the Metro M0 Express.
Man, GitHub Bot is on the ball. Shows up almost faster than on the web page
the bots aren't automatic but I can give you the secret url to add more if you like
@slender iron @cunning crypt The note in the "readme" regarding no SD support for the M0 Adalogger is a holdover from the orignal CP releases. SD support is now available, but as to playing WAV files, that may well be an differnt issue. I have not tried. They play fine from the M0 Express boards "on-board" flash.
ok, pm me
@cunning crypt its based on github webhooks so its speedy
Yeah, webhooks are fast. Even though I've been using it for ages, I'm still amazed at HOW fast the internet can be sometimes
@slender iron @cunning crypt I may have mis-spoken - What I have tested is the Adalogger Featherwing on a feather M0-express. it eorks fine with adafruit_sdcard.mpy - I have not used the M0 Adalogger. Sorry for any confusion.
I've tested with the M0 Adalogger
@slender iron Am I correct in assuming that board, os, etc are all generated and there's no place I can go to look at the various ones for various boards?
what do you mean by generated?
the APIs should generally be the same with the exception of the pin names
I want to look at what they spit out.
board is based on board_global_dict_table: https://github.com/adafruit/circuitpython/blob/master/atmel-samd/boards/trinket_m0/pins.c
If I want to make a "Blink" sketch that runs on all boards, I need to know what os.uname() returns, and what pins are available in board
uname is based on common_hal_os_uname: https://github.com/adafruit/circuitpython/blob/master/atmel-samd/common-hal/os/__init__.c#L66
I knew the information was there, I knew the file itself didn't exist until it was made and shoved on the board, but I wasn't sure where to look
yeah, its all compiled it
Hmm. MICROPY_HW_BOARD_NAME is what OS pulls, but I'm not sure where it's pulling it from. Time to dig.
There it is
boards/(whatever)/mpconfigboard.h
make a pull request @cunning crypt !
I'd have to remember/re-learn how to use GitHub first!
๐
(On my list of things to do!)
for something that small you can actually edit it on github if you like
Well, now THAT'S certainly convenient
Pretty much all the boards
have the built-in LED on what's referred to as D13
๐
Except for the Huzzah, which is GPIO0
That makes writing this universal blink script a LOT easier.
I'm going to skip the M4 express since it, well, doesn't really exist quite yet as far as I'm aware. Outside of prototypes, of course
M4 the new hotness
GPIO0 is also the pin that sets the esp8266 into programming mode, so it can be a tricky one to mess with
I hate that pin lol
Oh, oh yes.
But if you're using it as a simple LED flash, you're fairly safe
Dpes anyone have the Feather M0 Adalogger with the latest CP on it handy?
According to https://github.com/adafruit/circuitpython/blob/master/atmel-samd/boards/feather_m0_adalogger/pins.c
SD_CS should be a pin
which means that it IS supported, but the readme is out of date. But I don't want to close the issue/update the readme if that's not the case. And I dont have one to test with
In the pins.c file of the Feather M0 Adalogger, it looks like SD_CS is listed as PA08.
I don't have an M0 Adalogger Feather to test with, though.
I'm guessing the ESP modules don't have the handy-dandy show-as-thumb-drive support
All patches in asf4 tree were applied to teh adafruit/asf4 circuitpython branch.
Well now THAT is weird.
digitalio seems to not exist on my Feather Huzzah
oh, no, it's just my typing
@cunning crypt esp modules don't have built in usb
exactly
Interesting. Feather HUZZAHs actually have two built-in LEDs
ESP-12 module has one tied to GPIO2
And there's the Huzzah board one that's tied to GPIO0
@slender iron What's the recommended way for getting files on/off of the ESP?
we use ampy
some folks use WebREPL too
::raises hand::
I WAS going to complain that ampy was refusing to access the ESP
Then I remembered I had the REPL up
I need to dig into how that webrepl uploader works. I would like to make a gui uploader for the ESP
THAT would be fantastic
Indeed that'd be pretty awesome. I've been using Ampy for quite some time now @cunning crypt
Apparently I had ampy already installed
I remember trying out micropython on the esp ages ago
Gotcha. Update Ampy or you're going to have a bad time. Lol
Oh, I did
Haha good deal
hello
Hello @timber mango!
i was wondering how i could do the number call thing at the end of the live stream
@timber mango they'll say it's ohm-bit-stab I'll be a kill joy and just tell you it's 646-248-7822
@timber mango They'll tell you when to call.
You'll have to wait till they open the lines of course. The trick is there's about 4 seconds of delay on YouTube so you have to call just a tad early
@timber mango you're welcome!
thank you kattni and kurt
And don't hang up on accident lol. I've done that before.
You're welcome. You can call that number whenever you want and leave a nice voicemail if you'd like as well.
@slender iron I have my new logic analyzer and it is working well. Here are some screen shots: First is the micropython sdmount on the esp8266: oops wrong file - correct one below hmm can't delete the attached file - sorry
great!
adafruit_sdcard attemted sdmount:
micropython sdmount - works
now to figure out why..... clearly something not working
If anyone wants to take a look: First draft of the "Universal" Blink example
https://hastebin.com/kokukoweci.py
@solar whale wow. mosi and miso are totally flat.
hey, just wanted to let folks know. if you have an issue or PR that you are waiting for me on I'll do it in the mornings. I usually segment my day so I can focus on code in the afternoon.
@tidal kiln yes - clearly not responding.
@slender iron Thanks for letting us know.
Ugh. CircuitPython I2C is not being kind to me.
@cunning crypt look at the I2C BusDevice
I was. It was "Working" but I wasn't getting any useful data from it
Since it's an ATTiny running an I2C slave code, I'm not 100% sure it's not the issue there.
But, in any case, I'm just going to try again another day
๐
@slender iron If I make two pull requests, are you going to have to kick the second one back to me to resolve the conflicts that won't exist until you accept the first one? I'm unclear on how that would work.
not sure, give it a shot!
Sounds good! Thanks!
np
Does AnalogIn have a differential capability? Like, what is the differential form of this:
import analogio
import board
a = analogio.AnalogIn(board.A0)
Nope, no differential support, though there could be. If you have a proposed API that would be great (open a new issue). I briefly looked in the Arduino world and I didn't really see anything.
@formal plover let me know if you're working the TSL2561:
https://github.com/adafruit/circuitpython/issues/314
@tidal kiln Nope, I'm working on the HT16K33
cool. that's you that scott's referring to in the comment?
Haha yeah, KurticusMaximus
any idea what he's referring to? "similar repo"??
I think he was just referring to that I was using cookie cutter to pull the info from GitHub to build the readthedocs for it. Radomir (deshipu) already created a Micropython driver for the HT16K33, so I was cloning that repo and making it more CircuitPython ish and creating the Readthedocs for it
hmmm. ok. sounds like there's no existing circuitpython work or anything if i just go ahead and start fresh on the TSL. (i'll take a look at the micropython version of course)
@tidal kiln yeah, similar situation here. I believe that's what he was referring to
There's no readthedocs for the driver. So I have to make one
ok. thanks. guess it'll make more sense as i go through the cookie cutter process (again).
Yeah. I'm really far behind. I'm hoping to work on it this weekend.
I had everything up I was working in and we lost power... So that's always good. So now I have to figure out where I left off
Oi
lost power and lost work? ouch
Ohhh yes. Always fun.
yah. "fun".
I was just doing everything through VNC on a Pi. I had 2 CircuitPython boards hooked up where I was working on projects and this readthedocs stuff up... Lots of things gone.
Buggery. I hope it's a lot less gone than you think with some luck.
@idle owl Thanks, I hope so too. The project stuff I was actually saving notes on my Chromebook that I was using for VNC to the Pi... The readthedocs stuff though was like mid session though. However, the files should be saved. I had everything I think I needed in the folder and was just going to test the code to make sure it worked.
Then make it more CircuitPython ish and post it.
@formal plover Yeah I've been there where it turned out things saved more recently than I knew and in the end I didn't have to redo a ton. But you never know until you get back to it.
Nice!
I should have recorded our trio session with Scott. Lol.
Even when I take notes, I sometimes wish I'd done the same.
Right right
looks at notes Why did I write index here? (etc...)
Seems about 50% of the time, with a currently open file, Atom follows not only when I rename the file, but rename and move it. The other half of the time, if I rename it in place, Atom throws a popup error and fails completely. I still haven't figured out whether there's a pattern to when it fails or if it's completely inconsistent.
The error says it's a known bug so I haven't bothered reporting it. I never lose work from it, it's mostly a curiosity.
Gotcha.
hey @tidal kiln , drivers don't need _CircuitPython in the py file name
I'd probably do it as a separate class because these APIs are functionally split rather than split by peripheral.
hmmm. thought i read that somewhere...checking...
yah. not sure what made me think that was the pattern.
its good for the repo name
ah
filenames are used in code so its a bit long for that
that's probably it. was giving cookiecutter the repo name.
and i'm also probably incorrectly thinking directory name == repo name
yup yup, all my directories are just the device name
I thought I fixed the merge conflict but still see errors. Would you mind rebasing this locally? Thanks!
prior to being forked/supported, what should it be called?
@tannewt may take a few days to get to this due to illness.
@tidal kiln adafruit_ is fine. we'll get it supported soon
also. pep8 check. the .py should be all lower case?
yeah, I usually do that
@meager fog had the idea of us hooking up python code style auto-checking to learn guide code and we could do libraries as well
That would be neat. I use a linter in Atom but I'm finding sometimes I have to pass up the suggestions for readability. I had it running from the beginning of learning code, so it's been a bit of a change to have to make design decisions that go against the linter's suggestions. Sphinx especially messes with it.
my favorite part of pe8: "However, know when to be inconsistent"
yup yup, I'll want to tune it for my style
@idle owl looks like you'll need to rebase the second pull request
@slender iron I watched it update to having conflicts as you approved the first one.
๐
Which is what I expected. It works out though because Wolf REALLY wants to teach me rebase. And we haven't had a legitimate reason to do it yet.
๐
@tulip sleet lol: +5, -441,475 lines: https://github.com/adafruit/circuitpython/pull/318
@idle owl I have 20 minutes now if you want me to help on the acceleration PR
@slender iron You wouldn't have time in about an hour would you?
Or anytime after that, I meant.
Oh yea, he can definitely help me with rebasing it. That's no issue.
i'll be at the library this afternoon likely. I won't be able to voice chat but will be on text
Ok
hi @here we are going to be doing some fun ads with circuit python, SO! like all things adafruit, we're going to ask our community what they think! 
I haven't been able to reproduce the brownout bug (#280) by running down a battery. But this code should fix the problem. I was able to randomly break the filesystem by varying the voltage on a bench supply. I tried the same thing with this patch, and didn't get an error. But that's not a sure indication of a fix. Nevertheless, this code add more safety to safe mode.
we'll do some small banners likely with blink, the boards, etc. and we're thinking of this text - "CircuitPython - A Python implementation for coding with microcontrollers from Adafruit"
Something on the lines of the snake game and the mascot?
so when ya'll see this, make suggestions on how we can explain and show circuitpython
yah, we'll have blinks for sure in some way
@river quest I think of circuit python in terms of outcomes. It's relatively easy to learn, supports a wide variety of sensors and stuff at a high level, is self-contained, and is directly related to a seasoned programming language that likely won't go away. You can learn and create with CP then apply those skills as you progress as a maker or in your career.
good stuff @errant grail
so maybe ... Know Python? Make sensors sense with CircuitPython
yeah -- what you get with CP is simple, easy, expandable, and not proprietary
CircuitPython - Simple, easy, expandable, will not hurt your feelings
๐
good easy and confortable
now i feel like i gotta try it
CP-Fast dev stuffs for the rest of us.
Couldn't resist the seinfeld reference
CircuitPython - Fast dev stuffs for the rest of us
I almost always talk about it being a teaching/learning language when I talk about it. Which happens probably more than it should. And I always talk about the community that comes with it.
Could always use the "robot friend" theme.....CircuitPython: Make robot friend - not robot enemy.
The community is amazing. And in my opinion, a crucial part of the language. You have an idea? People will help you make it happen. You don't know Python? People will help you learn with CP. You just want to share something you did? People will be super supportive.
There's zero chance I'd be as far along as I am in learning programming if I hadn't stumbled into the Circuit Playground Express and CircuitPython.
I'd have to give it more thought to turn all of that into a snappy tagline though. ๐
Learn, program, grow!
@river quest where might we see these banners when they go live?
Code + Community = CircuitPython
@floral dagger MAKE and hackaday since i either worked there or founded it
@tdicola Pull request #319 would fix this, I think. I was able to break the filesystem a few times with the bench supply, and then after #319, I couldn't, but it wasn't really a good test. If you see this problem again after building the latest 2.x or using the upcoming 2.0.1 release, please reopen.
oh cool. Sounds like a really neat idea
@river quest Nailed it.
ok folks, congrats, we made an ad together ๐
^5
@slender iron "+5, -441,475 lines: " I know - I did a double-take when I saw the merge. I didn't think ASF4 was THAT big ๐
thanks @formal plover
@river quest You're welcome! That's a solid slogan/ad.
Speaks to what CircuitPython is
โค 
If only there was a code emoji, we could do it all in emojis haha
Just got the notice from Digikey that my 8MB SPI flash chips shipped. Iโll be supersizing a feather M0express this weekend.
@umbral dagger Nice!
@umbral dagger Which ones are they?
Not the cheapest flash, but it's a decent upgrade for the board
@slender iron I don't understand what you mean with the acceleration thing.
it should just be acceleration and return a tuple
the x, y, z = is way to unpack it
In code.py? Or in the API still
I'm missing something fundamental here. I remember going through this concept before and getting the same "bound_method object is not iterable" error. It has something to do with the way lis3dh needs to be called to update the data.
That's how I ended up with the individual properties.
I changed it up and changed up my code.py and that's the error I get. If I tweak it a little, and I print cpx.acceleration it returns <bound_method>
ah, I'm thinking it should be return self._lis3dh.acceleration
ok. Let me try that.
Same error.
Same results with print.
I really think it is related to how it has to be called to update. I tried a bunch of these types of things before I got it to work before.
@property
def acceleration(self):
return self._lis3dh.acceleration
don't forget the @property
I knew I was missing something obvious.
x, y, z = cpx.acceleration
print(x, y, z)```
Works.
That's what you want code.py to look like?
I was worried that would be unclear.
could be cpx.acceleration_xyz if you think that would be more obvious
That part is fine. I meant having x, y, z on their own might be unclear.
that is what I was thinking @idle owl
the x, y, z are up to the user so they can decide to rename it
accel_x, accel_y, accel_z = cpx.acceleration ?
I wouldn't have given it a second thought, but the friend who just got a CPX, I was explaining it to her and x, y, z didn't mean anything to her. She's plenty smart, but I guess not everyone got that far in maths?
thisway, thatway, otherway = cpx.acceleration # whatever you want
Could be an edge case, but that's what got me headed down this path in the first place.
Ok
forward_backward, left_right, up_down = ... (not sure that's right, but I think so
i'd say just keep it .acceleration
The only thing left to fix is the example in Sphinx. I'll test that it builds in Sphinx and then get it up to Github ๐
the fact that's it's the xyz components can just be part of the doc
I need to explain it differently than it is, obviously, but I'll get it sorted.
Thanks guys ๐
as long as we stick with a right handed coord sys. all good. ๐
xyz are the terms used on the board itself
That's a valid point that I knew but hadn't considered.
I even made the image with a red box around it, lol.
I was actually confused by the direction of x, but found out it's standard for navigation. I asked here: https://forums.adafruit.com/viewtopic.php?f=58&t=102426. This help me to understand: https://en.wikipedia.org/wiki/Axes_conventions
ha! i can edit my typos. take that irc!
Space 
related question: what's the approach to make the property read-only? just don't have a .setter defined?
I thought it was underscores. If private == read-only anyway...
I may not understand the question.
@tidal kiln right, no setter
@tulip sleet thanks. the error message you get if you try is a little confusing.
print(thing.x) # works
thing.x = 23 # says there is no property 'x', but i just printed it!?!?!?
Doc design question. If you don't call x, y, z = cpx.acceleration inside a loop, it obtains the data once, and your code follows suit. Should I put in 2 examples? One where you obtain the data once and one where you stream it? They both seem like reasonable beginner use-cases. And given that it's a slightly different setup from any of the other sensors so far, I'm wondeirng how detailed I should be with my explanation. I'm leaning towards very, but I'm always leaning that way when it comes to explaining to beginners.
@tidal kiln that seems like something that should be fixed. In CPython 3:
>>> class C:
... @property
... def p(self):
... return 3
...
>>>
>>> c = C()
>>> c.p
3
>>> c.p = 4
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: can't set attribute
@idle owl I would say that in this case, most of the interesting use cases are detecting changes in orientation, so a loop is a good idea. A simple check is whether is < or > 0, to check orientation.
@tulip sleet indeed. that's better.
@tulip sleet Ok. I'll keep the example I had. I think it works.
@idle owl it will encourage experimentation: "What happens when i tilt the board?"
That's a great way to look at it. I like it. I already had a streaming example, but I thought I would ask.
you can suggest that explicitly: "Try tilting the board in all directions to see what gets printed."
That was the plan. ๐
For ref, here's what it does in circuitpython REPL:
>>> class C:
... @property
... def p(self):
... return 3
...
...
...
>>> c = C()
>>> c.p
3
>>> c.p = 4
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'C' object has no attribute 'p'
@tidal kiln, yeah, that's lousy. I'll look around and see if MPy excuses that behavior somehow. You could file an issue in any case.
@slender iron Ok, updated and pushed.
k, will look in a sec after I finish state taxes ๐
No rush ๐
why not? they rock!
k done
they are easy because they don't take expenses into account
good job @idle owl! https://github.com/adafruit/Adafruit_CircuitPython_CircuitPlayground/pulse
hacktoberfest in a week
@slender iron Thank you! ๐
got your 4 PRs? yeah!
pulse?
It's a Github thing that tracks PRs and commits and all kinds of things. It's under "Insights"
ah. thought maybe the hacktoberfest site had a tracker or something.
Not that I know of. I wasn't sure how they were doing it until Scott explained they just check at the end of the month.
Ah my other PR was to a different repo, that's right.
cool. i'm at.......1! ๐
It was complete coincidence that they chose October. I already had all of these on my list, I was just working my way through.
Trying to finish my Learn Guide now.
๐ โจ ๐ฅ
More reasons to use (Circuit) Python (like we need five more). http://www.popularmechanics.com/technology/a27222/5-reasons-python-should-be-the-first-coding-language-you-learn/
@slender iron I'm merging all the 2.x changes into master. I saw something weird where some combination of -finline-limit -Os -O2 caused some routines to apparently disappear completely. It broke my deinit() checking. I fixed the Makefile to be consistent and the problem went away. I seem to remember you saw something like that??
I didn't mean to end up with -0s -O2 at the same time
no, that was my fault, from a complicated merge. I will not defer merging things so much. There were a number of merge conflicts I had to go through carefully.
anyway, it works well enough in the REPL to blink D13, so my assumption is it's perfect ๐
I remember some frustration you had with -O1, I thought, a week or two again. Maybe it's back in the chat, or maybe I'm misremembering. Not important.
Yes, this was with -Os (by accident) on the m4. I don't see hardfaults, but the calls to my deinit checking routine seem to have been optimized away. That didn't cause a crash, because they were just checks, but I could see that if other small routines were optimized away, bad things would happen.
so I bet it's the same thing.
also went away if i turned off LTO and left -Os (I was just divide-and-conquering the compiler flags)
it might have been with -finline-limit turned on as well
yeah, I feel like I've seen that if all you do is raise an exception
There are multiple commits here because they reflect all the commits to 2.x that are now being added to master. I'd suggest not squashing these because they reflect the true history of the individual changes to 2.x.
that sounds like a good test too. I'll keep an eye out. and there it is โฌ
will look tomorrow
np - I'm pretty much done for today
๐
wow weird @tulip sleet I just had a cplay express erase itself again. i plugged in what i thought was a charged lipo but probably not, now it's NONAME fs.. was running the 2.0 release https://github.com/adafruit/circuitpython/releases/tag/2.0.0 i'll keep this battery around as it might be good to repro with
the code it was running didn't do anything crazy, wasn't even using the lights
and now i'm bummed i lost it lol
didn't have it saved locally
it plays a scream when it detects a big increase in light (x times above standard deviation)
It's always a bummer losing code. I usually remember to save locally for a while and then slowly forget until I lose something again.
@timber lion wow, sorry! I checked in a potential fix if you're interested in building the 2.x branch. I don't know for sure if it would fix it, but the safety feature is something that should be there anyway (don't create a new filesystem if you're in safe mode).
@slender iron heya i haz an audio output Q
shoot @meager fog !
with the sine wave. it works, but how does audioio know the sample rate of the object i passed in
does it assume it is 1 second's worth
digging in the code
there's a frequency on the audio object that defaults to 8k IIRC
yah but if i do this
sample = audioio.AudioOut(board.SPEAKER, sine_wave, frequency=4*SAMPLERATE)
it sounds the same :/
yeah it was a little funky for me too but here's how i did arbitrary tone generation with mega demo
yeah, I don't have the frequency exposed through the constructor
I was thinking I should ๐
it gets a little weird with wav where we do try to get it from the file
@meager fog we have lots of methods that are a little too nice
hmm sample.play(loop=True, frequency=SAMPLERATE) # keep playing the sample over and over
File "main.py", line 24, in <module>
TypeError: extra keyword arguments given
hrm how do you paste code in discord?
i can't paste more than 2k characters it seems
yeah, the constructor is special: https://github.com/adafruit/circuitpython/blob/master/shared-bindings/audioio/AudioOut.c#L96
@timber lion put it in between triple backquotes, like github
if it's a C function it might not validate the keyword args
(shrug) oki np - still not having frequency success when passing it into play()
pastebin?
@slender iron oh yeah thats it, i have to learn how to read the readthedocs
anyways i make a 100 point sine wave and store it, along with the sample that's loaded to play that
ok i will set up my example code to show it off
no worries! its good to know what people expect to work
then when i call start_tone i change the frequency of the sample based on the number of points in the sine wav and desired freq (like 440, 392, etc)
filing an issue about arg checking now
Yeah, you can say this too: `
a = audioio.AudioOut(board.SPEAKER, bytearray(160),foobar=20)
good work @meager fog
well, kinda good work. maybe time to takea break if i cant read ๐
9 hours is more than enough to start melting brains.
thats true @meager fog
yah. don't blue smoke the gray stuff.
That is definitely NOT a recommended way to earn the Sparky pin
this is wortth it...
here's a fun cpx and python trick.. play the wilhelm scream (or any wav) when there's a big increase in light, like if you hid it in a box of candy and open it ๐ https://photos.app.goo.gl/zS6HhskbH3L3lJOu1
cat approves
gist with the files if anyone is curious is here: https://gist.github.com/tdicola/acaecdf855cad75ff3e1a825381af685
hah yeah cat is not impressed by sound ๐
or lack of candy
rats - travis failure; CPX is overflowing flash with the internal frozen modules
Ah, probably because its set up with the internal FS currently.
Python methods can take two type of arguments:
- Positional args that depend on their position in the list and must be given.
- Keyword args are optional and either depend on position or can be identified by their name.
For example, audioio.AudioOut takes two positional arguments, pin and sample_source and no keyword arguments.
In contrast, [AudioOut.play](https://circuit...
Gemma and similar do fit, with plenty of space. Also -finline-limit=19 is causing breakage like I described in chat: some routines seem to have been optimized away. I have turned it off. That's weird, because -finline-limit works fine in 2.x. It may be due to some other CFLAGS changes.
I'll adjust things to disable the CPX frozen modules for now, except for neopixel.
Now that I have an actual, real Adafruit display I can confirm that the CP RGB library flips the Red and Blue channels on the ST7735R library, as written here: https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/issues/5
massive new guide going up now! https://learn.adafruit.com/adafruit-circuit-playground-express?view=all 
To make the image fit on non-Express boards, I set -finline-limit=19. This is too low. It apparently causes some routines to disappear completely with -flto.
One way to check is to see if deinit checking is working. Here is an example of it not working:
>>> import board,digitalio
>>> d = digitalio.Di
DigitalInOut Direction
>>> d = digitalio.DigitalInOut(board.D2)
>>> d.value
False
>>> d.deinit()
>>> d.value
False
The second d.value should throw an exception s...
the blinka emoji kinda looks like the thumbs up emoji.
coincidence? ๐ค
THE PLOT THICKENS!
Dan,
This is very troubling - the use of -finline-limit should only impact code size, not result in lost code. I am not familiar with -lto so I guess I should read up, but how can you be confident that code is not being lost in other cases? Just curious. Am I missing something?
Jerry
@tidal kiln
look like it want to bite you some coding knowledge and helping you to code
@jerryneedell Exactly. No, I expect code may be broken elsewhere.Scott has seen different issues (exceptions were causing hard faults), so we can't tell where code is getting lost: I just have a reproducible example. I will try to figure out exactly what is going on. I am also going to look at removing a few more things from the non-Express builds so we can make them fit without -finline-limit. Another possibility is to reduce the 64k filesystem slightly, but we are reluctant to do that beca...
Confirmation that all my
boards have arrived.
@formal plover Have fun!
@solar whale thanks! Gotta get 2.0 flashed and we'll be ready to rock and roll
All the boards! Insert evil laugh here.
great to hear @formal plover !
I've been working on a sort of side project using the PCA9685, and don't quite understand the use for the pwm function. I get the freq() and duty() functions, but that one escapes me. Can someone help me out with what it does?
@floral dagger I think its so you can set the pulse length in absolute terms
how many microseconds for example
Thanks @slender iron So, do I have this right? It basically ignores the duty cycle and frequency, and just set an on/off duration for the pwm on absolute timings?
It's a bit confusing for sure. Would it be possible to add a basic on/off function to it? I can create it, but would probably need some help with the github stuff, and making sure it's all to spec.
looks like just two different ways of setting the signal: pwm or duty
why not just set the duty cycle to 0 for off?
duty is probably like pwm with on=0
Oh sure, that works, but if you want to say, dim an LED to 50%, then turn it off, and back on at 50%, the user has to work all that out. It just seems more intuitive to say pwmdriver.turnOn(15) or something, and have that duty cycle persist.
that makes sense
this driver needs some love: https://github.com/adafruit/Adafruit_CircuitPython_PCA9685/issues
Looks like it needs a rebase. (Probably after your asf4 PR)
I have a feeling the compiler doesn't understand the mechanic that is used
to raise exceptions. Its pretty tricky so we may want to "poison" the core
function with inline assembly so it doesn't disappear.
On Fri, Oct 13, 2017 at 7:00 AM Dan Halbert notifications@github.com
wrote:
@jerryneedell https://github.com/jerryneedell Exactly. No, I expect
code may be broken elsewhere.Scott has seen different issues (exceptions
were causing hard faults), so we can't tell where code is getti...
btw....what I am working on is a demo for a friend of mine to show how to use circuit python with that module. The idea is that you select the options you want, and then it writes the initialization code below on update. It's just a sort of interactive demo so he can quickly see how the code interacts with the unit. It's still pretty early on, and there's a lot to add. If anyone knows a good code formatter to use that will colorize/hilight syntax, I'm all ears.
I'm seeing "This branch has no conflicts with the base branch" in github, so what makes it look like rebase is needed?
Also, this only works on ESP8266 modules via webrepl at the moment. I want to get it communicationg via com, but that may have to come later
ahhhh...awesome. Thanks @slender iron I was using one I found on google...prettifier or something, but it only seems to work about half the time.
Oh, and I forgot to mention, the project updates the ESP in real time, so you can see the lights change as updates happen
browser
and it's probably something i did in settings
but i can't figure out how to bring it back
I use the Mac app and its ok for me
i did some muting a while back, but from what i can tell, it's all off now
there is a name that I can't think of for the type of structured posts it makes
That's a good point, because the deinit checking function raises an exception. I'll look at that.
I have been looking at trimming the non-Express builds. I can turn off complex floats, which I think nobody will miss, and get back 1576 bytes. With no -finline-limit at all, it's still over by a few hundred bytes. So I could bump -finline-limit back up a lot.
I don't see a lot else to remove immediately. Looking at the final .elf, I see that it includes double-precision float arithmeti...
@tulip sleet you rock! Your compiler investigations make circuitpython way better
and @solar whale is always so helpful on the forums. I went to check it and both questions had already been answered ๐
readelf, nm --print-size and firmware.elf.map have been helpful.
@slender iron thank you, and you are writings tons of great code at great speed!
haha, right ๐
@slender iron is like circuitpython mind with rosie
this usb packet stuff is pretty hacky
do you think their impl is just buggy? Are you trying to figure out how to do CDC better now?
I'm still on my sidequest of importing beagle logs into wireshark
I got the asf code responding to the first MSC request but then hanging after
wireshark will do SCSI decoding for me of the logs while total phase's software won't
i noticed that sometimes if I just leave the REPL idle for several minutes it stops responding
total phase will do it if you pay way more $$; very annoying
Fiddler is good tool too
does fiddler do usb? I thought it was just network
it is network but think if you compine both
@tulip sleet yeah, I refuse to pay for it when wireshark is the goto packet analyzer IMO
and open source
@tulip sleet hve you work a lot with wireshark
yes - i used wrieshark a lot for low-level http debugging (before browser F12 was so good). Then I found it would do USB: even better.
b2dcc5b reset pins on PDMIn deinit(). Fixes #275. - dhalbert
7f74412 Make touch more sensitive. Add .raw_value and .... - dhalbert
c2bb9e2 Add board file for the hacked Trinket M0 Haxpre... - deshipu
c478c10 Do not allow a *io object to be used after dein... - dhalbert
f498167 Add a gamepad module for handling buttons in ... - deshipu
I did a regular merge instead of trying to rebase locall. I won't do that very often but I wanted to preserve the 2.x commits and I had applied all those after the asf4 pr. So not sure why it wasn't rebase-able but not worth spending too much time on.
Ok, no worries! Thanks for doing that.
@idle owl did you see the CPX guide that @meager fog just posted?
@tulip sleet so you could do test write delay stuff
@slender iron I did! I saw it last night!
if you have time and interest would you mind trying to convert hte examples to the library @idle owl ? https://github.com/adafruit/Adafruit_Learning_System_Guides/tree/master/Introducing_CircuitPlaygroundExpress
@slender iron I'd love to!
wow @tulip sleet I just had a CPX erase itself when plugging it in to my computer, no battery attached.. super weird! it's running the 2.0 release too
i wonder if there could be a condition with voltage fluctuating during the plug in?
and ouch i should have backed up the code on that one ๐ฆ
@idle owl cool! how about forking that repo and adding them as alternative files in the same directory?
@timber lion sounds like we need to give you a 2.x branch build
argh man bummer i wonder if atom has a hidden cache of files
@slender iron So just call them something slightly different and upload them as such? Making sure I understand what you're saying.
yup yup!
Ok excellent!
maybe just an extra _cpx
I like it.
thank you very much!
@slender iron I know git clone, but wasn't there something you did differently to make it so it wasn't origin? Or am I thinking of a different step
yeah git clone -o <name> <clone url>
Thank you
np
@timber lion Sorry to hear! I have resorted to editing on the computer and doing cp -r ...;sync as a regular practice
ah yeah it isn't too bad to recreate, yeah i'm going to do the same
super strange though that it wasn't a battery level thing this time
it took me half a second to plug in though so maybe that was making some power noise
i'll try to grab the latest 2.0 later and try it
2.0 branch that is
if you can get it working you could do a video about it
@slender iron It's funny that you asked me to do this. I was looking for something else and stumbled on that repo last night before the Guide was posted, and I was thinking that I should mention the library updates so they could be included.
๐
