circuitpython-dev

[timber mango]

something is clearing the irq

[idle owl]

I don't think I'm running the tip of 2.2, maybe that's the difference.

I need to build it.

[timber mango]

you can grab it from s3

[idle owl]

Oh. much simpler.

[timber mango]

yeah in a bigger demo it does 'lose' taps

[idle owl]

Can I try your code

[timber mango]

yah

doesnt happen in a tight loop

[idle owl]

That's what I figured

[timber mango]

filz

this is latest main

it works most of the time

[idle owl]

Is it the loop? because I'm dropping the threshold significantly and it's not really improving

as in is it the fact that the loop has a lot in it that it's only looking for the tap when it's in that part of the loop so it's missing some?

[timber mango]

yeah

which...shouldnt be happening

[idle owl]

hmm

ooh

ok

here:

[timber mango]

found it

[timber mango]

https://github.com/adafruit/Adafruit_CircuitPython_LIS3DH/blob/master/adafruit_lis3dh.py#L229

[idle owl]

Oh what did you get

[idle owl]

we got the same thing then, really.

I increased time_latency, to keep the click event longer

and it responded much better

the click event was expiring before the loop maybe?

[timber mango]

instead we should just be setting the top bit high

yeah

wanna do a fix? you want to "| 0x80" 😃

only thing is, its frozen

so...a little challeging

[idle owl]

Yeah easy to test though

sort of.

because we might run into memory allocation issues, but we can easily test non-frozen copies by commenting out the prefer-frozen bit in the express.py file

[timber mango]

yah

ok im going to check some samples out, if thats OK?

[idle owl]

I don't know how to build a frozen test build, but @slender iron and @tulip sleet do

sure

[timber mango]

i have great faith in you 😃

the demo is good for testing because it EEPs when it works 😉

[idle owl]

real quick though: where does | 0x80 go in lis3dh

[timber mango]

right here https://github.com/adafruit/Adafruit_CircuitPython_LIS3DH/blob/master/adafruit_lis3dh.py#L229

[idle owl]

I put lights in mine so it would blink 😃

[timber mango]

you want to flip the top bit high

[idle owl]

oh oh I see

maybe

lol

[timber mango]

so "threshold | 0x80"

[idle owl]

I'll figure it out

ok that's what I thought ok

[timber mango]

threshold as is, is only bottom 7 bits. top bit is 'special'

its a little silly they put that config bit there. but they did. so. thats life

[idle owl]

heh true so often

[stuck elbow]

whatever you do to save a few gates

[slender iron]

@timber mango I feel like I tried that and it didn't detect any clicks then

[idle owl]

it does sound familiar.

[slender iron]

its been a little while those since @idle owl and I were playing with it

[idle owl]

I'll try to test it

[timber mango]

hmm could be

we have it set to 8G tho, at 8G you need to have a veru low thresh

[idle owl]

@slender iron once I update it can you teach me how to do a frozen test build? (not sure what you're up to)

[timber mango]

i can also test this on a feather sepatately

[idle owl]

increasing time_latency seemed to fix it @timber mango, so that might be another option

[timber mango]

increasing time_latency will totally do it, but...its a bit of a hack

[slender iron]

to build it into a frozen module you need to edit the file in the submodule of the circuitpython repo

[idle owl]

valid.

[slender iron]

I think the issue we may have seen was missing double taps on fast loops

we were clearing click too quickly to detect double taps

but it may have been a different bug

[timber mango]

bbl

[slender iron]

I'm gonna go climb, will be back in an hour and a half or so

[idle owl]

Ok

[tulip sleet]

me also gone for a while

[idle owl]

ok! see you all later!

[manic glacier]

wolf

[adafruit/circuitpython] Fork created: wolf/circuitpython

[timber mango]

@idle owl k im back, any luck?

[idle owl]

@timber mango still working on sorting git. I get what needs to be done, just getting the last few git steps ironed out. But I'm on it!

[timber mango]

np 😃

[spiral herald]

Hey everyone, Givemelove here. I just received my Circuit Playground Express for Christmas. Looking forward to running some projects on it.

[idle owl]

@spiral herald Welcome! That's exciting! Congrats 😃

[spiral herald]

Thanks @idle owl , i'm pretty excited. Going through the tutorial for now. Seems a lot more straightforward than Arduino

[idle owl]

That's what I've found to be the case!

[idle owl]

@timber mango I got it built with the change in. Now I'm tweaking all the values again because it's back to being entirely too sensitive for single-tap.

@timber mango But testing with double-tap and it doesn't work.

Both in the demo code and in a tight loop.

[slender iron]

I'm back

[idle owl]

Hiya

I think I managed to get the right thing to build. And it does still fail on double-tap.

[slender iron]

kk

[meager fog]

weird

[idle owl]

yah.

[meager fog]

i mean, i would rather get this Right

[idle owl]

I'm currently tweaking latency anyway.

[meager fog]

i can play around with a feather version, so not freezing

[idle owl]

Yah agreed

Ah ok

I can set it up too

[meager fog]

blah wont fit - let me move to m4

[idle owl]

@slender iron Is there anything that needs to be tested with the cookiecutter travis change?

[slender iron]

the overload one?

er, overwrite

[idle owl]

yeah

[slender iron]

nah, I think I enabled it in one repo already

[idle owl]

ok

Do we need to do a release or anything after merging?

[tulip sleet]

@idle owl are you making possible changes to the LIS3DH library, or only the CircuitPlayground library? I have a PR for updating the CPX frozen modules, but happy to wait if you're still working on the library.

[idle owl]

@tulip sleet Possible to LIS3DH

[tulip sleet]

k, so I'll wait

[idle owl]

ok keen 😃

[meager fog]

oof getting USB MSD disappearances on M4 - odd i never got them before

[idle owl]

oi

[meager fog]

making progrss tho

[idle owl]

nice!

[tulip sleet]

@meager fog jerryn saw probs with M4 build on latest gcc 7 toolchain. My guess is that new optimizations uncovered latent bug

[meager fog]

yah

when i save main.py the python runtime is good, but the MSD dies

and it erases main.py

[tulip sleet]

i can build you one with the old toolchain if you need it

[meager fog]

@idle owl whats your test code for single/doubel tap testing with the | 0x80 line?

im going in a few mins but i think it ought to be working?

[idle owl]

It was written for CPX, you're using lis3dh right?

[meager fog]

yeah directly

@tulip sleet what was the last 'good' release? 😃 ill just use that

[tulip sleet]

eh, we haven't made a "master" release in a while, you mean from AWS? Not even sure they're there

[meager fog]

yeah its from 15th

could be something else :/

[idle owl]

I think this is the code we used, but I don't remember what iteration this was:

    last_tap = False
    tap = lis3dh.tapped
    if tap and not last_tap:
        print("tapped!")
        pixels.fill((30, 0, 0))
    else:
        pixels.fill((0, 0, 0))
    last_tap = tap```

can't use pixels because that was CPX specific, but you get the idea

[tulip sleet]

here's a rebuild of the tip of master with gcc6 (2017q2 toolchain)

.bin version

[idle owl]

@meager fog ```python
import adafruit_lis3dh
import busio
import board

i2c = busio.I2C(board.SCL, board.SDA)
lis3dh = adafruit_lis3dh.LIS3DH_I2C(i2c)
lis3dh.range = adafruit_lis3dh.RANGE_8_G

lis3dh.set_tap(1, 20, time_limit=4, time_latency=17, time_window=150)
last_tap = False

while True:
tap = lis3dh.tapped
if tap and not last_tap:
print("tapped!")
last_tap = tap```

I'm having issues making it work, but I'm not yet convinced it's not something else.

Such as how I'm trying to tap the breakout. (it's mostly working now)

I edited the code snippet. Moved last_tap = False outside the loop. It spams the serial output if it's inside.

Even single-tap doesn't work very well with the config change to the driver on the breakout board.

[manic glacier]

develone

[adafruit/circuitpython] Fork created: develone/circuitpython

[meager fog]

@idle owl im just not getting the last_tap thing

something is weird

and my m4 keeps borking on me 😦

[idle owl]

hmm.

I did it using a feather and .mpy'd the file

but I have no idea what else to try changing in the driver to make the threshold change work

I can't remember why we did it that way. with last_tap. something about keeping it from spamming the serial? Or keep it from mistaking taps for double-tapping? maybe that was specific to doubletap but not needed for single.

Yeah, even single tap without it spams the serial. I think it has something to do with how it lis3dh uses the buffer

[meager fog]

i remember when i wrote this code in c it totally sucked 😄

and it wasnt documented at all

[idle owl]

always helpful

[meager fog]

im going to do more research, will work more onit tomorrow

[idle owl]

Ok sounds good. I'm heading out for the night

[timber mango]

ansi.sys style color escapes:
https://github.com/wa1tnr/cpx-basic-studies/blob/master/141-print.d/color_print_demo.py

[manic glacier]

akatrevorjay

[adafruit/circuitpython] New star added

[manic glacier]

microbuilder

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

@tannewt It looks like I only need to edit build_adafruit_bins.sh since there is only one build target we are testing against for now, but let me know if I missed something? See: https://github.com/adafruit/circuitpython/pull/496/commits/f1e1699c9f74e5aefdc6488c60daca52c8cd15bc

[slender iron]

@meager fog @timber mango @idle owl the last_tap thing ensures the cpx's tapped only returns once per tap. The lis3dh bit is potentially held high over multiple reads for the same tap because the "clear on read" bit is off

[manic glacier]

tannewt

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

@microbuilder I think that only runs it off Travis builds. The ESP8266 isn't built on travis because the toolchain isn't available on Travis.

You'll want to add a TRAVIS_BOARD here for it: https://github.com/adafruit/circuitpython/blob/master/.travis.yml#L15

That list makes the checks run in parallel and speeds up the build.

tannewt

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

// LED for standard examples Abbreviated versions like this makes it harder to read.

[idle owl]

@slender iron I was close 😄

Thanks for clarifying!

[slender iron]

np 😃

[meager fog]

@idle owl @slender iron yah but...it shouldnt if we set the high bit... so lets do that?

@idle owl i have a few things to do today for show, but will get back to this tnoite

[slender iron]

setting the high bit breaks double tap detection when you read it back quickly I believe

[idle owl]

@meager fog ok sounds good

[meager fog]

i didnt see that, double tap seems to work ok for me? :/

lis3dh.set_tap(2, 50, time_limit=10, time_latency=50, time_window=255)

Loop forever printing accelerometer values

while True:
# Read accelerometer values (in m / s ^ 2). Returns a 3-tuple of x, y,
# z axis values.
#x, y, z = lis3dh.acceleration
#print('x = %0.2f \t y = %0.2f \t z = %0.2f' % (x / 9.806, y / 9.806, z / 9.806))d
# Small delay to keep things responsive but give time for interrupt processing.
if lis3dh.tapped:
print("Tapped!", time.monotonic())
time.sleep(0.5)

[slender iron]

@meager fog did you try it with the top bit of the threshold register set?

[meager fog]

yah

self._write_register_byte(REG_CLICKTHS, threshold | 0x80)

mYsTeRy

[slender iron]

ah then we must have had a different bug

[meager fog]

i think yah maybe...

[idle owl]

hmm

So... that's weird.

Ok now double-tap sort of works. With ladyada's code and with the top bit set.

[slender iron]

and no last tap?

[idle owl]

Yeah.

O.o

No spamming the serial output either.

Finger stings. Successfully tapping a breakout on a breadboard is more difficult than it should be. 😄

[meager fog]

@slender iron yeah i didnt need last-tap code either

you do have to be careul with setting the params

[idle owl]

When it was spamming without last_tap, params didn't matter

[idle owl]

And it was consistently spamming the same number of times

Yeah

[meager fog]

i think that was something else

[slender iron]

yup yup

[meager fog]

i used this "lis3dh.set_tap(2, 50, time_limit=10, time_latency=50, time_window=255)"

[slender iron]

I'm happy for it to change since you two refined it

[meager fog]

(shrug)

😃

[idle owl]

I copied your code exactly

And it seems to be working.

[meager fog]

ok kattni if you want to tweak both lis3 and cpx and commit, ill test it but i guess we have to rebuild the cpx firmware since its frozed?

[idle owl]

But it doesn't yet explain it failing to work on CPX. I'll change up the params in express and load the test-build I made last night

I already have a test build with the 80 changed

So I can test it before we start committing

[meager fog]

k yeah i only tried it on a bb

[idle owl]

Still no double-tap on cpx.

[meager fog]

does it work on a lis3dh + BB?

[idle owl]

yes.

I just managed to get one double-tap as I set it down. But I even changed the thresdhold to 5 in express (should be spamming), and it's still not double-tapping on the CPX. If I leave it sit here without touching it, every so often, it will blink and say tapped. (tested it with your demo, now testing it without)

Issue with different thresholds being needed is back with this though: at 50 single is super-touchy with your demo, goes off all the time. So once this is sorted, we may have to go back to 80 or whatever ends up working for both.

Sanity check: yes still works on the lis3dh breakout with a feather m0 express.

...

hold up.

Ok here's some fun to add to the mystery. It works with different code.

Intermittently. But more than not at all.

It's the time.sleep

Without it, double-tap fails. But if you put it in the loop and outside the if/else (like in your test code), it works.

[meager fog]

its because we're querying too fast

[slender iron]

thats my theory

[meager fog]

so it doesnt have time to get the second tap

[idle owl]

Ok.... so doesn't tweaking the other params resolve that? Or is that a limitation of the hardware and we're required to have time.sleep in any code using double-tap?

I can test it if we're not sure

explains why your tests worked and ours didn't though....

So at least that mystery seems to be solved.

oi.

breakout fails without time.sleep! 😄

Ok so I'm ratcheting down the params in express class. To make the single-tap less touchy, and testing double-tap as I go.

[manic glacier]

microbuilder

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

It's always a tradeoff since wanting to stick to 80 chars wide, and abbreviation, but if you prefer to run over I'll update this.

tannewt

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

Running over or placing the comment above is fine.

[slender iron]

@meager fog is the functionality of the TB6612 generic or should I make a driver specific to it?

[idle owl]

Params in express are tightened up. Works with tight loop and with the shipping demo code. Threshold is higher than it was. Double-tap is responsive but you have to time right, and it's obviously a little less responsive due to the time.sleep.

So include that in the docs I suppose? Going to be 3 examples for that one in that case.

[slender iron]

yup to you, I'm headed to the gym

[idle owl]

Ok.

I'm going to merge the current PR and do it locally.

[slender iron]

k

[timber mango]

@slender iron heya back, for TB6612 and such, we should make a Stepper library, like arduino has

but since we have loose types, we can just pass in pin objects

https://www.arduino.cc/en/Reference/Stepper

~ideally~ if we do it right, we should be able to pass in port expanders, etc 😃

i can make the library if ya like

@idle owl did ya figure stuff out?

[idle owl]

@timber mango Yeah!

[timber mango]

yay thank you for helping 😄

[idle owl]

I'm making the change to lis3dh right now, and will do a PR for that. Then I'll merge your PR and do the rest of the changes locally and do another PR for express

Thanks for helping too! That was a group effort for sure. I'd have been staring at it for a bunch more days

I tightened up the params in express so you can handle the board and not have it going off constantly with the demo code running

[timber mango]

yah

ok let me know if/when you want me to test

i can pop it onto my cpx

[idle owl]

I can send it to you now if you have a couple of minutes. I have a test build with it in there and an express.mpy

[timber mango]

yeah

now is good!

[idle owl]

Ok!

[timber mango]

ntense

ok

[idle owl]

(pretty proud of that uf2 😃 )

[timber mango]

ok loaded

toss me your tests

[idle owl]

Mm right, lol. Sorry

That's the two sound files and the demo and a code.py that's currently named 1code.py so main.py would run

[timber mango]

ok single tap works for sure

double tap also?

[idle owl]

Yep! Needs a time.sleep(0.4) or higher

I added it into your demo, slows down the rainbow, but it was good for testing

Also works in the code.py

[timber mango]

hm not triggering for me

[idle owl]

hmm.

[timber mango]

(double)

let me simplifiy the tst

[idle owl]

updated for double_tap

Works for me in that...

Timing maybe? I left the time_window 255.

highest it can be afaik.

[timber mango]

can you tell me the new express settings

[idle owl]

yep

[timber mango]

_lis3dh.set_tap(1, 10, time_limit=10, time_latency=50, time_window=255)

(etc)

[idle owl]

lis3dh.set_tap(value, 90, time_limit=2, time_latency=50, time_window=255)

I tightened up time_limit because otherwise single_tap goes off when the board is moved around, keeps it from triggering when you shake the board.

Do you want express.py?

[timber mango]

nah

noodlin

[idle owl]

ok figured i'd check

Just checked it again to make sure I had the most updated express.mpy, and it's still working for me in the demo code. 😕

[stuck elbow]

@pastel panther what oscillator are you using on your board?

[timber mango]

ok so

[idle owl]

yah

[timber mango]

@idle owl @slender iron i made it so its betternow

because we keep clearing the register when we read

the Right Way is to use IRQ

[idle owl]

yeah

[timber mango]

irq = DigitalInOut(board.ACCELEROMETER_INTERRUPT)
irq.direction = Direction.INPUT
irq.pull = Pull.UP

while True:
# Read accelerometer values (in m / s ^ 2). Returns a 3-tuple of x, y,
# z axis values.
#x, y, z = lis3dh.acceleration
#print('x = %0.2f \t y = %0.2f \t z = %0.2f' % (x / 9.806, y / 9.806, z / 9.806))d
# Small delay to keep things responsive but give time for interrupt processing.
if irq.value:
if cpx._lis3dh.tapped:
print("Tapped!", time.monotonic())

this way it doesnt matter if you query too soon

[idle owl]

ok... so does that go into express then?

[timber mango]

(thinking)

yes

well

yes - we should check the irq first

thinks hard

it could also go into lis3dh

but there's a chance that they didnt set up the lis3dh for irq-on-tap

whereas we do for sure with cpx

[idle owl]

ok

@tulip sleet hold up a sec on updating the frozen module.

[timber mango]

but on the other hand, we will not allow the pin to be exposed

let me check the DS, we may have to update lis3dh

[idle owl]

seems like it can be worked into express class though

ok

[timber mango]

actually, sorry, we should do it in lis3dh

[idle owl]

ok

[timber mango]

if thats ok, thats the best place for it

this line https://github.com/adafruit/Adafruit_CircuitPython_LIS3DH/blob/master/adafruit_lis3dh.py#L189

[idle owl]

Should be fine, I haven't gotten a notification that Dan's done the update yet.

[timber mango]

read INT1_SRC (reg 0x31)

and look if the value & 0x40 > 0

if so, THEN read CLICKSRC

[tulip sleet]

@idle owl I just did a release of the library (which was probably premature), but I am waiting on your finishing the debugging before doing anything in adafruit/circuitpython

[idle owl]

@timber mango I'm not sure I follow what that will end up looking like. I have it pulled up, but I don't get how to translate from the concept to the actual code 😖

@tulip sleet Ok I'll let you know

[timber mango]

ok start here

https://github.com/adafruit/Adafruit_CircuitPython_LIS3DH/blob/master/adafruit_lis3dh.py#L29

make a new register called REG_INT1SRC

[idle owl]

ok

[timber mango]

value is 0x31

[idle owl]

then read_register_byte(theoneIjustmade) ?

[timber mango]

yep here

https://github.com/adafruit/Adafruit_CircuitPython_LIS3DH/blob/master/adafruit_lis3dh.py#L189

read the raw value

then you want to test that this bit is set

0 = no interrupt, 1 = yes interrupt!

it is the 7'th bit in, so thats 0x40 hex

(1 << 7) == 0x40

if (raw & 0x40): interrupt is set, so now check that the interrupt is from CLICK

[idle owl]

        self._read_register_byte(REG_INT1SRC)
        raw = self._read_register_byte(REG_CLICKSRC)
        if raw & 0x40 > 0:
            return raw & 0x40

?

no

wrong order

That?

It's not interacting with the INT1SRC though I don't think. What I just wrote I mean.

So I don't think it's right.

[timber mango]

you have to save that register read, it gives you back the byte

raw = self._read_register_byte(REG_INT1SRC)

then you can test it

does that make sense? registers are a bit of a stretch the first time u use them

[idle owl]

sort of.

[timber mango]

its data, but its representing the hardware

[idle owl]

        if raw & 0x40 > 0:
            click_raw = self._read_register_byte(REG_CLICKSRC)
            if click_raw & 0x40 > 0:
                return raw & 0x40```

[timber mango]

the number you get back has bits set that tell you what the chip has stored in it

[idle owl]

?

[timber mango]

yah

like t hat

[idle owl]

ok I guess it makes more than sort of sense 😄

[timber mango]

when you read a register, sometimes it clears it

thats why we have to do 2 checks - because if we clear it too early, by reading, then the lis3dh is like "that first click never happend"

[idle owl]

so this should eliminate the need for time.sleep?

hmm how to test this...

because I don't know what accel_interrupt would be on a feather.

owait it only uses frozen if we're using cpx. oi.

[timber mango]

yah you dont need time.sleep

oh you dont need the accel_int anymore

you should be able to just call tapped()

i sorta did a workaround. the IRQ pin is 'elegant' but not really needed for us.

(since, we dont have interrupt support in cpy anyhow)

[idle owl]

so this is what I have, it runs but it's not working:

import digitalio
import adafruit_lis3dh
import busio
import board

i2c = busio.I2C(board.ACCELEROMETER_SCL, board.ACCELEROMETER_SDA)
lis3dh = adafruit_lis3dh.LIS3DH_I2C(i2c, address=0x19)
lis3dh.range = adafruit_lis3dh.RANGE_8_G

irq = digitalio.DigitalInOut(board.ACCELEROMETER_INTERRUPT)
irq.direction = digitalio.Direction.INPUT
irq.pull = digitalio.Pull.UP

lis3dh.set_tap(1, 20, time_limit=2, time_latency=50, time_window=255)
while True:
    if irq.value:
        if lis3dh.tapped:
            print("Tapped!", time.monotonic())```

this is on a CPX.

[timber mango]

with t he new compiled lis3dh code?

[idle owl]

Yeah.

[timber mango]

ok ill look after the show

i have to get ready n ow 😃

[idle owl]

I'll do it again to make sure

np 😃

[stuck elbow]

so I figured out why the stlink flashing wasn't reliable

it's related to the fact that it uses its own 3.3V signals, and that's sometimes a little bit different voltage than the microcontroller gets from the ldo

if I power the microcontroller from the stlink directly, it flashes flawlessly

[idle owl]

good catch

[stuck elbow]

the jlink doesn't have that problem, because it always uses the target's voltage

[manic glacier]

dhalbert

[adafruit/circuitpython] New comment on issue #500: Metro\-M4 problems with gcc 7\.2\.1

I kept pruning the program back. The problem appears to be much more fundamental, and appears to have to do with storage allocation or garbage collection. This program hangs around i=479:

for i in range(10000):
    print(i)
    l = [0]*50

Interestingly, it doesn't fail in the repl, but does fail if named as, say gcc7crash.py and then I do import gcc7crash. Don't make it main.py: it will crash before you get to the REPL, and CIRCUITPY will be nonfunctional quickly. I had ...

tannewt

[adafruit/circuitpython] New comment on issue #500: Metro\-M4 problems with gcc 7\.2\.1

Have you tried this with a debugger hooked up to see where it is in C land?

[slender iron]

@idle owl I understand what @timber mango was going for if you need more help

[idle owl]

@slender iron I do. I have code that runs but it's not working.

[slender iron]

ok can you post what you have?

[idle owl]

In adafruit_lis3dh: python @property def tapped(self): """True if a tap was detected recently. Whether its a single tap or double tap is determined by the tap param on `set_tap`. This may be True over multiple reads even if only a single tap or single double tap occurred.""" raw = self._read_register_byte(REG_INT1SRC) if raw & 0x40 > 0: click_raw = self._read_register_byte(REG_CLICKSRC) if click_raw & 0x40 > 0: return raw & 0x40

In code.py: ```python
import digitalio
import adafruit_lis3dh
import busio
import board
import time

i2c = busio.I2C(board.ACCELEROMETER_SCL, board.ACCELEROMETER_SDA)
lis3dh = adafruit_lis3dh.LIS3DH_I2C(i2c, address=0x19)
lis3dh.range = adafruit_lis3dh.RANGE_8_G

irq = digitalio.DigitalInOut(board.ACCELEROMETER_INTERRUPT)
irq.direction = digitalio.Direction.INPUT
irq.pull = digitalio.Pull.UP

lis3dh.set_tap(1, 20, time_limit=10, time_latency=50, time_window=255)

while True:
if irq.value:
if lis3dh.tapped:
print("Tapped!", time.monotonic())```

Oh and this in lis3dh: REG_INT1SRC = const(0x31)

[slender iron]

in code.py you shouldn't need the irq pin anymore

[idle owl]

ok. I tried that too and it still didn't work. I'll remove it

[slender iron]

yeah, I think there is some config to do to make INT1 == the CLICK_SRC IA

[manic glacier]

dhalbert

[adafruit/circuitpython] New comment on issue #500: Metro\-M4 problems with gcc 7\.2\.1

going to do that - just wanted to redirect where to look. It's doesn't seem like it's IO or USB or something like that. I have a feeling it's something that got optimized out or misplaced even though it's "asm"d or something like that.

[idle owl]

ok

in lis3dh you mean

[manic glacier]

tannewt

[adafruit/circuitpython] New comment on issue #500: Metro\-M4 problems with gcc 7\.2\.1

Yup, thats my feeling too. I'll assign to you.

[slender iron]

ya

unless the default state makes sense

[idle owl]

not sure what you mean

[slender iron]

we may not have to configure anything is its configured correctly by default

[idle owl]

ah

[slender iron]

ah ha!

CTRL_REG3 has a click interrupt on INT1 bit thats disabled by default

[idle owl]

ah!

[slender iron]

(section 8.10 in the data sheet)

[idle owl]

0: default, 1: enable

[slender iron]

know how to set it?

[idle owl]

hmm. write_register_byte(REG_CTRL3, 0x80) ?

[slender iron]

yup, theres a similar line in the init already that I think you can replace

[idle owl]

Ah. change 0x10 to 0x80

so just in init? or in tapped too?

because I'm still not getting any response from the cpx.

Or on a feather with a breakout.

[slender iron]

@idle owl just in init

[idle owl]

should it still be in set_tap then?

[slender iron]

should what be?

[idle owl]

self._write_register_byte(REG_CTRL3, 0x80) # Turn on int1 click.

[slender iron]

oh no, I didn't know it was in set_tap already

[idle owl]

oh. yah

this both: self._write_register_byte(REG_CTRL3, 0x80) # Turn on int1 click. self._write_register_byte(REG_CTRL5, 0x08) # Latch interrupt on int1.

[slender iron]

ah

seems like it should work then

I'm not convinced the INT1 register == INT1 pin

[idle owl]

I think I had something wrong, but I changed it and it didn't fix it: python if raw & 0x40 > 0: click_raw = self._read_register_byte(REG_CLICKSRC) if click_raw & 0x40 > 0: return click_raw & 0x40 ^^ I had return raw & 0x40

ah. that would mean we're not really calling the interrupt pin?

[slender iron]

yeah, we're not exactly reading the pin state

I think the INT1 registers would be better named IA1 and IA2 to match the bits in CTRL_REG3

[idle owl]

how's that work

[slender iron]

I don't think we can read INT1_SRC as a proxy for CLICK_SRC

[idle owl]

ah

[slender iron]

INT1_SRC only pertains too the inertial interrupts like free fall

[idle owl]

why does CTRL_REG3 call it "CLICK interrupt on INT1"?

[slender iron]

I think because INT1 is ambiguous

[idle owl]

ah

[slender iron]

in that case they mean the pin, not the registers

[idle owl]

ohhhh.

[slender iron]

because REG3 also has IA1 and IA2 on INT1

[idle owl]

I see that

[slender iron]

which match the INT1 and INT2 register sets

[idle owl]

ah ok

so is there any way to do what she was going for?

[slender iron]

you could read the actual pin state

[idle owl]

the INT1 pin?

also should I set init back to what it was?

[slender iron]

ya, I don't think it'll do what we want

[idle owl]

ok

[slender iron]

I think we'll need some more @timber mango time to sort out what she wants

[idle owl]

ok

[slender iron]

was the issue that double taps are missed when a sleep waits a while in the loop?

[idle owl]

It was a combination of that and the fact that we needed time.sleep at all, I think

double taps weren't working for her, they were working for me with a sleep in the code

so she went on a hunt

[slender iron]

if the LIR bit is off we don't need sleep then though

[idle owl]

did we do that? Or does that need to be done still

[slender iron]

I believe it was just turned on

thats the 0x80 | threshold thing

[idle owl]

oh.

hmm.

then the time_latency needed to be higher I think, and that's a workaround, and she wanted to do it right, so that's what started all of this.

[slender iron]

yup, its tricky

the latching is weird because ideally it should effect the latency detection for double tap

[idle owl]

so is trying to read the pin state directly a path worth heading down?

I have help.

[slender iron]

yeah, thats the only way I can think of getting what she expects

[idle owl]

ok

keen

I'll work on that for bit

[errant grail]

Digi-Key and Adafruit orders arrived yesterday. The CPy StringCar PCBs arrived today, ahead of schedule! Assembly starts after AaE tonight. May have to brave the snow storm tomorrow for final testing.

[slender iron]

@errant grail are you going to show it on show and tell?

[errant grail]

@slender iron Not tonight. Perhaps sometime after testing.

[slender iron]

but PCBs are fun to look at!

[errant grail]

I think so too. Designing PCBs is almost as much fun as soldering!

[slender iron]

yeah totally!

[errant grail]

The area to the right of the two StringCar boards is for a special retro-ish USB power monitor I've been working on. Perhaps that will make it to S&T before the StringCar stuff, we'll see.

[slender iron]

cool cool

[errant grail]

< PCB project endorphins >

[umbral dagger]

Is or has anyone worked on a LSM303 (e.g. the Flora accel/mag board, https://www.adafruit.com/product/1247) driver fir CP?

[idle owl]

Pin state read implemented!

[slender iron]

nice!

[timber mango]

@umbral dagger not yet!

@slender iron @idle owl hiya thanks for patience, i am about to eat food

i see we use the INT1 for two purposes?

[idle owl]

yeah but not INT1SRC

[timber mango]

can we use INT2 for tap, INT1 for 'other'?

[idle owl]

I don't know if INT2 is even there

[timber mango]

i think there's two ints

[idle owl]

I don't think it's connected to anything

there is a pin on the chip

not on the CPX for sure

[timber mango]

chip has both, but i think hardware wise we only connect one

yknow, its probably best we just use the pin

[idle owl]

I implemented the irq read into lis3dh

[timber mango]

this darn chip does tooo much!

[idle owl]

I tested it with lis3dh directly, I'm currently making a test build for CPX so we can try it with express class

[timber mango]

so what do we want to do

or rather, what isnt working still 😃

[idle owl]

Ok, we don't have to do what I did, but Scott thought that reading the pin state directly was the only way to do what it was you were trying to do, so I figured I'd try to do it

and did

Everything works at the moment. 😃

Haven't tested with express class yet, but lis3dh works with pin state read implemented

And error checking if someone doesn't pass in the irq_pin, so if they don't have it connected, they can still do single_tap but not double_tap because that was the error we were having to begin with, and the only way around it is time.sleep etc etc etc etc

(went in a circle)

Want my test stuff?

at least the lis3dh anyway

Works for me anyway

mmm. test build fails with the CPX demo code though. Time to sort why.

[umbral dagger]

@timber mango OK, I've started fiddling with converting the C code.

@timber mango Sneak peek at a project:

[idle owl]

So amendement to earlier statement: the demo code isn't currently working with express class with the changes to lis3dh.

[timber mango]

@umbral dagger cool! check out our 'how to port libraries' guide 😃

@idle owl i have to eat now, sorry 😦

[idle owl]

@timber mango ok np

I was just updating. no rush

[umbral dagger]

@timber mango I appear to have the Flora lsm303 sensor working in CP (on a Feather M0 Express).

[idle owl]

@meager fog Status: I have the irq pin state read working on the breakout, and on the CPX not using express class. My test frozen module build fails on the demo code for express class with pin PA13 is in use. I don't know what else is using it in Express, or if the issue is pervasive to lis3dh and it's a fluke that it works directly. I need to head out for the night. I'll see when you're around tomorrow.

[cunning seal]

Is there a place where to find the Bossa desktop tool compiled ? The one I use from Shumatec keep crashing on my Mac

[stuck elbow]

https://github.com/shumatech/BOSSA/releases

there are some compiled binaries there

also, I think it ships inside Arduino, so you might be able to use that one

[cunning seal]

@stuck elbow thats the one I am using but it keep crashing. I need the desktop version not the command because I need my customer to update code with a simple app from their desktop

Bossa has been forked many time but I can't compile the fork myself

So I am looking for a stable desktop wrapper for the bossac

I made one with Processing that works on my Mac but I have trouble porting it to Windows

So maybe the solution is already available somewhere ?

Here is my Processing wrapper : http://www.polaxis.be/bossa-uploader/

[stuck elbow]

I didn't even know there were gui versions

[cunning seal]

@stuck elbow Yep I knew this wasn't exactly the right place to ask 😩

[stuck elbow]

sorry

[manic glacier]

gregworley

[adafruit/circuitpython] New star added

[solar whale]

hmmm - I am playimg with an SI7021 sensor. On my metro M0_express, it works under CP 2.x but not under 3.0 .... error message under 3.0 ```Adafruit CircuitPython 3.0.0-alpha.1-16-g36ec29d on 2017-12-23; Adafruit Metro M0 Express with samd21g18

import si7021_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "si7021_test.py", line 8, in <module>
File "adafruit_si7021.py", line 79, in init
File "adafruit_si7021.py", line 79, in init
File "adafruit_si7021.py", line 75, in init
File "adafruit_si7021.py", line 74, in init
File "adafruit_bus_device/i2c_device.py", line 94, in write
OSError: 5

This was using the 20171223 Bundle.

[stuck elbow]

does the i2c.scan show it?

[solar whale]

yes 64 = 0x40 ```Adafruit CircuitPython 3.0.0-alpha.1-16-g36ec29d on 2017-12-23; Adafruit Metro M0 Express with samd21g18

from board import SCL,SDA
from busio import I2C
import adafruit_si7021
import time
i2c=I2C(SCL,SDA)
i2c.try_lock()
True
i2c.scan()
[64, 104]

[stuck elbow]

I don't suppose you have a logic analyzer handy?

[solar whale]

yes I do - just a sec - will post a picture

si7021

last comm

[stuck elbow]

can you upload the capture file?

[solar whale]

si7021_error

[stuck elbow]

awesome

[solar whale]

FYI - it failed on the Metro_M4 and nrf52 board as well.

[stuck elbow]

why is it trying to write to 0x80? that's not a valid i2c address

[solar whale]

hmm - sounds like a shifted 0x40

[stuck elbow]

ah, ok, 7-bit versus 8-bit addressing, I guess

is that empty write your i2c.scan?

[solar whale]

no - this wa just the init

[stuck elbow]

ah, no, it's the i2c_bus checking if the device exists

can you compare that to a working session?

[tulip sleet]

Line #74 in the backtrace is i2c.write(data, stop=False). stop=False is unusual

[solar whale]

from busio import I2C
import adafruit_si7021
import time


i2c=I2C(SCL,SDA)
sensor=adafruit_si7021.SI7021(i2c)
while True:
  print(sensor.temperature,sensor.relative_humidity)
  time.sleep(1)

[stuck elbow]

@tulip sleet why is it unusual?

[solar whale]

@stuck elbow sure - it'll take a few minutes to reconfigure for 2.x

[tulip sleet]

not always used: not THAT unuusual, but might be something wrong with the 3.0 impl

[stuck elbow]

@tulip sleet it's a common pattern in i2c reads -- you send the register number, and then you switch to reading and read the value

every single driver uses that

@tulip sleet what is unusual is that line is inside a try-except that should catch that OSError

@tulip sleet but for some reason it doesn't

ah, I see, it expects OSError 19 but it's giving it OSError 5 instead

the error is expected, because the sensor is resetting

[tulip sleet]

19 is MP_ENODEV; 5 is MP_EIO

[tulip sleet]

19 is thrown only if it's an I2C_ERR_BAD_ADDRESS

[stuck elbow]

so the problem is that 3.0 returns MP_EIO instead of MP_ENODEV when the device doesn't respond to a write request

[tulip sleet]

yeah, lemme check the 2.x code

maybe

[solar whale]

Ah - that makes sense

[stuck elbow]

I wish MicroPython would finally define, document and freeze its API

and document api changes like this

[tulip sleet]

the code is essentially the same in 2.x and 3.0, but the lower level ASF3 vs ASF4 libraries may be returning diff values

maybe see how other libraries handle this; perhaps it's being too picky

[stuck elbow]

well, we can always add 5 to that list of expected error values

but I would hate to catch and ignore unexpected errors

[tulip sleet]

MP_EIO makes more sense, because the device is there, I think

[stuck elbow]

you can't tell

you would get exactly the same behavior if it was disconnected

the clock line remains high

[tulip sleet]

i wonder if 3.0 ever returns 19 in any circumstances

looking...

[stuck elbow]

I think we have some code that assumes error 19 in the i2c bus device

[solar whale]

don't know if it is meaning ful but the nrf52 say it can't find the device. ```Adafruit CircuitPython 3.0.0-alpha.1-29-ga14bfeb-dirty on 2017-12-23; Bluefruit nRF52 Feather with NRF52832

impost si701_test
Traceback (most recent call last):
File "<stdin>"
SyntaxError: invalid syntax
import si7021_test
Traceback (most recent call last):
File "<stdin>", in <module>
File "si7021_test.py", in <module>
File "adafruit_si7021.py", in init
File "/home/travis/build/adafruit/Adafruit_CircuitPython_Bundle/libraries/helpers/bus_device/adafruit_bus_device/i2c_device.py", in init
File "/home/travis/build/adafruit/Adafruit_CircuitPython_Bundle/libraries/helpers/bus_device/adafruit_bus_device/i2c_device.py", in init
ValueError: No I2C device at address: 40

[stuck elbow]

ah, no, it just catches all OSErrors

[tulip sleet]

in ASF4:

    uint16_t status = hri_sercomi2cm_read_STATUS_reg(hw);

    if (flags & MB_FLAG) {
        /* tx error */
        if (status & SERCOM_I2CM_STATUS_ARBLOST) {
            hri_sercomi2cm_clear_interrupt_MB_bit(hw);
            msg->flags |= I2C_M_FAIL;
            msg->flags &= ~I2C_M_BUSY;

            if (status & SERCOM_I2CM_STATUS_BUSERR) {
                return I2C_ERR_BUS;
            }

            return I2C_ERR_BAD_ADDRESS;

[stuck elbow]

https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/blob/master/adafruit_bus_device/i2c_device.py#L65

[tulip sleet]

not sure when BUSERR is NOT set; have to look on the datasheet

[stuck elbow]

I wonder if just catching all OSErrors there would be the right thing — personally I cringe a bit, because that's hiding errors, but it would surely be more robust against such api changes, and if it's an actual error, it will fail later anyways

@solar whale that ValueError definitely looks wrong

[tulip sleet]

BUSERR is protocol violation or timeout. But ASF3 is checking for RXNACK, not BUSERR. Does a timeout give RXNACK

in ASF3, RXNACK gives BAD_ADDRESS.

[stuck elbow]

%-)

[tulip sleet]

yes 😃

[solar whale]

@stuck elbow yes - lets defer the nrf52 until the M0/M4 issues get resolved....

[tulip sleet]

in ASF4, RXNACK just returns a NACK error code

so ASF3 and ASF4 are not consistent on the error codes they return. I think I will browse through other CPy drivers and see if they're so specific

[solar whale]

@tulip sleet @stuck elbow thanks for the quick response and debugging. I opened an issue on the si7021 -- this is not a critcal need - just testing stuff.

[stuck elbow]

@solar whale do you think you could testing with 5 added to that tuple on line 74?

[slender iron]

<@&356864093652516868> The meeting is still on for today at 3pm Pacific / 6pm Eastern. Make it if you can otherwise no worries! Have a great holiday break.

[solar whale]

@stuck elbow sure - - looks like current code has a fe changes - it is now in line 78 😉 - I'll try it

[tulip sleet]

@solar whale @stuck elbow no other driver in the bundle catches 19 specifically. bno055 catches any OSError and assumes device is resetting

[stuck elbow]

I guess I was overzealous

[prime flower]

has anyone come across an error when casting a float to an int (TypeError: can't convert float to int)?

[stuck elbow]

@prime flower with int()?

[prime flower]

yep

[tulip sleet]

@prime flower in C or Pyton?

[prime flower]

pyth

[stuck elbow]

python doesn't do implicit casting, you have to use int() or math.round() explicitly

[tulip sleet]

it's too big?

[prime flower]

not sure. passing in frequency = 25.2 to length = int(4000 // frequency) and hitting that error

[stuck elbow]

ah, use /

not //

// expects an int

[solar whale]

@stuck elbow @tulip sleet adding 5 to the tuple woks

[prime flower]

tried doing /, still gets the same error.

[solar whale]

oops - not so fast - I forgot to go back to 3.0....

[stuck elbow]

works for me

[solar whale]

just a sec - will try unde 3.0

[stuck elbow]

actually, it works for me with // too

@prime flower is that 2.x or 3.0?

[prime flower]

yea, it works within the REPL but not the lib.

[stuck elbow]

now that is fishy

[tulip sleet]

@prime flower can you point to the code?

@solar whale would suggest just catching OSError withOUT checking for 5 or 19

[prime flower]

https://gist.github.com/anonymous/0654e89cb3f1043f8a3aac5d1633cd28#file-gistfile1-txt-L21

[stuck elbow]

@prime flower works for me in main.py too

[solar whale]

@tulip sleet so just "pass" on OSError?

[tulip sleet]

@prime flower I think the error is actually here for i in range(length / 2):

range cant' take a float, and thats float dividision

v>>> range(5.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't convert float to int

[stuck elbow]

yeah, those pokemon try-excepts are confusing

[tulip sleet]

@solar whale prob fine, that's what bno055 does

[stuck elbow]

it's just witing for the sensor to start responding again after a reset

I wonder if we should have a timeout there

[tulip sleet]

maybe good to note that in a comment if not already noted

[stuck elbow]

and raise an exception after a number of tries

otherwise you could have your whole project stuck because of a bad connection

then again, this is not Apollo computer...

[solar whale]

@tulip sleet using pass in lin 78 - bumps the error down the ine ....

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "si7021_test.py", line 10, in <module>
  File "/lib/adafruit_si7021.py", line 121, in temperature
  File "/lib/adafruit_si7021.py", line 100, in _data
  File "/lib/adafruit_si7021.py", line 100, in _data
  File "/lib/adafruit_si7021.py", line 97, in _data
  File "/lib/adafruit_si7021.py", line 97, in _data
  File "adafruit_bus_device/i2c_device.py", line 78, in readinto
OSError: 5

[stuck elbow]

well, that's the same pattern again

same fix

[solar whale]

yes it repeats in _data - I'll add the pass there as well.

[tulip sleet]

bno055 does this for reset:

    def reset(self):
        """Resets the sensor to default settings."""
        self.switch_mode(CONFIG_MODE)
        try:
            self._write_register(_TRIGGER_REGISTER, 0x20)
        except OSError: # error due to the chip resetting
            pass
        while True: # wait for the chip to reset
            time.sleep(0.01)
            try:
                chip_id = self._read_register(_ID_REGISTER)
            except OSError:
                chip_id = 0
            if chip_id == _CHIP_ID:
                break

[stuck elbow]

I know, I wrote it, but I'm starting to have second thoughts about this now

[tulip sleet]

just showing jerry

[solar whale]

        self.i2c_device = I2CDevice(i2c_bus, address)
        self._command(_RESET)
        # Make sure the USER1 settings are correct.
        while True:
            # While restarting, the sensor doesn't respond to reads or writes.
            try:
                data = bytearray([_READ_USER1])
                with self.i2c_device as i2c:
                    i2c.write(data, stop=False)
                    i2c.readinto(data)
                value = data[0]
            except OSError:
                pass
            else:
                break
        if value != _USER1_VAL:
            raise RuntimeError("bad USER1 register (%x!=%x)" % (
                value, _USER1_VAL))
        self._measurement = 0

    def _command(self, command):
        with self.i2c_device as i2c:
            i2c.write(struct.pack('B', command))

    def _data(self):
        data = bytearray(3)
        data[0] = 0xff
        while True:
            # While busy, the sensor doesn't respond to reads.
            try:
                with self.i2c_device as i2c:
                    i2c.readinto(data)
            except OSError:
                pass
            else:
                if data[0] != 0xff: # Check if read succeeded.
                    break
        value, checksum = struct.unpack('>HB', data)
        if checksum != _crc(data[:2]):
            raise ValueError("CRC mismatch")
        return value

this works

[stuck elbow]

I guess we could replace that while loop with a for loop with an else, and raise an exception in that else?

[solar whale]

modified init and data

[stuck elbow]

@solar whale looks good!

[solar whale]

@tulip sleet @stuck elbow I'll update the issue wit thsi information. Do you want a PR with this change or should it wait for further discussion.

[stuck elbow]

@solar whale a PR would be great!

[tulip sleet]

@solar whale i defer to @stuck elbow 's thoughts on the best way to fix tit

[stuck elbow]

I think this is good enough™

[solar whale]

OK - I'll create a PR.

PR submitted - feel free to ammend as desired. thanks!

[stuck elbow]

@tulip sleet what is the pr merging policy? Can I just merge it, or do we require a minimum number of reviews?

[slender iron]

@stuck elbow you reviewing is enough

and passing travis tests and such

[stuck elbow]

which merge strategy is preferred?

merge commit?

[slender iron]

I rebase when the commits are ok and squash if not. dan likes to merge and thats ok too

[tulip sleet]

@slender iron debugging the gcc 7.2.1 issue: gdb sometimes hangs when printing backtrace and some other weird stuff when debugging these hangs. Older gdb does too. I just have to be careful. It prints enough so that when I restart it I know what frame to go to. just YI

[slender iron]

weird. I've never really seen it hang

did adding lto repro it with debug symbols?

[tulip sleet]

i was kinda astounded. Also when I was printing some objs. Yes I can debug it. It's in gc, calling __del__ on an object it wants to gc. The obj looks like a vfs_fat obj (??). I noticed these comments in gc_collect() in main.c:

    // WARNING: This gc_collect implementation doesn't try to get root
    // pointers from CPU registers, and thus may function incorrectly.

Is this a potential serious issue? accidentally gc'ing something that seems to have no ptrs, but might have refs in a register?

[slender iron]

maybe yeah

its unlikely a ptr is only in a register though

[tulip sleet]

prob. I'd need to know which regs might contain python object pointers. The regs are checked in the the esp8266 gc_collect() and some others. Prob need to understand the abi conventions or something. If they only look like objects perhaps that's safe, or would it try to follow them? Not expecting an answer - I have to understand the gc and I don't really know the details right now

[stuck elbow]

as far as I know the MicroPython gc is pretty loose about what it considers a pointer — it can have false positives

[slender iron]

I think it'd ignore any values outside the range of the heap

[stuck elbow]

I think the assumption is that they will get gc-ed next time around, or something

[tulip sleet]

so I could easily check the right regs for pointers. I'll add that to the list of things to do

since arm-none-eabi-gcc is used for stm and other arm impls, I can probably just follow what's done in those ports, since the reg use should be the same

[umbral dagger]

@meager fog Still climbing this particular learning curve as quickly as I can 😃 Feedback appreciated: https://github.com/dastels/circuitpython_lsm303

[meager fog]

https://github.com/dastels/circuitpython_lsm303/blob/master/adafruit_lsm303.py#L219 isnt ever called, remove?

[timber lion]

oh did the meeting get moved to 3 instead of 11 pst?

ouch, hrm i can't make 3 today

[stuck elbow]

how much time until the meeting?

[timber lion]

4 hours

[stuck elbow]

thanks, not sure if I can make it either

[idle owl]

@stuck elbow Do you have a minute?

[stuck elbow]

sure, always

[idle owl]

For the ssd1331 update. I don't know why the pylint messages are there. Scott wants comments included to explain. Could you help?

I think you explained the init one in the comment

[stuck elbow]

well, the other is about the number of arguments

and we simply need that many arguments in that function, because that's how many arguments it needs

no, wait, that's circular argument

because that's the API

[idle owl]

"due to function requiring the given number of arguments" ?

or method I guess since it's api

[stuck elbow]

the driver needs all that data

to work

[idle owl]

Ok, I got that one then.

What's the super for?

[stuck elbow]

so that we can override the default values

[idle owl]

ok

got that then too.

What about the "no-member" after that? Although I'm not sure he wanted comments on the whole thing or not. But might as well.

[stuck elbow]

let me see

[idle owl]

ok

[stuck elbow]

not sure what that is about, do you remember what the lint error message was?

[idle owl]

No. I can remove it and lint it though. two shakes.

[stuck elbow]

:no-member (E1101): %s %r has no %r member
Used when a variable is accessed for an unexistent member.

is "unexistent" a word? %)

[idle owl]

E:103, 8: Instance of 'SSD1331' has no 'dc_pin' member (no-member)

I didn't think so

It is now 😄

The dc_pin is called in another file iirc

[stuck elbow]

yeah, it's inherited from the DisplaySPI

[idle owl]

excellent!

Thank you!!

@slender iron update to ssd1331 pushed to PR. travis passed.

[slender iron]

ok, I'll look now @idle owl

[idle owl]

keen

[slender iron]

@stuck elbow and @timber lion sorry you can't make it. we'll still do 11am normally. I just wanted to experiment with a different time

@idle owl did you mean to merge and approve https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/pull/10 before your pull?

[idle owl]

No because it doesn't work in his and there's still 3 other drivers that have to be tested in that one.

He knew he'd have to rebase that file.

@stuck elbow said it was a totally different issue so we did it separately.

Since it was an issue with the original driver

[slender iron]

ok, well the dc lint error is correct because its stil just dc and not dc_pin in master

[idle owl]

hmm

bugger.

So change it to dc in mine for now?

[stuck elbow]

there is a pull request to change it

[slender iron]

right, its an ordering problem

[idle owl]

Yeah it'll break in the meantime

[slender iron]

I thought the lint PR would be merged first but it shouldn't be if they aren't all tested

[idle owl]

There's so much in it, I've been working through it slowly

[slender iron]

yeah, that library is large

[idle owl]

I didn't realise there's even multiples in each lib file. I have so many displays now

so that's why it's not done

[slender iron]

k, no worries

[idle owl]

so change mine to dc and remove the pylint bit and it should at least be good for master, and it'll need to be updated in the PR?

[slender iron]

yeah

[idle owl]

ok

[slender iron]

because pylint isn't enabled in travis now anyway

[idle owl]

ok pushed to PR

it passed without the no-member bit locally

[stuck elbow]

I totally missed the fact that dc_pin is not merged

[idle owl]

That's why we have multiple eyes-on 😃

[slender iron]

ok merged (squashed)

[idle owl]

nice. thanks!

[stuck elbow]

@slender iron I wonder, is there a way to see the summary of all open circuitpython-related pull requests somehow?

just to make sure we are not missing any

I had some pull requests to the micropython libraries that I didn't see for months

[slender iron]

@stuck elbow Not exactly. Adabot can traverse all of the repos already though so it shouldn't be too hard to add. https://github.com/adafruit/adabot/blob/master/adabot/circuitpython_libraries.py#L208

ideally we could hook some of that logic up to adabot on discord

[umbral dagger]

pylint question: it's complaining about my use of "const" . How can/do I fix that?

[idle owl]

I think I found it's build into travis ci, so it'll complain locally but build fine in the PR. If you're talking about the same error I think you are

[umbral dagger]

Undefined variable 'const' (undefined-variable)

[idle owl]

oh nope. That's different.

[umbral dagger]

resulting from things like _REG_ACCEL_CTRL_REG1_A = const(0x20)

[idle owl]

right. I'm looking at one right now that has those, and there's no pylint-disable for that. Just the whitespace disable

not sure.

(thought maybe we were disabling it or something, so I checked)

did you do the import like this from micropython import const ?

dunno if that matters

I'm going through things in this lib that might have helped. That's the last of the ideas I have if that didn't help.

[umbral dagger]

no import for it

[slender iron]

you need the import

(micropython and circuitpython don't actually require it but they should.) we should add another built-in function

[umbral dagger]

That did it. It lints clean now

[idle owl]

Nice!

[umbral dagger]

If anyone cares to have a look: https://github.com/dastels/circuitpython_lsm303

[slender iron]

@umbral dagger I'd suggest using properties for most of what you are doing

https://circuitpython.readthedocs.io/en/2.x/docs/design_guide.html#sensor-properties-and-units

any methods with a set_ prefix should likely be properties

[umbral dagger]

Oh neat

[slender iron]

@timber lion can I make the thermal printer repo public?

[stuck elbow]

oh, nice

[idle owl]

So with the tap int pin state read changes, acceleration is broken on the CPX using lis3dh directly. Which means somehow acceleration was using the interrupt. Everything works great on the LIS3DH breakout.

[stuck elbow]

strikes out another part for which he wanted to write a driver from the list

[umbral dagger]

@slender iron Updated to use properties

[idle owl]

Broken as in: acceleration grabbed one initial set of data, and then never updates.

[umbral dagger]

@stuck elbow Total yak shave... I wanted an accel featherwing and that flora breakout fit on a featherwing protowing just right, and was fairly cheap.

[stuck elbow]

@umbral dagger sorry, I was thinking about the printer

[umbral dagger]

@stuck elbow But I did want to start writing driver level studd, soo...

@stuck elbow ah

[stuck elbow]

but your driver is great too!

we need more of them

[umbral dagger]

😃

[slender iron]

@umbral dagger its weird you are setting _LSM303MAG_GAUSS_LSB_XY which is formatted like a global. I'd suggest using a attribute on the object

also accel should be accelerometer to match other drivers and the guide

[idle owl]

How would acceleration using the same driver be using something one way on the breakout and something another way on the CPX? It's the same driver...

[umbral dagger]

@slender iron True. An artifact from the inital C code I ported.

[slender iron]

looks like we need to add one to the guide for magnetometer as well

[umbral dagger]

@idle owl I'll look at the CPX driver api

@idle owl Makes sense for them to be compatible

[idle owl]

@umbral dagger I was on a different tangent if you're referring to what I just said. But your statement is still valid either way.

[slender iron]

@umbral dagger no need for sensor_type either. you can just pass the device directly

@umbral dagger the design guide should have magnetic as an x, y, z of uT

[stuck elbow]

ideally you would look for an existing driver for a similar device, and make it work the same way

[umbral dagger]

I worked form the C driver and a different CP accel driver

[slender iron]

not sure we've done a magnetometer driver yet

[stuck elbow]

Which different driver? We might need to synchronize it

[timber lion]

@rapid ember is the build sorted out and able to make releases? if so yep it's good to make public

er @slender iron

[slender iron]

@timber lion it needs to be public to get the build sorted out

its ok for it to be public without a release right?

[timber lion]

oh gotcha, yep fine with me

[slender iron]

ok perfect! will do that after lunch

[timber lion]

yeah i wasn't sure if travis would be mad now if it's not public

any commit will likely try to trigger it

i don't see any commits in the near future though

[slender iron]

I'm not sure actually

adabot only has permissions to work on public repos

[timber lion]

we'll see 😃

[slender iron]

I do have some feedback on it, how should I get that to you?

(for example why we need begin separate from __init__)

[umbral dagger]

@stuck elbow Bah... I was looking more closely at the C lsm303 lib.

But hey... make it work, then make it work nice

[stuck elbow]

sure

I'm a huge fan of working software

in fact I try to only use working software myself

[manic glacier]

tannewt

[adafruit/circuitpython] Issue opened: #502 Update \`magnetic\` attribute in design guide

Its listed as a single value but should actually be an x, y, z tuple like acceleration.

[idle owl]

@stuck elbow Whaaaaat? Working software? Come on.

[stuck elbow]

I know, I know, dream on. But it's nice to aspire to something.

[timber lion]

@slender iron yeah i made it in the comments, begin takes about a half second to run so i want people to have control when it happens

it's waiting for printer warmup

if you do it in the initializer it's not obvious to people and they're going to put it in all their global object creation at the top of their script

and wonder why it takes 1/2 second to get to main code 😃

the guide and explanation also mentions it a lot too

coming from the C++ world I'm still super leery of putting a lot of logic in object creation too

i know python can throw exceptions and such.. but no one really catches them in object creation 😃

[stuck elbow]

I do

[timber lion]

totally, you can and should but in practice most python beginners avoid it

it's not usually an expected thing

particularly if coming from C++ 😃

[stuck elbow]

the list of things you do in Python that are not common in C++ is very long 😃

[timber lion]

yeah i wish someone would make a good book about coming to python from a C/C++ background

it's a big mind shift

haven't really seen much out there

[stuck elbow]

but in C++ when you call the constructor for a global variable, you can't really do much logic

so it makes sense to have a deferred "real" constructor

[timber lion]

yeah and C++ has all the quirks around when objects are created, like static initialization and such

i remember there was a brief period of time where i fully undestood those semantics

and then immediately forgot them 😃

it gets super strange though and IIRC there's actually undefined behavior in the spec for lots of static objects that depend on each other

[stuck elbow]

I wonder if it would make sense to have a pair for methods, for switching the heater on and off, so you could save energy when not using the printer

could matter for battery-powered projects

[timber lion]

yeah it's not actually turning anything on unfortunately, it's happening as a side effect of resetting its state

these printers are odd little beasts

the firmware works but i have a feeling is kinda buggy like some of the fancy sensors (BNO055)

they dramatically change instructions between minor firmware versions

like setting inverse mode totally changes from version 2.64 to 2.68

kinda feels like they just hack things in as necessary 😃

[stuck elbow]

yes, also the font switching and even what fonts are available

it feels like they actually have several branches of that firmware for different use cases, but we get whatever branch was most recently released

[timber lion]

hah yeah could be!

[stuck elbow]

I still didn't figure out the images on that thing

I have some thermal sticker paper, the kind you use for labels — I wanted to connect a microbit to it, and have kids design their own 5x5 stickers

[timber lion]

yeah i couldn't get bitmaps going either

i think we're sending data too slowly and the printer bugs out

[stuck elbow]

I guess I could print 5x5 images with ascii-art

[timber lion]

it starts interpreting the bitmap data as characters for me and prints bizarre stuff

ah fun yeah ascii printer art

[stuck elbow]

are you powering it properly? usb is not nearly enough for it

[timber lion]

yeah bench supply with 5.5 volts up to 2 amps

the arduino code prints bitmaps fine

[stuck elbow]

I had it reset in the middle of a line when powered from usb

[timber lion]

and i'm sending the same data.. but something is up

ah interesting

i was going to go back later and look more with a saleae to see if anything is up

but my gut is that it's not getting data fast enough and starts interpreting the bitmap bytes as characters to print

even though you tell it how many bytes to expect, it seems to just stop and go back to print mode

[stuck elbow]

are you using the samd21?

you could buffer the whole thing first, and then send in one burst

[timber lion]

yeah samd21, yeah i tried for a very small 8x8 image that and it might have worked but it was hard to tell (it's a really small 8x8 pixel square.. super tiny when printed and hard to see if it's filled in or not)

but big images in general are hard as they take a ton of memory

75x75 pixel adafruit image basically filled up memory

with the library and such

so even if printing worked right now it would be pretty limited 😃

[carmine hornet]

Is there a map function in circuitpython like there is in arduino or makecode?

[stuck elbow]

hmm, streaming from a file could be an option

@carmine hornet in the simpleio module

[timber lion]

yeah totally i'd like to stream from file or SD, but if from memory is too slow right now need to figure that out first

@carmine hornet something i like to use instead is a linear interpolation function (what map does internally), good background here: https://en.wikipedia.org/wiki/Linear_interpolation

it's a couple lines as a function though, very clear in python:
def lerp(x, x0, x1, y0, y1):
return y0 + (x -x0) * ((y1 - y0) / (x1 - x0))

can see the formula exactly matches the simplified version in the articule

i used lerp everywhere.. it's great for animating colors

[stuck elbow]

it looks like the docs for simpleio are not picking up the docstrings from the code: http://circuitpython.readthedocs.io/projects/simpleio/en/latest/#api-reference

[timber lion]

like if you get a sine wave that goes from -1 to 1 you can map to a color value 0 to 255 like
x = math.sin(... whatever your sine wave is...)
color = lerp(x, -1.0, 1.0, 0.0, 255.0)

easier to add that one liner than import a whole separate lib too 😃

[manic glacier]

microbuilder

[adafruit/circuitpython] New comment on pull request #496: nRF52 update with internal file system support

@tannewt This includes 'feather52' builds on travis now, but the CTRL+C issue with REPL still needs to be addressed before this can be merged (hopefully tomorrow).

[idle owl]

I have no idea. The breakout is wired the same. It only uses INT1, INT2 isn't connected to anything. Same as CPX. But the CPX is using the lis3dh driver differently than the breakout.

[timber lion]

alright i have to run, sorry i thought the meeting was at normal time of 11am today... i have to be at a family get together at 3pm and will miss the meeting this afternoon

[idle owl]

It's all good. Have a great time!

[cunning crypt]

I'm on the other side - I'll be here!

Just no voice from me today. We have family visiting. Family in the form of four children.

[slender iron]

@timber lion have fun with your fam!

[slender iron]

@stuck elbow here is the list of open PRs:

• https://github.com/adafruit/Adafruit_CircuitPython_SD/pull/4
  • https://github.com/adafruit/Adafruit_CircuitPython_VC0706/pull/1
  • https://github.com/adafruit/Adafruit_CircuitPython_HT16K33/pull/1
  • https://github.com/adafruit/Adafruit_CircuitPython_MAX7219/pull/9
  • https://github.com/adafruit/Adafruit_CircuitPython_CharLCD/pull/6
  • https://github.com/adafruit/Adafruit_CircuitPython_BNO055/pull/4
  • https://github.com/adafruit/Adafruit_CircuitPython_SSD1306/pull/6
  • https://github.com/adafruit/Adafruit_CircuitPython_SSD1306/pull/5
  • https://github.com/adafruit/Adafruit_CircuitPython_SI7021/pull/6
  • https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/pull/10
  • https://github.com/adafruit/circuitpython/pull/496

[stuck elbow]

@slender iron I found 2 more for the micropython libraries

[slender iron]

kk, this is only looking in libraries returned by github's repo search for circuitpython

[cunning crypt]

@slender iron Do you have those statistics broken down into which boards are more popular?

[slender iron]

• arduino_zero 83 +14
  • circuitplayground_express 1171 +422
  • feather_huzzah 254 +31
  • feather m0 adalogger 76 +10
  • feather m0 basic 99 +13
  • Feather m0 express 337 +50
  • gemma m0 206 +44
  • metro m0 express 144 +27
  • trinket m0 638 +144

[cunning crypt]

Oh, neat.

CPX is,completely unsurprisingly the clear leader

Even without that, though, it had a good lead

I'm surprised a little at how many downloads there are for the Huzzah, given how much more difficult it is to install compared to the Express

Probably right.

[slender iron]

https://github.com/adafruit/circuitpython/issues/493

[cunning crypt]

Hug Report: Lady Ada, as she updated Kattni's wonderful "Intro to CP" with instructions on how to install CP onto non-Express boards and ESP boards, in a matter of minutes, in the middle of the night, when someone was looking for how to do it. Also, group hug because everyone here is awesome and I won't be able to do another one until next year.

[slender iron]

?whois tannewt

[digital shore]

tannewt#4653

ID

252717193496756235

Nickname

None

Status

online

Game

None

Joined

Thu, Jun 22, 2017 1:13 AM

Join Position

1

Registered

Mon, Nov 28, 2016 8:47 AM

Roles

community helpers, world-maker-faire, Show & Tell, osh-summit, circuitpython helpers, seattle-mini-maker-faire, admins, multiplayer-gaming, metro m4 testers

Key Permissions

Kick Members, Ban Members, Administrator, Manage Channels, Manage Server, Manage Messages, Mention Everyone, Manage Nicknames, Manage Roles, Manage Webhooks, Manage Emojis

Acknowledgements

Server Admin

Dec 28, 2017, 11:16 PM

[idle owl]

Jerry

[stuck elbow]

I didn't think to type it 😊

steppers are complex

[cunning crypt]

He'll just have to step up his game, right?

Status Update: Begun work on "Migrating from Arduino to CP" guide. Not much yet, but if anyone wants to peek at it feel free to prod me. That's also my plan for the next week, too.

[idle owl]

That looks amazing!

[cunning crypt]

Indeed, it looks awesome!

I thought the weather would be snow big deal

[errant grail]

Ice rain is problemmatic for strings, not just the electronics.

[stuck elbow]

but glass trees are pretty

https://cdn.hackaday.io/images/4955251514252282765.png

https://cdn.hackaday.io/images/388361514475842212.jpg

[errant grail]

Wow!

[idle owl]

It's so tiny!

[cunning crypt]

I think you can do smaller.

Make it so you need a SEM to view it.

[stuck elbow]

https://hackaday.io/project/27629-game/log/70845-homebrew

[tulip sleet]

@solar whale M4 3.0 gcc7 test code: CIRCUITPY/c.py

def r():
    for i in range(510):
        print(i)
        l = [0]*50

in REPL:

>>> import c
>>> c.r()

Will hang around i=497. That is when gc gets called.

Do NOT put c.py in main.py, because you'll get stuck and not be able to get to CIRCUITPY when it hangs

[stuck elbow]

https://github.com/greiman/SSD1306Ascii

[solar whale]

I'm sorry - I have to go - good night and Happy New Year all.

[idle owl]

Have a good one!

import adafruit_lis3dh
import busio
import board
import time

i2c = busio.I2C(board.SCL, board.SDA)
lis3dh = adafruit_lis3dh.LIS3DH_I2C(i2c)
lis3dh.range = adafruit_lis3dh.RANGE_8_G

lis3dh.set_tap(2, 20, board.D11, time_limit=10, time_latency=50, time_window=255)

while True:
    x, y, z = lis3dh.acceleration
    print(x, y, z)
    time.sleep(0.1)
    if lis3dh.tapped:
        print("Tapped!", time.monotonic())```

https://gist.github.com/kattni/e6f77f710d3697bc9861e78136363d53

        try:
            self._lis3dh.set_tap(value, 90, board.ACCELEROMETER_INTERRUPT, time_limit=2,
                                 time_latency=50, time_window=255)```

[errant grail]

Thanks all! Have an excellent New Years!

[slender iron]

thank you all!

[stuck elbow]

thanks

[idle owl]

Thanks so much!

[cunning crypt]

Video recording is a monster on disk space

Everyone pitch in $1 and we can get him a set of floppy disks for his videos.

@errant grail @idle owl GitHub is NOT intuitive well

Reel-to-reel tape storage?

@slender iron Out of curiosity, what's your typing speed? It sounds like you type pretty fast

@slender iron Do you use hibernation on your computer? I remember a while back that Windows would end up with a several-gig hibernation file even if you're not actively using it

ALL the NVidia drivers.

Upgrading from tiny SSD + storage HDD to pure SSD was the biggest upgrade my computer has had

GPUs also matter if you run multiple monitors

I have six monitors on my computer. I still need to fiddle things around to get them all working again though.

[idle owl]

Oi

[cunning crypt]

Yes I do!

Vivo makes good mounting brackets

They're solid steel bars. can't get much simpler

[tulip sleet]

that's good the vivo 6-monitor thing is $1125

[cunning crypt]

I didn't spend NEARLY that much on mine.

Hopping out of voice chat as well. Later!

[errant grail]

g'nite!

[stuck elbow]

night

[idle owl]

Night all!

[slender iron]

night all!

[cunning crypt]

@tulip sleet This is the one I have: https://smile.amazon.com/gp/product/B00B1D4P56/

[slender iron]

def __init__(self, spi, cs, baudrate=100000):

[tulip sleet]

@cunning crypt looks good as long as the tabletop is sturdy!

[slender iron]

def __init__(self, spi, cs, *, baudrate=100000, int1=None, int2=None):

[cunning crypt]

I went hunting for an appropriately sturdy desk before purchasing.

[tidal kiln]

hey. happy holidays all. sry. very afk season for me.

[cunning crypt]

An old picture. I've upgraded several monitors since then.

[carmine hornet]

I was working with a neopixel strip and the circuit playground, and it was working perfectly fine until I taped the strip to the wall. Can anyone help?

Now it only controls two pixels

heres my code

I don't see any physical damage to the strip

[tulip sleet]

@carmine hornet if you didn't change the code then you may have cracked one of the solder joints on the strip. try pressing on the last lit pixel or the first dark one, and also inspect the solder joints carefully with a magnifying glass. it may help to bend the strip slightly to see a crack. Also are you using longer wires to the strip than you did before? And are you powering the strip with 5v or3.3v?

[idle owl]

@tulip sleet I'm about to do the PR for LIS3DH. I can send you some testing files if you want to try it, including a test build with the frozen module updated and the current demo code.

Still have some documentation to change in express class but the core or everything is done.

[tulip sleet]

@idle owl sure, but in the morning

[idle owl]

@tulip sleet Ok np. Figured I'd offer in case you were up for it tonight.

[tulip sleet]

no, I'm fading fast after staring at assembly language

[idle owl]

That sounds tiring 😄

[tulip sleet]

if I add a print statement in a certain place, then the 3.0 gcc7 stuff works. I know what is different, but not why it makes a difference yet.

[idle owl]

oi, yeah

[tulip sleet]

ok, gn

thanks for all the work today and yesterday on lis3dh

[idle owl]

Yeah it's all fixed it seems!

Night!

[tulip sleet]

@slender iron think I found a compiler bug; I know how to get around it. something's forgetting to save one of the arg passing registers. Have to find all the cases where this happens. Has to do with calling routines designated attribute(na k e d) (spaces added to avoid bot censoring. This bug appears to be new in gcc7. @idle owl I lied when I said I was going to sleep.

[idle owl]

@tulip sleet I noticed

[tulip sleet]

but now I don't have to chew on it overnight 😃

[idle owl]

I totally understand

I had to go to sleep with the lis3dh thing still in the air last night

[tulip sleet]

yeah, wake up at 3am with visions of code dancing in your head

[idle owl]

exactly

[tulip sleet]

ttyl this time for real

[idle owl]

Night!

[idle owl]

@meager fog I have a test build of CircuitPython for the CPX with the updated lis3dh frozen in. I have a PR in for the update to both lis3dh and the CPX express class updated to work with it. I have files for you when you're around.

I am done for the night!

[tulip sleet]

@slender iron my diagnosis was incorrect, but still maybe getting closer.

[solar whale]

@tulip sleet progress is not always forward 😉

[tulip sleet]

@solar whale 🤷 but now I understand the calling conventions on ARM, which is actually very helpful to know.

[solar whale]

@tulip sleet I just ran your "c.r" on my Metro M0 (Cp 3 gcc 7.2.1) and it completed ok.