#circuitpython-dev
1 messages · Page 168 of 1
It's true!
Have a boring flight!
Only if exciting means something bad. Really have a good flight, @ruby atlas 😃
How do I resolve the "Changes Requested" flag?
You resolve the issues and then the reviewer who requested the changes resolves the flag.
@matt-land just mention me asking for a re-review. I haven't figured out what the GitHub workflow is meant to be.
Boring flights are the way to go.
@stuck elbow hi, thanks for all your help last time! may i pick your or anyone elses' st7735r knowledge ?
i'm having trouble understand what is being sent over spi. and how to configure what to send
i want to send a different _MADCTL value to rotate the display. currently b'\xc8' is being sent and it makes the display look normal, but sending bytes(0b011000 & 0x07) also shows normal. and(_MADCTL, b'\128')shows it rotated 180.
ive looked up the datasheet (http://www.displayfuture.com/Display/datasheet/controller/ST7735.pdf) and ive tried sending the bin values specified on page 61. no avail. was that descriptive enough ?
Just figure out what bits need to be set.
@marble hornet you want MY =1 Mx =1 Mv = 0?
they go in th upper 3 bits of the MADCTL byte binary 111xxxxx or 0xE0 masked into the other bits of _MADCTL
sorry 0xC0
ah
binary 110xxxxx or 0xc0
so,, (my_bin << 5 ) + ?
Note: Data is always written to the Frame Memory in the same order, regardless of the Memory Write Direction set by MADCTL bits B7 (MY), B6 (MX), B5 (MV). The write order for each pixel unit is
that should work or better (my_bin<<5) | (lower 5 bits)
| is a thing ?
yes indeed. ;)
def disp_logo_geom(page):
global cmd
column = 0 # must be zero or a multiple of 16
icol = column + 16
cursor_right = (icol // 16) - 1
cmd = (0x10 | cursor_right) ; display.write_cmd(cmd) # upper x positional byte
cmd = (0x00 | 0) ; display.write_cmd(cmd) # lower x positional byte - fine tuning
cmd = (0xb0 | page) ; display.write_cmd(cmd) # only y positional byte - page 0 is middle row
cmd = 0xe0 ; display.write_cmd(cmd)
# write data here
That's from some private ST7565 code I wrote in February.
nice @timber mango
@slender iron belated response RE: .subscr. you were spot on. i went and read the code in py/objtype, and i was trying to use it incorrectly (without array/indexing). switched to frequencyin.value... thanks for the quick eye/feedback!
@solar whale @timber mango um... TypeError: unsupported types for : 'bytes', 'int'
for this code :
b'\xc8' | (bytes(0b110)<<5)
bytes(0b110<<5) but why are you oring it with 0xc8
@slender iron Thanks for showing the CP team. I like this pic of @tulip sleet
i don't, unless the lower 5 bits can be extracted from \xc8, but i haven't been able to translate \xc8 to bits
0xc8 os 11001000 --
0xc8 1100 1000
|facepalm|
My =1 Mx =1 Mv = 0 - low bits are 01000
c = 1100 8 = 1000
@timber mango don't go there 😉
hahah. When I learned it we had to know it to do our job.
( (bytes(0b110<<5) | bytes(0b01000) ) ??
, have a preference for bin, but thats me
(b'\b0b110' << 5) | b'\b01000')) gives (b'\b0b110' << 5) | b'\b01000'))
byes byt why or -- use 0b11001000
okay, i just tried 0b11001000
i got TypeError: object with buffer protocol required
x = 0b11001000
what is the line of code you are writing?
One of the greatest things Microsoft ever did for me: added the "Programmer" calculator. i avoided bitwise/binary experience for so long, that i require a visual for it. 😄
(_CASET, cols),
(_RASET, rows),
(_NORON, None),
(_DISPON, None),
(_MADCTL, ( (b'\b0b110' << 5) | b'\b01000')),
):
self.write(command, data)```
ah, i think i'm a little out of my depth. (he says spreading sarcasm like butter), so thank you so much for all the help.
for**
@solar whale main.py output: Traceback (most recent call last): File "main.py", line 11, in <module> File "/lib/adafruit_rgb_display/st7735r.py", line 128, in __init__ File "rgb_text_.py", line 198, in __init__ File "rgb_text_.py", line 74, in __init__ File "/lib/adafruit_rgb_display/st7735r.py", line 146, in init File "rgb_text_.py", line 217, in write File "rgb_text_.py", line 217, in write TypeError: object with buffer protocol required
def char_out():
global cmd, mbytes
for p in range(0,6):
cmd = mbytes[p]
display.write_data_out(cmd)
def write_short_phrase_to_lcd():
global mbytes
mbytes = bytearray(b'\x3e\x48\x88\x48\x3e\x00') # A idea to use bytearray from deshipu's code
char_out()
mbytes = bytearray(b'\xfe\x82\x82\x82\x7c\x00') # D
char_out()
.
.
again, from unpublished code for ST7565.
okay, @timber mango what is the name for the notation inside fo the bytearray()?
I have no idea I was in a hurry so it was some monkey see monkey do coding all that week. ;)
😂 😂 i can relate
Those are hexadecimal bytes of 8 bits per segment.
$fe $82 $82 $82 $7c $00 is how it's written in Forth.
@marble hornet what was the code that caused that error?
Basically you're setting pixels in columns in that particular case.
Forth is a language. http://www.forth.org/
https://www.forth.com/starting-forth/
looks like data has to be a byte array try ```data=bytearray(1)
data[0]=0b11001000
self.write(_MADCTL,data)
The original code I wrote called them "muta_bytes" because I think the environment used the word 'mutable' in the error it generated. So I said they were 'mutable bytes'.
Shortened to mbytes in later iterations. ;)
in python3 ```>>> a=bytearray(1)
a[0]=0b11001000
a
bytearray(b'\xc8')
yay!
jerry when you typed the 'a' on a line by itself, it generated that? bytearray(b'\xc8')
yup
awesome!
That's obviously why deshipu chose that notation, then, I'd suppose.
(I was working off his driver for a similar problem to mine)
hmm,
I'm still not very well versed in python syntax -- keep googling it!
I can do the binary to hex conversion in my head so I am comfortable with the hex notation.
Yeah. The byte array is used ...
it can be any number of bytes
oh it turns int to bytes ?
you create the array using bytearray(x) for an x byte array - then populate it
mbytes = bytearray(b'\xfe\x90\x90\x90\x80\x00') # F
This sets all the pixels needed to form the glyph for the letter 'F' on a monochrome LCD.
0xfe is the first 8 bits, which are set from top to bottom (8 rows of pixels, one pixel wide).
not really - ints are several bytes long - a byte array is a group of 8bit values in order.
My bytearrays are 6 bytes each -- five bytes for the glyph and one byte of spacing.
(that's why the last number is always \x00)
the Adafruit 'fruit' logo
@cunning trail Thank you! 😃
@marble hornet I think the main reason bytearrays are used is to remove any uncertainty about the order in which multiple byte values are transferred.
good luck with it. I'm back quiet (watching Rumpole of the Bailey)
@marble hornet glad to help - and I learned few things as well
this is always fun. good times!
bed time here -- good luck with it!
hey does the cpx library have any commands for the analog out?
trying to write to it using board is returning that the pin's already in use, prob from loading in cpx before it
@harsh plume You need PulseIO
I can't really give better guidance right now. On an airport shuttle atm
I thought that PulseIO is for regular digital pins
It's been a while. I could be wrong
Note to self - and sharing with other nrf52 users... when building CP with a non default SOFTDEVICE - (like SOTFDEV_VERSION=5.0.0) don't mis-spell SOFTDEV_VERSION! the makefile does not complain, but it happily goes ahead an builds wih the Default 2.0.1 SoftDevice and when you load that to the feather52 with a 5.0.0 SD bootloader, it does not go well 😉 It took me quite awhile to figure out what I had done wrong and I was about to create an issue about the nrf52 build was failing to boot properly. All better now... minus a few more hairs.
I agree it's better to disable the functionality than to return a value that's 2 minutes off.
Is there a plan to enable long int?
Adafruit CircuitPython patchbase-dirty on 2018-05-10; Adafruit Feather M0 Express with samd21g18
>>> now = 1526400902
OverflowError: long int not supported in this build
>>>
This extends from PR https://github.com/adafruit/circuitpython/pull/841 (which should merge first) to add SPI support in a similar fashion as default I2C support.
import board
my_spi = board.SPI()
Boards were chosen for support for having all of the following defined in pins.c for the target board:
- MP_QSTR_SCK
- MP_QSTR_MISO
- MP_QSTR_MOSI
Boards that have support have the following in mpconfigboard.h:
- #define DEFAULT_SPI_BUS_SCK (&pin_PB11)
- #define DEFA...
@cunning crypt thanks for the tip, at this point honestly i'm just blinking an LED so digital will do :p
@dhalbert You've tried enabling long ints on express builds right? Do you think we have enough space?
@harsh plume check out the blinky code at the bottom of the rtd: https://circuitpython.readthedocs.io/en/2.x/shared-bindings/digitalio/__init__.html
looking like a lot of the PRs from PyCon are getting merged!
Having an issue creating working firmware for Gemma. Basically the previously loaded firmware determines if the next one works. Help wanted
Adafruit Gold Master > Mine <- mine works
Mine -> Mine2 <- mine2 does not work
@knotty cypress does Adafruit Master -> Mine2 work?
mine 2 will, but i have to go back to adafruit master before i can load my own again
@ruby atlas I thought of code with some other simple animations in it.
hmmm. what are you working on? seems a "breaking" change is getting hung up. could also be OS related; which OS are you on?
im on macOS, and im working on default serial for the board module
ahhh. are you able to debug? when it doesn't load, does the port get established?
@ruby atlas https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/CircuitPython_Essentials/CircuitPython_DotStar.py and https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/CircuitPython_Essentials/CircuitPython_NeoPixel.py
i didn't learn how to debug yet
@knotty cypress in case you want to: https://learn.adafruit.com/debugging-the-samd21-with-gdb
not sure how cross-platform it will be with macOS...
The slicing is harder to do because you have to do some weird code to make it work on a number of LEDs that aren't divisible by the size of the slice. But if it's behind the scenes, maybe we could make slicing really easy by making it more complicated code in the lib.
@idle owl awesome, i'll have to find myself a neopixel or two asap. looking forward to mucking around more later.
@idle owl i agree that we should hide the complexity in the libs to make it really easy to use.
TY
Agreed entirely, the question was more about whether to add slicing or not because it gets weird, but then I realised we can hide the weird and probably add it nicely.
@knotty cypress as an intermediate step, i'm sure macOS has a comparable dmesg to help diagnose the port creation. having done some work with the serial/USB CDC, i can vouch that it is not fun... 😄
@idle owl when you are ready for code of conduct feedback please make a PR so we can comment inline
@slender iron Ok I'll branch it and PR it. I linked it to two people and suggested filing an issue because I was still actively working on it.
Wait I already branched it. I'll PR it.
😃
I was trying to avoid merge conflicts since I was literally working on it that moment.
@margaret please mention us when this is ready for another review.
I was in-between build attempts, and needed something to do. 😆
@raven canopy I took that entire paragraph directly from a CoC we're adapting. Rewording is entirely ok by me. I like your suggestion a lot.
like I said, i'm aware that its still WIP. 😄
WIP that values your input. That's the entire reason it's on GitHub. We want feedback
Longints are currently enabled on 3.0 Express builds. I checked again recently about enabling on non-Express builds: https://github.com/adafruit/circuitpython/issues/572#issuecomment-387505388, quoted below. It looks pretty iffy that it would ever fit on 192KB builds (non-Express).
Longints are not going to fit in the non-Express builds for 3.0 without removing other stuff. I recently tried MPZ and LONGLONG. Currently a Gemma M0 build has about 1800 bytes free. If I enable MPZ, it overflo...
This implements default UART in atmel-samd boards, similar to how I2C and SPI work.
>>> import board
>>> board.UART()
<UART>
Boards were chosen for support for having all of the following defined in pins.c for the target board:
- MP_QSTR_TX
- MP_QSTR_RX
Boards that have support have the following in mpconfigboard.h:
- #define DEFAULT_UART_BUS_RX
- #define DEFAULT_UART_BUS_TX
Changing these values will change the default UART pins.
Supported Boards:
- (A...
@raven canopy Rust loves their semicolons.
Just randomly pondering LED animations.... I wonder... is (approximately) constant luminosity more important than colour accuracy for the default use case?
Well, say I want a colorloop with say 4 color points... say - blue, yellow, pink, orange - I think the colours will vary quite a bit in luminosity if we cycle through pure colours. Thay may be preferable for some uses. However, I know I'd be happier for some use cases with a relatively constant luminosity and would prefer to shift through Hues at a relatively fixed (or completely fixed) saturation/luminosity and use the colours as hints for what to cycle.
I suspect I'll just have to play with lots of combinations 😃
Ahh ok
I see what you're saying
I've done both, where I keep the overall RGB number equal when added together, or where I simply make the color I want and don't worry about relative luminosity.
Yah I would say experiment with it. And then once it's out in the world, people will use it and provide feedback and we can deal with it then
yep!
@slender iron Would you say "Adafruit Discord and CircuitPython Community Code of Conduct" is a better title? I thought it was wordy until I gave it more thought and realised it's a much better indication of the scope we're looking for. Now I'm into it.
I'd drop the Adafruit Discord part. In #code-of-conduct we can make it clear that the CircuitPython Community Code of Conduct covers the entire server.
eh, just because its called that doesn't mean we can't use it other places
I pulled the latest, but no long int.
pi@agl:~/circuitpython/workdirs/test/circuitpython$ git log --oneline -1
8581ee3f0 (HEAD -> test, tag: patchbase, origin/master, origin/HEAD, master) Merge pull request #844 from matt-land/feature-default-spi-circuit-playground
Adafruit CircuitPython patchbase on 2018-05-17; Adafruit Feather M0 Express with samd21g18
>>> now = 1526400902
OverflowError: long int not supported in this build
>>>
@notro, oops, you're right, it's enabled on M4, but not M0 Express.
Can someone please change it to 1970 and remove the APIs in non-express builds?
I can do this. Is there a 'long int in use' macro I can use to #ifndef the functionality?
I'm starting the guide on the CPX Express class and having a debate with myself about how to label the pages.
Maybe this?
STATIC const mp_rom_map_elem_t time_module_globals_table[] = {
{ MP_ROM_QSTR(MP_QSTR___name__), MP_ROM_QSTR(MP_QSTR_time) },
{ MP_ROM_QSTR(MP_QSTR_monotonic), MP_ROM_PTR(&time_monotonic_obj) },
{ MP_ROM_QSTR(MP_QSTR_sleep), MP_ROM_PTR(&time_sleep_obj) },
#if MICROPY_PY_COLLECTIONS
{ MP_ROM_QSTR(MP_QSTR_struct_time), MP_ROM_PTR(&struct_time_type_obj) },
+ #if MICROPY_LONGINT_IMPL != MICROPY_LONGINT_IMPL_NONE
{ MP_ROM_QSTR(MP_Q...
FYI -Just verified that this issue is still present.
@notro that looks good!
@slender iron @tulip sleet did you see this https://forums.adafruit.com/viewtopic.php?f=48&t=135734 I thought it best for an “official “ response.
looking now
@idle owl <SMILE> conventional wisdom says 1,2,3... </SMILE>
@idle owl how about break it by hardware aspect: buttons, slide switch, light sensor, etc
@languid sage Nice 😄 My debate was whether to call them simply by the sensor they use or include "CPX" before it so the titles of each page stands alone.
@tidal kiln That was what I was leaning towards.
@slender iron If you're good with it, I can put a final update on the PyCon issue on GitHub and close it out. I wasn't sure if you wanted to get into a bunch of details of the results there or simply update it and close it out.
@idle owl that sounds good. I didn't have plans for it
@tidal kiln @languid sage Either way the guide will be broken down by sensor on the Circuit Playground Express, it was simply a matter of whether to include more on each page title.
@slender iron Ok great
@idle owl I know whatever you choose, It'll be fine. I just thought, as it's late in the week, a bit of levity wouldn't hurt.
@languid sage I've been busy or travelling for nearly two months straight, a little levity is always welcome 😄
@idle owl it's going to be a stand alone guide? not part of the CPX guide:
https://learn.adafruit.com/adafruit-circuit-playground-express
It's going to be big. So it'll be standalone, but ideally it'll be mirrored into its own section on that guide as well.
So there will be a title and a sublist if it's mirrored.
But even including "CPX Temperature" doesn't really clarify it from anything else. So I feel like as long as I nail the title on the overview page, each page can be "Temperature" or "Buttons" under that heading and be clear.
PyCon was an absolute blast and a complete success. Our Open Spaces were full and people were incredibly engaged. The sprints resulted in tons of updates to libraries, core code and documentation, and continued after we had already departed the conference. We gave the NeoPixel rings and other hardware we had to individuals who were absolutely excited to have them. One of the best moments was when people came to us with new ideas and projects outside the quickstart we created and were so incre...
maybe use the same subsection headings from here?
https://learn.adafruit.com/adafruit-circuit-playground-express/guided-tour
Oh to break up the guide itself. I see. Yeah maybe. I know if it's mirrored in, it'll end up under one heading anyway. But maybe the guide should be broken up a little. I'll keep that in mind
I think I'll start with no sublists on the guide itself and see how it plays out
i'd lean toward not having CPX in front of them all also
mainly because it's an acronym, a whole bunch of all caps CPX's might look a little heavy
Also valid
I created a bunch of the pages and they look good with only the name of the sensor/LED etc.
and also, yah, unless you know what CPX stands for...what you said
If its a guide for CPX, then frequent citing of the CPX acronym appears to be a repetious redundancy, and so and so forth :^) (sorry for the bad spelling, it's been a loooong day)
It is a guide entirely for CPX, so also a good point.
@idle owl I once new a man who was an expert in his field... working for Title Insurance companies on complex land deeds, disputes, etc. He always said the correct way to write a document was "concise brevity". A lot of folks get the brevity part OK, but not the two of them together. My experience says that writing deeds is a lot like documenting software. Say it with enough words to absolutely cover the subject. No more, no less, and cover the subject well.
I do my best 😃
I've tend to find that people who are skilled are first and foremost problem solvers, communicators, and team players.
Then, after that -- they are knowledgable in their specific field....whether it is programming, being a manager, scientist, engineer, etc.
Or as they say in my specific field -- "we can teach anyone to do [what we do]. We can't teach someone to be easy to work with, to mesh well with our team. That team fit is more important than their technical skills they bring initially."
Anywho, back to your regularly scheduled Pythonic content 😉
in response to showing my kids the gemma_m0: "change more numbers! change more numbers!" and "ooh that's pretty" "less red" etc.
That's great! 😃
so i have a circuit express and was working with the IR sensor.. When i first started playing with it I was able to get pretty consistent results from a remote such that I could identify the keys. It was getting like 67 pulses that encoded to something repeatable. Now all I am getting is noise.. even when pointing a remote directly at it and pressing a key, I'm generally only getting 4-6 pulses maybe 10, but not the 67 I was getting before and the pulses are all random and not predictable to get a keypres read from it. I've reset power cycled the board several times, but no luck, it still behaves the same way. Any idea on what is going on? Is the sensor likley bad or is something else going on ?
did anything change? The remote? Did you update libraries? Anything?
nope.. i was testing something in the client code and it worked just fine and then just stopped working.
Perhaps something you set in the client code is causing a problem. Can you paste your code here? You can paste the code by adding three ticks (the key to the left of the 1) before and after the code like this
here's the important part..
pulses = decoder.read_pulses(pulsein, blocking=False)
if pulses:
print("Heard", len(pulses), "Pulses:", pulses)
# if len(pulses) >= 4:
# forward = not forward
try:
code = tuple(decoder.decode_bits(pulses, debug=False))
print("Decoded:", code, button.get(code))
#value = button.get(code)
#print("Decoded:", code, value)
#value = button.get(code)
#if value in ("1", "2", "3"):
# color_index = int(value)
except adafruit_irremote.IRNECRepeatException: # unusual short code!
print("NEC repeat!")
pass
except adafruit_irremote.IRDecodeException as e: # failed to decode
print("Failed to decode: ", e.args)
pass
so i used to get like 64 pulses from .read_pulses, now I'm just getting noise.. it's always dropping to the print("Failed to decode: ", e.args) block because it's so few pulses
this exact code was working just fine and then just stopped working
even without pointing a remote at it, i have always gotten random noise (2-4 pulses) that couldn't be decoded even when not pointing a remote at it.
What is the exact error message? Is it "10 pulses minimum" or "Not enough data"?
Failed to decode:
hold on, let me run and I'll give you some examples
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [193]
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [166]
Failed to decode: ('10 pulses minimum',)
Heard 3 Pulses: [167, 1748, 345]
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [170]
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [172]
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [170]
Failed to decode: ('10 pulses minimum',)
Heard 4 Pulses: [1915, 585, 909, 589]
Failed to decode: ('10 pulses minimum',)
Heard 1 Pulses: [169]
Failed to decode: ('10 pulses minimum',)```
@ruby atlas it might be neat to hook up a potentiometer(s) to control RGB values like https://learn.adafruit.com/rgb-hsv-neopixel-dialer
I'm just getting noise.. pressing the remote doesn't seem to have any affect any more.
i'm getting that noise if i am pointing the remote at it or not
What version of CP are you using?
i'm guessing the latest.. i got this board from scott at pycon during the sprint.. how do i confirm the version?
entering the repl by pressing ctrl+c
Adafruit CircuitPython 2.3.1 on 2018-05-07; Adafruit CircuitPlayground Express with samd21g18
looks pretty recent to me.. is it normal for the ir sensor to get noise when nothing is pointing at it?
could the board/sensor be going bad?
That is the latest version. I can't say if there is a problem with the board or not
is seeing noise normal for the ir sensor?
No, is it possible there is another remote or something else around you that it is picking up?
Did you by chance change this line so that idle_state=False? pulsein = pulseio.PulseIn(board.REMOTEIN, maxlen=120, idle_state=True)
nope, it's pulsein = pulseio.PulseIn(board.REMOTEIN, maxlen=120, idle_state=True)
it's constantly picking up noise.. as in, from when I plug it in, it's reporting noise ever few seconds.
i covered the board and it's still picking up noise
i have a shoe over the board, and it's still reporting 1-7 pulses randomly
I tried that and I am getting noise if I cover the IR tx and rx together...
ok, so noise is normal, but not sure why it isn't picking up signal
and it WAS working.. not perfectly, but pretty reliably. then it just stopped.
And you said you tried to reset the board? Did you press the reset button or unplug it?
i power cycled it.. is there something else to do a reset?
(removed the power and plugged it back in)
I would simulate the act of printing the code to paper (by capturing it somehow). Then erase everything. Then retype the entire program in by hand.
But only after verifying the IR remote used is still functional.
ahh.. that did it.. i just put the example in by it's self and it's responding as expected.
thanks, I'll figure out what I moved around to causse problems.
i think i may have moved the imports around
I looked back at your code and noticed you had blocking set to False in the read_pulses call,
that's a feature i just added during this sprint..
If False, will return None if no pulses.
Defaults to True for backwards compatibility ```
that was working just fine.
If you made a printout, mark it with a pen in your own handwriting to say it's good the way it is printed. ;)
digitally take an md5sum up to line number n and append it to the document as line number n + 1
$ cat -n ./myfile.py | sed 22q | md5sum >> to_append.txt
Something like that.
sed is just the stream editor, which in this case prints the first 22 lines of what was sent to it.
md5sum is a cryptographic one-way hash function. It's guaranteed to produce a unique number for every unique file (or stream) it is sent.
22 is just the length of the file (in counted lines) minus one or two lines of white space at the bottom of the document (it should span the entire entered code in a given file). 'cat -n' is convenient here to determine what to replace '22' with. ;)
@prime flower if the led animation stuff comes together as I envision it, it'll be trivial to use potentiometers to control a colourloop.
hmm.... there might be something wrong with the non-blocking code I added.. it doesn't seem to work so well in the example code now. it's so strange that it was working so well with no problems and now it's giving me trouble. I'll have to play more with this blocking code and see if something can be made better there
infrared comm is fussy and low bandwidth. ;)
now i'm getting errors like Failed to decode: ('Only mark & space handled',) and Failed to decode: ('Both even/odd pulses differ',)
hmm.. it was behaving so well for a while and now it's really misbehaving. it worked great at the sprint and no it's being problematic. so frustrating.
I usually get my aha moment with at least 15 minutes separation from trying to solve it (and perhaps 25 feet physically from the room where I tried to solve it).
I don't know how I do it. An approach to it just comes to me.
You could try checking the length of pulsein before call the read_pulses function. That is really all the blocking code is doing
thanks for the ideas.. going to poke around with it some more later. my goal is to create something my 2 year old can point at with a remote that doesn't control our tv that will change based on what he presses.
I made a hacky version of this today to change input() to not echo the input data. I think there is another day or two of work required to separate this functionality into getpass the "right way" (not that I'm signing up to do that) but I estimate that an initial version is only about 20 lines of code plus a few configuration lines added per port. Here are some notes; I admit I implemented the easiest version which just changes the behavior of input(), rather than really add a getpass modul...
I gently want to suggest that we revisit the idea of board.I2C(), board.UART(), board.SPI() as implemented recently in PR's #842, #844, and #845. I think it introduces a new, somewhat weak, shortcut API that doesn't work out well if you need to change your program to use different pins. I suggest instead that we add defaults to the pin args for busio.I2C(), busio.UART(), and busio.SPI().
I'll take board.I2C() as an example. It returns a singleton instance that is `busio.l2C(b...
Use UNIX epoch in the time module to match CPython.
This requires long int, so enable that on Express boards which has room for it.
I don't know if I got the long int patch right. Some extra scrutiny would be appreciated.
Ref: #570
executing this code has repeatedly resulted in a corrupted FS with teh current master CP 3.0
It often fails to allocate enough memory, but sometime runs. If it does all seem ok for awhile -then the FS seem to just disappear....
I have reproduced this on a feather_m0_express and on a feather_m0_supersized.
# Initialize and mount SD card of Featherboard adalogger
import board
import busio
import digitalio
import adafruit_pcf8523
import adafruit_sdcard
import storage
import ada...
The FS appears to remain OK until the next soft reboot of the system after execution of the code.
Whe it reboots, the CIRCUITPY drive no longer appears on my Ubuntu linux system- It reamied connected to the REPL but if I then try
import os
os.listdir()
it hangs and I have to physically reboot but the system is no longer responsive and I have to upload the eraser .uf2 to recover.
interestingly - another program that writes to the SDCard runs with no ill effect
import time
import board
import busio
import adafruit_am2320
import adafruit_sdcard
import digitalio
import storage
# can also use board.SDA and board.SCL for neater looking code!
i2c = busio.I2C(board.SCL, board.SDA)
am2320 = adafruit_am2320.AM2320(i2c)
# Connect to the card and mount the filesystem.
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
cs = digitalio.DigitalInOut(board....
I can run this with no problem
jerryneedell@Ubuntu-Macmini:~/projects/feather_m0_express$ cat sdtest.py
import adafruit_sdcard
import busio
import digitalio
import board
import storage
# Connect to the card and mount the filesystem.
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
cs = digitalio.DigitalInOut(board.D5)
sdcard = adafruit_sdcard.SDCard(spi, cs)
vfs = storage.VfsFat(sdcard)
storage.mount(vfs, "/sd")
# Use the filesystem as normal.
with open("/sd/test.t...
Of course I would much prefer the solution proposed here by @dhalbert. Not only will it use less memory when you are not using I2C, not only adding it will result in smaller code size, but also it has the advantage of using an existing Python mechanism, which everybody will have to learn about anyways, instead of being something entirely new created specially for the purpose, which has to be learned separately from the documentation.
causing the FS corruption by executing the code listed in the firs message is very reproducible on a feather_m0_express. I'm confused....
I remove the import dht from the test code and it still causes the same problems.
Sometimes it cannot allocate enough memory an fails.
Sometimes is runs to completion - and corrupts the FS.
Could the problem be due to being very low on available RAM when accessing h SD-Card.Still it is not the SD Card that gets corrupted, it is the CiRCUITPY FS.
one more test case -- running this seems to execute OK and I can do a soft reboot, BUT at the next hard reset/power cycle, the FS is corrupted - I cant even get to REPL
import adafruit_sdcard
import busio
import digitalio
import board
import storage
# Connect to the card and mount the filesystem.
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
cs = digitalio.DigitalInOut(board.D5)
sdcard = adafruit_sdcard.SDCard(spi, cs)
vfs = storage.VfsFat(sdcard)
storage.mount(vfs, "/s...
Wait a minute, filesystem corruption shouldn't affect REPL...
Yikes -- something very odd is going on -- much of the above may be just red-herrings...
I just tried erasing the FS on the feather_m0_express-- load the erase .uf2
then reload CP -- looks good - I get to REPL.
Power cycle and the FS is corrupted again..
I don't know if that's related, but I recently had some problems flashing the uf2 of the master — it would work the first time, but then flashing the same or similar image (with different frozen code) would result in a crash — not even USB or REPL visible — until I flash some completely different image (for example 2.x) and re-flash the master.
What versions of the UF2 bootloader are you both running? See INFO_UF2.TXT in the BOOT drive. You might try updating to the latest with an update-bootloader*.uf2 from https://github.com/adafruit/uf2-samd21/releases
In my case that was on the µGame, so it's my own build of some really old version of the bootloader. Was there some change in 3.x that made it incompatible with the old bootloaders?
UF2 Bootloader v1.21.0 SFHR
Model: Feather M0
Board-ID: SAMD21G18A-Feather-v0
I'll try updating
@deshipu I'm just trying to eliminate some possibilities. Also, the clock code for the SAMD21 was redone about 10 days ago with https://github.com/adafruit/circuitpython/pull/785. If either of you can reproduce the problem consistently, we can bisect to see if that (or something else) is causing a problem.
@tulip sleet that clock redoing is probably the reason why I can't get gamepad to work
updating bootloader did not help - in fact I then loaded current master and I could not even get to REPL or mount the FS.. I reverted to the released alpha6 and it is working fine.
I then reloaded current master and REPL was OK but after power cycle -it is gone again
should I try removing #785?
hmmm -- cant revert it -- not sure what the conflicts are:
jerryneedell@Ubuntu-Macmini:~/projects/adafruit_github/circuitpython_master$ git checkout -b revert_785
Switched to a new branch 'revert_785'
jerryneedell@Ubuntu-Macmini:~/projects/adafruit_github/circuitpython_master$ git revert -m 1 d3a5d40
error: could not revert d3a5d40... Merge pull request #785 from notro/rtc_calibration
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git...
@stuck elbow try reverting that. It may well be. The testing was not that thorough
@solar whale ok, just try going back to the commit before. Not sure what it’s intertwined with.
I will be out for an hour or so soon but then will be back and can take a thorough look.
after trying th above revert - git diff shows:
jerryneedell@Ubuntu-Macmini:~/projects/adafruit_github/circuitpython_master$ git diff
diff --cc ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
index bfa8c64,56e9c8b..0000000
--- a/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
+++ b/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
@@@ -46,15 -46,3 +46,18 @@@
GD25Q16C
#include "external_flash/external_flash.h"
+...
@tulip sleet OK -- will keep trying.
reverted to commit 64bd95ea0155834c2c4313c4137af198890a59bc which was the one previous to merging #785 -- seems to be working OK
And with thsi commit -- the previous issues with writing to the SDCARD are resolved!!!
The case that corrupted the system repeatedly now works.
There have been a lot of commits since #785 that are not in place now, but this is a big improvement!!
PR #785 introduces 3 clock changes:
-
It enables OSC32K: https://github.com/adafruit/circuitpython/pull/785/commits/f21c2494cb612b9f9316ab97096e55ab30a404b4
-
It reworks the samd21 clock setup: https://github.com/adafruit/circuitpython/commit/4adba515695eb4eddf994c6847a5b92cffed6c07
AFAICT this didn't change clock register values. This snippet reverts that change:
diff --git a/ports/atmel-samd/supervisor/port.c b/ports/atmel-samd/supervisor/port.c
index 8e6f2b185..103f39c7...
I tried the changes above on the current master:
jerryneedell@Ubuntu-Macmini:~/projects/adafruit_github/circuitpython_master/ports/atmel-samd$ git diff
diff --git a/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h b/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
index bfa8c64..cfe1919 100644
--- a/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
+++ b/ports/atmel-samd/boards/feather_m0_express/mpconfigboard.h
@@ -47,7 +47,6 @@
#include "external...
@timber mango $ cat -n ./myfile.py | sed 22q | md5sum >> to_append.txtThat's a very cool idea, I had never considered applying a hash to my own code
One case this is designed to ease is initializing multiple I2C devices on the same bus, which is common when using multiple feather wings. With a singleton in board the device drivers can default to the same bus:
d1 = device1.Device1()
d2 = device2.Device2()
With the proposed default args we'd need:
bus = busio.I2C()
d1 = device1.Device1(bus)
d2 = device2.Device2(bus)
The second option does make it easier to change the pins but how common will th...
Enter
Sounds like you are on the right track @paulswirhun. Please make a PR when you have something close and we'll take a look.
Thanks!
Can't we cache the bus, so that creating a bus with the same parameters just gets you the same bus back?
I was composing a message with the same idea the @deshipu just posted.
Suppose busio took care of the singleton? Right now:
i2c1 = busio.I2C(board.SCL, board.SDA)
i2c2 = busio.I2C(board.SCL, board.SDA)
will throw a "Pin xxx in use" right now.
We could have busio.I2C keep track of the pins and return the same object. If this is an issue of upward compatibility, we could have a new SharedI2C class. But I think it's probably fine to create and return a singleton as neces...
@solar whale I will try a bisect to narrow this down to a particular commit. Which example is the most reliable in causing problems?
I don't think you need to run anything -- just load the image and power cycle - that kills it for me.
Feather M0 Express in particular, right? We may not have seen this elsewhere on boards without crystals.
@stuck elbow does uGame have a crystal?
no
hmmm
it seem ok on metro_m4 express
the new clock code is not on m4
ok, I will try a bisect. I have to leave about 1:15 for a school meeting but then will be back 3:30-4.
you mean you can't even get METROBOOT?
I get to METROBOOT - Just no REPL or CIRCUITPyY --- after power cycle
Ok, that's fine with me. I think it'll be a bit tricky because the memory is allocated in shared-bindings and not common-hal.
ok, sounds like some critical clock setting is set by the bootloader but not by CPy, or something like that
any particulat boards you want me to try?
Yes, this would be easier to implement in Python than C :smiley:
@solar whale have you done a bisect before?
As an easier solution, we could cache only the argument-less call.
you could try a gemma or trinket or cpx to see if the crystal makes a difference
prob not based on Radomir's issues, but worth double-checkign
I think my issues are special ;-)
as in, not actually related to this after all
for example, the not-working gamepad is also not working on m4
it almost looks like the tick() function is no longer being called
good news is that it my not be corrupting the FS at all.. just confusing the USB
That might be kind of confusing, since then sometimes a double call would work and sometimes not. I think it might not be too hard to keep track. The I2C objects already keep the pins, so we just have to look over the existing objects. Just have to keep a list of them. We could even use list primitives to manage the storage if we don't want to manage it in a C way on the heap.
trinket_M0 dies after reboot with current master as well.
@solar whale This documentation is good: https://git-scm.com/docs/git-bisect I don't have time to get started before I have to leave, so if you feel like it, go ahead.
ok - I have some distractions for the next hour or so as well, but I'll take a look - thanks
note: the trinket and probably others -- the Dotstar goes white when I connect to the REPL but there is no prompt. After a few 10s of seconds , it drops the connection.
We are already using only a single set of .mpy libs on M0 and M4, without complaint. I think it only comes up if there's actually a longint value compiled into the .mpy file, which hasn't happened yet.
trying bisect
I couldn't find a sd card breakout board to hook up to my feather M0 express, so I tried a M0 Adalogger I had, but I only get: OSError: no SD card
So I'm unable to try and reproduce this :-/
It does not need an SDCARD -- just compile load and start the REPL -- then power cycle and it will fail to boot to the REPL and eventually disconnect the USB port. Its not really related to the SD Card.
Hmm, i wonder if some of that is related to my work on supervisor.reload() and the work to reduce flash size by reducing what pins are defined on trinket_m0 and gemma_m0?
(But I wasn't seeing those symptoms and am not currently on the latest master)
i'll have to test master later.
Oh, I've done all my testing with 'feather_m0_express' and circuitplayground_express and I've never encountered any problems.
I have run run tests for 2 days reading the time every second over raw repl to check for accuracy and never had a hiccup.
I rarely power cycle, but I have done it occasionally to be sure that the clock changes didn't have any ill effects from cold boot.
I am trying to do a "bisect" to find the commit that caused the problem and I think it is well beyond yours. Are you using the current master now?
my attemp at a bisect gas identified this:
2c067edf540fcc1f1f4aa68f0992ce8480a954bb is the first bad commit
commit 2c067edf540fcc1f1f4aa68f0992ce8480a954bb
Author: Matt Land <mland@sparefoot.com>
Date: Wed May 16 15:54:01 2018 -0400
used pins.c instead of README.rst
:040000 040000 05f72a171e17efa3a33447fa3b571af3a2decdb5 2a454fbb36bb964794fd4c5830b2d630851b0f2f M ports
not convinced - tried previous commit to this and it still fails....
narrowing it down -- this commit seem to work 99e34e38eb6a81e0722b31b085c2f24ea1111981
Are you using the current master now?
Yes.
Are you having problems on a Feather M0 Express without any code.py, from cold boot to the REPL?
Or do you get problems after some python code has run first?
and this commit is OK 07c0a3227da24ef92e44a2457f94af71cc7f081c
@notro yes - the problem is on a clean flash - no code.py - I get no prompt from REPL and the hos OS eventually drops the USB connection to it.
but this one fails -- 6a8db03ade64bd2fdf5c7b5df54ad113a062e005
I was just walking up the merged PRs --this was #838
reverted to commit 07c0a3227da24ef92e44a2457f94af71cc7f081c and it seems to be OK - REPL works -- power cycle -- still get REPL and CIRCUITPY
I can still run the sdcard test with out any problem as well
I'm working on Windows 10 and I just did a test connecting the board to a Raspberry Pi and it still worked.
Do you have another computer than the Mac/Ubuntu to test with?
I "tried" removing PR#838 from the current master, but the revert did not work so Idon't trust my resut - with failed but reverting to 07c0a3227da24ef92e44a2457f94af71cc7f081c works consistently.
@notro since my system works on some commits and not others I don't think it is the problem.
Are you using the current master now - or your last commit. I think you last commit is just fine.
I'm using current master:
$ git log --oneline -1
1eb412b44 (HEAD -> test, tag: patchbase, origin/master, origin/HEAD, master) Merge pull request #845 from matt-land/feature-default-serial
just tried build of master - same version as you -- it inatillay boots to REPL after load, then after power cycle it failed on the Ubuntu system, my MACOS system and my raspberry PI.
I'm puzzled!...
Anyone else experiencing issues with paste mode? I get a hard crash to safe mode whenever I try to paste. Metro M0 Express, CP 2.3.1
as on the trinket, I can connect and the Nepoixel goes from green to white, but no REPL prompt..
I'll be off for a bit -- give the channel a break...
@dusk hemlock have you tried writing the code line by line in the REPL to make sure it is paste mode vs the code causing a reboot? We did have to fix paste mode a little in 3.x, but I haven't seen any issues come up with 2.3
@raven canopy aye, pasting "import board" causes a crash
@raven canopy paste works while in safe mode, if I reset the board to go out of safe mode paste mode causes a crash again
Hmm. I can try to replicate & debug later, if no one else can get to it. If you like, you can go ahead post an issue on the repo.
Can you upload a failing feather_m0_express firmware somewhere so I can try it?
This is the one I'm currently trying: http://tronnes.org/downloads/feather_m0_express-firmware.uf2
I'll try with a different serial terminal and/or downgrade circuitPython first
if I'm able to reproduce it I'll post an issue on github
cheers
https://learn.adafruit.com/circuitpython-tv-zapper-with-circuit-playground-express/circuitpython-code-2 "...save this code as main.py on your CPX:"
that should be code.py, right ?
and... is there a more formal place to log issues ?
Or rather it's so small that you can zip it and e-mail it: noralf@tronnes.org
I just tried yours and it seems to work!!! very odd -- send mine in a minute
@teal bear code.py and main.py are both accepted. And the GitHub repo is the "formal" place to file an issue for CircuitPython. For the guides, there is a Feedback/Corrections link on the left side.
ah, got it. um.. how do I find the code that is listed on that page?
the 'eval()' makes me grumpy
The "save this code as main.py" is referencing the code in the code block below it. You can use either the "Download cpx_main.py", "View on GitHub", or "Copy Code". The last two would envolve pasting the code into a file.
And expose the list as busio.buses? That could actually help in debugging when you get errors about used pins and you are not sure where from.
Where is "View on GitHub" ?
First soft reboot after upload gives repl, power cycling gives: Failed to recognize usb device. Same as you.
But now I have the same problem with a new build I just did! What is going on here?
Reverting to the one I sent you, is working.
@notro -- I guess I'm relieved - a bit....
can you reproduce the one you sent me, was it build today or ealrier?
The one I sent you was built 1 hour ago. I'm doing a fresh build now. This is mysterious, I'm starting to doubt my own sanity :-)
I've been doubting mine all day! I made a new clone of the repo this morning and have been working with that. I still can get back to a working version consistently by revering back before PR#838
@teal bear I'm at work, and on my phone, otherwise I'd put up a screenshot. I will say that in order to see all the links for a code block, the browser window needs to be full width/maximized...
@solar whale I experienced the "failed to recognize" error that notro reported, a couple times last now. Power cycle always fixed it. I was debugging, so I thought it was a local/JLink issue.
@tulip sleet when I tried the bisect, it was selecting commits even if they were not merged - in one case it was a commit that failed to compile. Is that expected? I may have confused it by marking the failed compile "bad"
@raven canopy its' odd. In my case it seems to be the power cycle that triggers it....
@raven canopy what board are you using?
@raven canopy thanks found it. did a View Source . not sure why FF isn't rendering it.
I'll be off for awhile -- my head hurst and I need to go for a walk 😉 Maybe it'll all work when I get back ...
@solar whale itsy express. I'll be off too..
This is the strangest thing.
Looks like I've found a reproduceable way of flipping back and forth between working and not working.
I have a build script that creates a git tag when checking out the code so I can easily dump out the commits I've done using git format-patch patchbase..HEAD.
So with that tag I get a firmware that can handle power cycling:
git tagging:
pi@agl:~/circuitpython/workdirs/test/circuitpython$ git tag patchbase
pi@agl:~/circuitpython/workdirs/te...
When the version string changes boot_out.txt is rewritten to include the new version string. The file is read first to see if the string is the same. If the version string doesn't change then it's not rewritten.
Also your tag made the string shorter, though that doesn't seem so likely an issue.
@jerryneedell If you include PR #838 does it fail?
I'd suggest trying multiple times with the same build to see if it fails repeatedly, or whether you're cycling through a "first time only" effect.
@raven canopy @teal bear The code in some guides isn't in the Learn repo and would therefore not have a "View on GitHub" link. I don't know whether that was relevant to this case, but it's information worth having.
@teal bear CircuitPython looks for code.py and main.py in that order. Therefore, if you have both, it will run code.py not main.py. Naming the file main.py is a carryover from lower level programming languages, so we didn't want to eliminate it completely. To make it easier for beginners, we chose to additionally go with code.py because that's where your code lives. 😃
With master on a trinket_m0, this happened to me too. First reboot after flashing was OK. Second boot was not. Starting a bisect too.
That particular code block is on GH, but I know that there are some quirks with how the learn system renders..
Ok, I simply wanted to make sure so you weren't hammering against something that didn't exist.
I've done that too many times 😃
@dhalbert for me once it fails -multiple power cycles does not bring it back.
I have tried writing the failing firmware 3 times without any changes. I've checked that boot_out.txt gets updated.
Can it be some kind of offset problem? The flash size changes for me between working and not working.
What about this warning?
../../shared-bindings/usb_hid/__init__.h:33:23: warning: size of 'common_hal_usb_hid_devices' differ from the size of original declaration [-Wlto-type-mismatch]
extern mp_obj_tuple_t common_hal_usb_hid_devices;
...
@rhooper good idea - now I just need to figure out haw to add a PR to a "detached" branch...
@notro That warning is innocuous: it's a spurious warning due to -flto not knowing how to match an array in a struct properly. It has been fixed upstream.
Wow, it does fail reliably after #838 is merged, which reduces the flash size on trinket_m0 and gemma_m0. I'm going to cherry-pick out all of the reload code in 838 in a branch and see what happens.
@rhooper yes- that is waht I just found adding #838 to my working version causes it to fail. At lest I think that is what I did. I did:
git checkout 07c0a3227da24ef92e44a2457f94af71cc7f081c
this builds a working version
then I
jerryneedell@Ubuntu-Macmini:~/projects/adafruit_github/circuitpython_master/ports/atmel-samd$ git fetch origin pull/838/head:jerryn_test838
From https://github.com/adafruit/circuitpython
* [new ref] refs/pull/838/head -> jerryn_test838
jer...
Another observation is that my main.py was still present when I flashed a good firmware. I have pushed two different branches that revert #838:
- https://github.com/rhooper/circuitpython/tree/no-reload-patch
- https://github.com/rhooper/circuitpython/tree/no-space-savings
However these leave the flash image too big for trinket_m0 and gemma_m0 so I can't test if either of these branches work.
I'm not git-savvy enough to know how to get those commits into my clone of master.
@rhooper you can shrink the image somewhat by uncommenting
## CFLAGS += -finline-limit=50
in the Makefile
@jerryneedell
git remote add rhooper git@github.com:rhooper/circuitpython.git
git fetch rhooper
git checkout rhooper/no-space-savings
Are these flash device only good to 10,000 write cycle ? I may have worn it out today 😉
@jerryneedell or just clone it fresh: git clone https://github.com/rhooper/circuitpython rh-circuitpython or similar
@dhalbert CFLAGS += -finline-limit=50 worked to reduce the image, but still fails to run after a hard reset or reboot. going to seek out the most recent working commit like others.
@rhooper cloned your repo and checked out no-space-savings - it still fails after power cycle on the feather_m0_express
I think I've done enough harm for today -- good luck @ruby atlas -- i'll be off for a few hours and be happy to test more later.
I'm going to do some more bisecting, since I can reliably reproduce.
We love @solar whale's ability to break things!
I'm tempted to rig up a gemma to control the trinket
so i can automate bisecting
but that'll probably take longer than just clicking the button occasionally.
not sure how it's breaking. I built the latest for Metro M0 (so I could debug it with the jlink). If I power-cycle it it still comes back fine. How to reproducee?
my metroM0 failed - let me try again
@tulip sleet for me this works: build master, copy new firmware to it, reboot hard (reset button or powercycle).
i have a simple main.py:
import microcontroller, pulseio, board, supervisor
import adafruit_dotstar, time
pwm1 = pulseio.PWMOut(board.D13, duty_cycle=1, frequency=500, variable_frequency=True)
pixels = adafruit_dotstar.DotStar(board.APA102_SCK, board.APA102_MOSI, 1, brightness=0.3)
n = 0
while True:
pwm1.duty_cycle = 30000
pixels[0] = (128, 128, 128)
ah - in my flow I do a soft reboot after uploading - before power cycling
my test --
build metro_m0_express
copy to METROBOOT
verify REPL is working
power cycle
No response from REPL -- wite light on Neopixel
after a bit, OS drops the terminal session
then I repeat after ```
git checkout 07c0a3227da24ef92e44a2457f94af71cc7f081c
Note: checking out '07c0a3227da24ef92e44a2457f94af71cc7f081c'.
the debug build does not fail; the non-debug build does, it appears 😦
anyway I can do some gdb'ing
ah - those sneaky DEBUG build 😉
@tulip sleet is there a serial port on the trinket or gemma? (I haven't tried yet)
no, I'm wrong it still works both ways
And/or are there gdb instructions I could follow?
you need a j-link or laboriously set up openocd. Do you have a j-link"
back later - have fun!
i do not.
bye - thanks for all the testing!
There is an Edu mini version for 25 ish.
the edu or mini versions are cheaper. Us paid people need the expensive one: https://www.adafruit.com/?q=jlink
ooh i was looking at the segger site
I wasn't thinking about it, I should have had you get one.
with the edu mini, a cable, and a metro you are golden
<shrug> I didn't expect to start debugging pre-boot issues 😃
@ruby atlas here is the link to a useful guide for your bookmarking: https://learn.adafruit.com/debugging-the-samd21-with-gdb
Metro is out of stock at the moment 😃
for boards without the SWD connector, you'd use the SWD breakout board and solder some jumpers to the SWD pins on the bottom of the board. much easier to use metro
so can get a 3571, + 1675 plus the metro
@tulip sleet are you testing on an m0 or m4?
how much more flash does the metro m0 have than the trinket/gemma?
it has the extra 2MB external SPI flash chip. The CPU chip is basically the same (fewer pins).
same internal flash size. On the trinket/gemma we take 64kb of the 256kb flash for a tiny CIRCUITPY. On the Express boards like Metro CIRCUITPY is the 2MB SPI flash chip
(scrolling back to see what boards are known to fail on master)
jerry said he failed with metro. I'll try a trinket
linux
i could try building in a VM.
the build will be the same - if there's an issue it might be the USB port
fwiw i had a Segfault during a -j16 build earlier, but that explains why my desktop crashes randomly.
(time for memtest/cpu burnin tests)
also feather M0 Express failed. that was the original one. I'll try that
ok. i'll keep learning git bisect. (I was manually bisecting before)
if #837 is ok and #838 isn't, may be easier to manually step through them
ok, I get failure on Feather M0 Express with no main.py
backtrace in gdb on metro m0:
#0 0x0001cf30 in HardFault_Handler ()
#1 <signal handler called>
#2 0x0000e30c in validate.lto_priv ()
#3 0x0000e4e4 in f_write ()
#4 0x0002052e in mp_hal_stdout_tx_strn ()
#5 0x0000dc8c in mp_hal_stdout_tx_str ()
#6 0x00020a7a in maybe_run_list ()
#7 0x00021544 in main ()
I need to get the debug build to fail
something not initialized on setup, I bet
is all memory initialized to 0 on hard boot?
NO, in fact the double-click checking depends on the RAM being preserved. a signal value is written on the first click
@slender iron Are you currently working on the newsletter?
nope, just did the one commit
ok. I'm going to add the guides then.
👍
@ruby atlas no luck on getting debug build to fail. I'll take a break and maybe be back in a few hours
i'll try a debug build too. time to eat though 😃
Hmm, what's the standard way to enable debug builds?
@tulip sleet @ruby atlas just build a DEBUG=1 version for feather_m0_express - as noted, it runs ar power cycle, BUT - even though CIRCUITPY is mounted and seen by OS,, the onboaed FS does not see it!! there are several files on my syste one is sdtest.py```Adafruit CircuitPython 3.0.0-alpha.6-142-g1eb412b on 2018-05-18; Adafruit Feather M0 Express with samd21g18
import sdtest
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'sdtest'
import os
os.listdir()
[]
@ruby atlas make BOARD=xxxx DEBUG=1
thanks
make clean first, though 😃
wow, that's quite the flash overflow 😃 region `FLASH' overflowed by 16724 bytes
even wierder - tried DEBUG build on Metro_m0_express - it come up int REPL after power cycle and at firs shows the files but when I try to acces them., they disappear!
Adafruit CircuitPython 3.0.0-alpha.6-142-g1eb412b on 2018-05-18; Adafruit Metro M0 Express with samd21g18
>>>
>>>
>>>
>>>
>>>
>>>
>>> import os
>>> os.listdir()
['.fseventsd', '.metadata_never_index', '.Trashes', 'boot_out.txt', 'oled_test.py', 'jewel.py', 'lib', 'si7021_test.py', 'sgp30_test.py']
>>> import oled_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "oled_test.py", line 6, in <module>
File "adafruit_ssd1306.py", line 34, in <module>
ImportError: no module named 'adafruit_bus_device'
>>> os.listdir()
[]
>>> os.listdir()
gremlins - uninitalized variables -- potato - potado 😉
🥔
just to get this "on the record" DEBUG builds appear to work better, but not so much.
ON a feather_mo_express and Metro_m0_express, I did a DEBUG=1 build of master and at first it seemed to work, but the REPL is not able to acces the FileSystem even though it is visible to the OS as CIRCUITPY. In this case on Metro_m0_express there isa file sdtest.py on the FS and at first is shows up via os.listdir(), but it fails when it tries to load libraries and afterword the FS looks empty.
You c...
thanks for updating that @solar whale (also i have way too many github tabs and windows open)
Good problem to have 😃
@solar whale It seems like there's a bug in the filesystem drivers. I'm having a look at what os.listdir() triggers, slowly chasing the chain.
currently trying to find where mp_state_ctx.vm is initialized
mp_init()
@slender iron I just put in a PR to the Learn repo and it says CI hasn't been setup. Is there something else we have to do to make that happen? Were we waiting for a reason?
probably have to enable travis
Ah ok
I triggered a build: https://travis-ci.org/adafruit/Adafruit_Learning_System_Guides
Excellent
(it'll fail hard)
did it fail as hard as my desktop just did?
Hah! No idea! Oi for you though....
pretty sure it's bad ram.
I got my screenshots for this soil moisture sensor, I should probably water my poor little cacti now.
That'll do it, @ruby atlas
did you get one of the capacitive ones, or is it resistive?
hopefully there's no voltage on the pin? i had a cheap moisture sensor completely dissolve the metal of the exposed trace into the soil on me.
The only plants in the house that aren't in big pots are these tiny little cacti I grew from seeds from a cactus my parents have had for 45 years or something. And I hadn't watered them in ages.
Um... It's reading raw capacitive touch values. There is voltage on the pin, you can test for it using analogio, but I'm not sure it's involved with capacitive touch...
one of these https://www.ebay.com/p/5-Pcs-Soil-Humidity-Hygrometer-Moisture-Detection-Sensor-Module-for-Arduino-W-B3/2159478510?iid=282812332547 dissolved the anode over a few months.
Ah, oi. Not a great result
i don't know that you're at the same risk - but you can probably clean the nail and see if it looks like it's rusting or dissolving.
It's also brass it looks like, or brass plated. It was the only nail we had.
Yeah brass plated steel.
They're supposed to be for mounting pictures to the wall. It's a kit.
i know the ones. tiny little things. 😃
This one has massive ones! Oddly enough
I guess for hanging massive frames.
They're 2 inches long.
There are tiny ones in there too, but it has the bigger ones as well.
Good thing too because those little ones wouldn't have done for this project.
do we have a suggested circuitpython debugging playlist? 😃
😄 We all listen to different things. We were talking about doing something up on Spotify, but we don't all use Spotify either.
I need to retrain my spotify daily picks somehow. it's gotten boring over time.
it seems to be self reinforcing if you keep listening to the daily picks.
That makes sense. I found the same with Google if I listened to stations from songs I liked, it eventually became all the same things.
I'm listening to an electronica stream from Soma.fm. That's my focus music.
Someone else is probably still bingeing on the Wicked soundtrack. All depends on what you're into 😃
i had soma's space station on earlier, and before that secret agent. moved on to apple's alternative radio station for now.
I'm listening to The Trip
It's always surprising to me when I find people who know Soma... that's awesome 😃
oh that's one I hadn't listened to before. liking it!
Nice!!
currently looking for where in the startup sequence the usb mass storage device is started.
since in the failure mode that doesn't start up for me.
Hello, I just bought https://www.adafruit.com/product/3405 I'm not entirely sure if this is compatible with circuitpython. Can anyone help?
There isn't currently support for the HUZZAH32 in CircuitPython.
So I've been digging, and added a new dotstar colour before reset_port() in main.c, and the am using that to isolate the crash.
Nice
print-debugging, in glorious colour
best way to do it
is there a way, while a circuitpython board is plugged in via usb, to have it respond to input from a keyboard or mouse? essentially, can the board act as a keylogger?
After spending a lot of time doing print-debugging using colours on the dotstar on trinket_m0, the hang is during maybe_run_list() during
mp_hal_stdout_tx_str(filename);
bool maybe_run_list(const char ** filenames, pyexec_result_t* exec_result) {
const char* filename = first_existing_file_in_list(filenames);
if (filename == NULL) {
new_status_color(RED);
return false;
}
new_status_color(BLUE);
mp_hal_stdout_tx_str(filename);
...
well, i'm at a loss as to why mp_hal_stdout_tx_str() would hang now but not before.
hmm.
I'm unlikely to be much help here.
btw you can make inline code by surrounding it with a single backtick ` (upper left corner of a US keyboard) on either side or a codeblock with three backticks on either side.
i had 3 or 4 lines pasted before I removed them, and was too lazy to change the block quote to inline
i love that markdown inline and block quotes are almost everywhere
okay time to try printing a clear abs gemma case
Ooh nice
Also, commenting out
mp_hal_stdout_tx_str(filename);
mp_hal_stdout_tx_str(MSG_OUTPUT_SUFFIX);
Fixed my gemma_m0 and trinket_m0
also filename is valid.
new_status_color(CYAN);
if (strlen(filename) > 1000) {
new_status_color(RED);
} else if (strlen(filename) > 500) {
new_status_color(GREEN);
} else if (strlen(filename) > 250) {
new_status_color(BLUE);
} else if (strlen(filename) > 125) {
new_status_color(ORANGE);
} else if (strlen(filename) > 50) {
new_status_color(YELLOW);
} else if (strlen(filename) > 25) {
new_status_color(BLACK);
} else if (strlen(filename) > 10) {
new_status_color(WHITE);
} else if (strlen(filename) > 5) {
new_status_color(PURPLE);
}
mp_hal_stdout_tx_str(filename);
``` stops at PURPLE
I need more colour constants for more debugging!
Sounds like someone needs to make more colour constants.
I suppose we could import some of the webby ones. https://docs.mql4.com/constants/objectconstants/webcolors
those aren't actually the web ones, but I liked the layout
I wonder if it because the code is calling mp_hal_stdout_tx_str(MSG_OUTPUT_SUFFIX); when filename is null
I have a longer list of constants in a piece of code I wrote, but it's all relative. They're what I thought fit the colors I listed 😃
the filename is not null.
#define MSG_OUTPUT_SUFFIX " output:\r\n"
it was between 5 and 10 characters 😃
what was the filename?
my guess is main.py 😃
which matches that last case.
(and is what's on my device)
testing mp_hal_stdout_tx_str("1234.67");
also there's a check in maybe_run_list() that returns false if (filename == NULL) right up top.
new_status_color(RED);
return false;
}
new_status_color(CYAN);
mp_hal_stdout_tx_str("1234.67");
new_status_color(YELLOW);``` hangs on CYAN
i'm really loving this colour based debugging. ALL boards by everyone should have neopixels or dotstars.
No neopixel Emoji?
this reminded me of an issue a few days ago with the boot_out.txt creation.
this change creates a working version on the metro_m0_express:
diff --git a/ports/atmel-samd/mpconfigport.h b/ports/atmel-samd/mpconfigport.h
index 27c2480..589a7e1 100644
--- a/ports/atmel-samd/mpconfigport.h
+++ b/ports/atmel-samd/mpconfigport.h
@@ -280,6 +280,6 @@ void run_background_tasks(void);
#define MICROPY_VM_HOOK_RETURN run_background_tasks();
#define CIRCUITPY_AUTORELOAD_DELAY_MS 500
-#de...
so not creating the boot_out.txt file fixes it ??
also good on feather_m0 _express
and trinket_m0
@ruby atlas with that line commented out, it still runs maybe_run_list()
Commenting out
/#define CIRCUITPY_BOOT_OUTPUT_FILE "/boot_out.txt"
skips the attempt in main.c to create an the boot_out.txt file.
It still looks like something is hanging up the filesystem when trying to create the boot_out.txt file.
goodnight all!
Night @solar whale, have a good one !
catching up. my pandora is pretty much stuck on my Bassnectar radio. at this point, it rarely plays a non-thumbed song. but when it does, its usually a spot-on pick. 😄
@solar whale >> Are these flash device only good to 10,000 write cycle ? I may have worn it out today
500 writes per day, working 24 hours a day, averaging 3 minutes distance between writes.
24 * 3600 = 86400
86400 / 180 = ~500 (480)
Twenty four hours a day, times 3600 seconds per hour, is 86 thousand and 4 hundred seconds per day!
Divide that by 3 minutes (180 seconds) gives 480 iterations a day, at 3 minute intervals.
To wear one out (86,400 / 10,000) you'd have to reduce your iterations to 8.64 seconds per iteration! (not possible).
Also I think 10k would be a very low figure.
min. 20k typical 100k endurance erase/write for C8051F330D which has 8kb flash and is quite a few years old (< 2004)
>>[00:44 UTC] @radiant lichen : is there a way, while a circuitpython board is plugged in via usb, to have it respond to input from a keyboard or mouse? essentially, can the board act as a keylogger?
(let's toss out 'or a mouse' for this .. I have no idea how to do that)
For Arduino IDE that'd be Serial.read(); and I have used it -- works as expected (acquires keyboard input).
Not sure how this is done in CircuitPython, but the hardware can certainly do this.
You are basically using the target board to listen for serial input (via the USB port).
You won't be plugging a USB keyboard into the target board to use Serial.read() but instead will plug the target into a host PC as usual (standard USB cable).
Oddly enough it seems you can go the other way, and emulate a USB keyboard (or mouse) with specific target boards. Look for the term 'HID' to find out more about this capability.
I would think a true keylogger is inserted inline with a USB keyboard, to acquire keystrokes as well as pass them through to the host PC.
I think I have a fix. In main.c, change this:
#ifdef CIRCUITPY_BOOT_OUTPUT_FILE
if (!skip_boot_output) {
f_close(boot_output_file);
filesystem_flush();
boot_output_file = NULL;
}
to this:
#ifdef CIRCUITPY_BOOT_OUTPUT_FILE
if (!skip_boot_output) {
f_close(boot_output_file);
filesystem_flush();
}
boot_output_file = NULL; // This line moves outsi...
FrequencyIn success!!! up to 512kHz before REPL stops responding...
hmmm. i wonder if pushing the prescaler up will help....
@dhalbert this appears to be a good fix!
It's an embarrassing bug on my part. I reworked that code for the power fix after a couple of long days. It has been broken for a while, but invisibly. Something about the recent merges made the garbage data in the file descriptor more likely to cause a hard fault.
I've got a FrequencyIn core module working!
Using the same PWMOut script as above, I'm now getting up to 512kHz before the REPL locks up. Using this script to capture the frequency in:
import board, pulseio
tc = pulseio.FrequencyIn(board.D7)
while True:
if (tc.value > 0):
freq = 48000000 / tc.value // currently only working on SAMD21
print(freq)
I have the TC prescaler set to 1 right now, and I think it may be hitting max COUNTER. Will continue to d...
boot_output_file was not set to NULL after if boot_out.txt did not need to be written, so running code.py would try to write to boot_out.txt with a file descriptor that had junk in it. Usually this caused no problem, but recent merges apparently made this more likely to cause a hard fault.
2.x version of #848.
This didn't actually cause 2.x crashes, but it's still wrong and needs to be fixed.
It was a pleasure to watch this debugging session, you guys rock!
Nice work @dhalbert , @rhooper and @notro -- this was a tricky one - sorry for all the misleading information at the start.
I have tested PR #848 on trinket_m0, feather_m0_express and metro_m0_express -- alll working fine after power cycle and all boot_out.txt files updated.
@timber mango Thanks for the info! That's unfortunate that there isn't a way to do this with circuitpython. I wanted to make an LED matrix that would light up according to keystrokes as bling for my laptop.
I must have missed something regarding audioio on CP 3.0 -- I t looks liek the aruments to audioOut have changes so it now just takes one argument for the Pin. I am tryin to play a small .wav file on my CPX here is the code ```
import board
import audioio
import digitalio
Required for CircuitPlayground Express
speaker_enable = digitalio.DigitalInOut(board.SPEAKER_ENABLE)
speaker_enable.switch_to_output(value=True)
f = open("WhoHitMe.wav", "rb")
a = audioio.AudioOut(board.A0)
print("playing")
a.play(f)
while a.playing:
pass
print("stopped")
but I get this errorAdafruit CircuitPython 3.0.0-alpha.6-143-g990da6d on 2018-05-19; Adafruit CircuitPlayground Express with samd21g18
import audio_test
playing
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "audio_test.py", line 13, in <module>
RuntimeError: Unable to allocate buffers for signed conversion
this still works under 2.3.1 ```import board
import audioio
import digitalio
Required for CircuitPlayground Express
speaker_enable = digitalio.DigitalInOut(board.SPEAKER_ENABLE)
speaker_enable.switch_to_output(value=True)
f = open("WhoHitMe.wav", "rb")
a = audioio.AudioOut(board.A0, f)
print("playing")
a.play()
while a.playing:
pass
print("stopped")
@jerryneedell The problem is that mp_hal_stdout_tx_strn() (called by mp_hal_stdout_tx_str()) would try to write to boot_out.txt via the (bad) file descriptor boot_output_file. This would either happen immediately when main.py or code.py was being run, or if they didn't exist, when you entered the REPL and the REPL started printing things. So a bad write would happen sooner or later. Since this was kind of a second-order bug, the different place where it could occur further confuse...
@solar whale The API changed so that the AudioOut isn't tied to just one file. Here's the new documentation: http://circuitpython.readthedocs.io/en/latest/shared-bindings/audioio/AudioOut.html.
@tulip sleet ah missed the audio.WaveFile
now it will play wav files or play a raw in-memory sample
also note new .pause() and .resume() functionality
requested by Phil for a robot demo, and Scott was able to implement quickly
hmmm ```Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 3.0.0-alpha.6-143-g990da6d on 2018-05-19; Adafruit CircuitPlayground Express with samd21g18
import audio_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "audio_test.py", line 9, in <module>
TypeError: file must be a file opened in byte mode
forimport board
import audioio
import digitalio
Required for CircuitPlayground Express
speaker_enable = digitalio.DigitalInOut(board.SPEAKER_ENABLE)
speaker_enable.switch_to_output(value=True)
f = audioio.WaveFile("WhoHitMe.wav")
a = audioio.AudioOut(board.A0)
print("playing")
a.play(f)
while a.playing:
pass
print("stopped")
@tulip sleet I think the docs need an update - this works ```
import board
import audioio
import digitalio
Required for CircuitPlayground Express
speaker_enable = digitalio.DigitalInOut(board.SPEAKER_ENABLE)
speaker_enable.switch_to_output(value=True)
data = open("WhoHitMe.wav", "rb")
f = audioio.WaveFile(data)
a = audioio.AudioOut(board.A0)
print("playing")
a.play(f)
while a.playing:
pass
print("stopped")
the file has to be opened with "rb" then passed to audio.Wavefile -- passin gthe filename to audioio.wavefile (as in the docs) does not work.
it is documented in https://github.com/adafruit/circuitpython/blob/master/shared-bindings/audioio/WaveFile.c#L61
Am I doing something wrong here or is this an issue?: test code for CP3.0 ```buttonA = DigitalInOut(board.BUTTON_A)
buttonA.direction = Direction.INPUT
buttonA.pull = Pull.DOWN
buttonB = DigitalInOut(board.BUTTON_B)
buttonB.direction = Direction.INPUT
buttonB.pull = Pull.DOWN
The two files assigned to buttons A & B
audiofiles = ["rimshot.wav", "laugh.wav"]
def play_file(filename):
print("playing file "+filename)
with open(filename,"rb") as f:
wav = audioio.WaveFile(f)
with audioio.AudioOut(board.A0) as a:
a.play(wav)
while a.playing:
pass
print("finished")
while True:
if buttonA.value:
play_file(audiofiles[0])
if buttonB.value:
play_file(audiofiles[1])
works 3 times then errorsAdafruit CircuitPython 3.0.0-alpha.6-143-g990da6d on 2018-05-19; Adafruit CircuitPlayground Express with samd21g18
import audio
playing file rimshot.wav
finished
playing file laugh.wav
finished
playing file rimshot.wav
finished
playing file laugh.wav
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "audio.py", line 35, in <module>
File "audio.py", line 30, in play_file
File "audio.py", line 26, in play_file
RuntimeError: All timers in use
I think is an issue -- same basic thing works under 2.x
@solar whale go ahead and file issues for the doc and the timer problem. Exactly the kind of testing we need
on CPX with current master
The following code executes 3 times then works on the 4th try:
buttonA = DigitalInOut(board.BUTTON_A)
buttonA.direction = Direction.INPUT
buttonA.pull = Pull.DOWN
buttonB = DigitalInOut(board.BUTTON_B)
buttonB.direction = Direction.INPUT
buttonB.pull = Pull.DOWN
# The two files assigned to buttons A & B
audiofiles = ["rimshot.wav", "laugh.wav"]
def play_file(filename):
print("playing file "+filename)
with open(filename,"rb") as f:
...
The documentation for playing a file from flash in:
https://github.com/adafruit/circuitpython/blob/master/shared-bindings/audioio/AudioOut.c#L83
needs to be updated to be consistent with
https://github.com/adafruit/circuitpython/blob/master/shared-bindings/audioio/WaveFile.c#L61
the first one gives an error while the second one works but it is the first one that is seen in ReadTheDocs:
http://circuitpython.readthedocs.io/en/latest/shared-bindings/audioio/AudioOut.html
Example of e...
1d9bcc5 fix doc error in audioOut.c - jerryneedell
My quick thoughts, after spending the last couple weeks in the timers, are that they aren't being deinitialized after with audioio.AudioOut(board.A0) as a:. M0 only has 3 timers, which is why it would fail after the third file.
I think I have confirmed my thoughts.
During common_hal_audioio_audioout_deinit, only the event channel is disabled. There is no call to turn_off_clocks(self->tc_index)...
runs to check his FrequencyIn deinit to make sure the clocks are being turned off 😄
they weren't 🤦
Twofer
yep. gotta update the comment though (or build a turn_off_clocks function)...
forgot that all that's available in timers.c is tc_set_enabled(false) and tc_reset.
To amend my earlier turn_off_clocks statement, that function is not available.
However, tc_set_enable(self->tc_index, false) and tc_reset(self->tc_index) are available.
Would we want to do a full TC.SWRST with tc_reset on deinit? (SWRST sets the TC back to default config, and turns it off).
@tulip sleet Great brain dump, slowly adding to it.
i should wait until the coffee starts to work before commenting and coding... ☕
luckily there are compilers that are smarter than me. 😄
Figured out that this works: cpx.pixels.auto_write = False which is handy.
worth documenting
@tulip sleet It'll at least be going into the guide I'm working on. Used it in an example. Redid the NeoPixel-range light-sensor code with the cpx lib.
Redid the sound sensor code too, though it doesn't tighten it up much.
Might still include it.
@slender iron thanks for the reviews!
I may do the caching of the busio objects next. That will partially undo board.I2C(), etc.
Should we add the mic to the cpx lib for the purpose of returning a magnitude value? So this bit would be included in something like cpx.mic_samples or something mic = audiobusio.PDMIn(board.MICROPHONE_CLOCK, board.MICROPHONE_DATA, frequency=16000, bit_depth=16) samples = array.array('H', [0] * 160) mic.record(samples, len(samples))
Plus the noramlised_rms function so it returns a magnitude of the samples.
Then you could print(cpx.mic_magnitude) or something.
@tulip sleet This math.pow(10, 2 * -0.1) will always return the same thing, correct? As in it's not a range of math, it's a single equation that results in a number. (0.630957 according to the REPL) I want to make sure I'm not missing something with how that works.
right no vars in there, so hoist it out of a loop if it's in a loop
ok
You had variables in it in the original code, this is for beginners so I'm limiting what can be changed and therefore what must be explained.
MakeCode has a "loud sound" conditional. that's really simple. a numeric value might be useful too
works if you clap, or blow into the mic
The Girls Who Code used it quite successfully
but if the idea is to be able to program the soundmeter with cpx lib, then a value would be good too
oof. back to the datasheets, unfortunately. i refuse to accept 512kHz as the upper bound! well, at minimum i have to figure out how to catch the upper bound and bail. 😄
@tulip sleet Are the MICROPHONE_CLOCK and MICROPHONE_DATA pins used for anything else? As in do I need to do anything fancy with init because it might get a pin in use error later?
Or can I init it like anything else and be fine.
they are dedicated pins connected solely to the microphone, so no sharing, so you should be fine. Like SPEAKER_ENABLE, etc.
ok keen thank you
Oh snap I did it.
(Sorry I'm still utterly amazed when I manage to do this stuff.)
saddened that there is no :snap_fingers: so...you have earned a 🌮!!! that is one of the best feelings though, isn't it. grats!
It is! Thank you!!
import array
import audiobusio
import board
import math
def normalized_rms(values):
minbuf = int(sum(values) / len(values))
return math.sqrt(sum(float(sample - minbuf) * (sample - minbuf) for sample in values) / len(values))
mic = audiobusio.PDMIn(board.MICROPHONE_CLOCK, board.MICROPHONE_DATA, frequency=16000, bit_depth=16)
samples = array.array('H', [0] * 160)
mic.record(samples, len(samples))
while True:
mic.record(samples, len(samples))
magnitude = normalized_rms(samples)
print((magnitude,))
Is now
from express import cpx
while True:
print(cpx.magnitude())```
says it all...
Well played @raven canopy
@tulip sleet In MakeCode, the loud sound thing, does it only respond once? because if I blow on the mic it prints a bunch of times because there's no delay. Or do you even have any idea. As in, do I need to make it into a sort of state machine or do we leave that to the code to do that, or add a delay in the code if you want it to only respond once
Right now it's kind of like touch, where if it's touched, it's returning a value.
So right now, if I blow on the mic, as long as the magnitude is above the threshold, it's returning true
Typically in MakeCode you run something that takes time (like play a tune or do an animation), so it gets triggered and then doesn't get checked again until the thing is done
Right ok
I'll leave it without a delay because this works in a super cool way: ```python
from express import cpx
while True:
if cpx.loud_sound(sound_threshold=200):
cpx.pixels.fill((50, 0, 0))
else:
cpx.pixels.fill(0)```
Blow on the mic and the lights are on the whole time
oh, I like the option argument
Super handy
It'll default to 200 I think, but I had it at 100, was too reactive
so I set it in the code because I haven't moved the updated express.mpy over yet
was still tweaking.
from express import cpx
import array
import math
def constrain(value, floor, ceiling):
return max(floor, min(value, ceiling))
def log_scale(input_value, input_min, input_max, output_min, output_max):
normalized_input_value = (input_value - input_min) / (input_max - input_min)
return output_min + math.pow(normalized_input_value, 0.630957) * (output_max - output_min)
def normalized_rms(values):
minbuf = int(sum(values) / len(values))
return math.sqrt(sum(float(sample - minbuf) * (sample - minbuf) for sample in values) / len(values))
samples = array.array('H', [0] * 160)
input_floor = normalized_rms(samples) + 10
# Lower number means more sensitive - more LEDs will light up with less sound.
sensitivity = 500
input_ceiling = input_floor + sensitivity
peak = 0
while True:
print(cpx.magnitude())
c = log_scale(constrain(cpx.magnitude(), input_floor, input_ceiling),
input_floor, input_ceiling, 0, 10)
cpx.pixels.fill((0, 0, 0))
for i in range(10):
if i < c:
cpx.pixels[i] = (i * (255 // 10), 50, 0)
if c >= peak:
peak = min(c, 10 - 1)
elif peak > 0:
peak = peak - 1
if peak > 0:
cpx.pixels[int(peak)] = (80, 0, 255)
cpx.pixels.show()
Sound meter.
normalised_rms is already in the lib.
Unsure about adding to the lib though. It's neat, but it's not really a "feature of the board" per se.... it's more a fancy project using a feature of the board. How would you include the sound_meter in another project? Not sure you would.
I think I'll include it in the guide I'm doing though.
hmm...Voice Activated Recorder? not going to get a long recording, but it's possible.
Eh we thought about it and no. The recordings it does are iffy at best. You can hear clicks and taps but nothing discernible.
ahhh.
Yeah. And you get about 1.5 seconds I think.
The functionality is there, but it wasn't worth it
the buffer is so small
You wouldn't be able to do anything else.
security alarm (like a glass break sensor) is about the only other thing that comes to mind... adabox 007 style.
Right, but you can use magnitude() for that
You don't need the entire sound_meter code
Was my point.
cpx.sound_meter() would simply the board lighting up to sounds .
not workable into something else really.
cpx.magnitude() and cpx.loud_sound() I'm adding
you're making this difficult. 😆
another That 70's Show episode just popped in my head. anywho. gcc throws me an "unused variable" warning even though i named the variable garbage. too smart for its own good. 😄
zactly
@tulip sleet Are either of these @propertys:```python
def magnitude(self):
self._mic.record(self._samples, len(self._samples))
return self._normalized_rms(self._samples)
def loud_sound(self, sound_threshold=200):
if self.magnitude() > sound_threshold:
return True
I'm still unclear on what makes something a property. I did figure out something else was a @staticmethod
oh lol that's what makes it one? I knew that part
I wasn't sure if they were actually properties or not
Some of the other things in the lib don't have the property decorator on them
i think she's asking "when is something a property, and when isn't it"?
err...considered a property.
it's a property if it looks like a regular attribute .foo but is implemented as a def (or two defs if there's a setter). It doesn't take arguments, so no parens.
I'd use a more specific term than magnitude(), which could mean magnitude of a bunch of things, not just sound magnitude. like .audio_level or .sound_level
is that what you're asking?
Yes. I give them both property decorators and the code fails, so I'll keep testing.
and I agree on name
yeah, so just say cpx.magnitude, not cpx.magnitude(), when you add the @property
it doesn't like loud_sound being a property
cause it can take an argument (even if optional), so it's just a function
it's the average of the values in the buffer. I'm not sure why it's called minbuf!
ok
ok lint time!!!!
I'm getting this error Either all return statements in a function should return an expression, or none of them should. on this function def loud_sound(self, sound_threshold=200): if self.sound_level > sound_threshold: return True
I think Scott always has an answer to this one
something about returning something different.... I don't remember
else:
return False
or maybe he always wanted them to return True ?... I'm forgetting
oh
no that's maybe what Scott always tells me not to do because it's implied?....
could also be:
def loud_sound(self, sound_threshold=200):
return self.sound_level > sound_threshold
much cleaner! thanks Dan.
Yep I knew it was something about the returning True that wasn't right. Thank you!!!
satisfied Your code has been rated at 10.00/10 (previous run: 9.95/10, +0.05)
Because pylint is holding out on us.
"We are SPINAL TAP!"
if it will give negative scores it can give extra credit
does clapping trigger loud_sound?
yep
great
I'm looking for the original soundmeter code to see why it was called minbuf. I think calling it average or avg would be better.
I called it mean_values
just now when I updated it
I can refactor to average if you like that better
average or mean is fine, whichever you think is clearer. I could update the example in the CPX Guide.
I was thinking of including this version of it in the guide I'm doing now for the cpx lib
but I can link it instead
Or are you talking about only that part of it
from express import cpx
while True:
print(cpx.sound_level)
if cpx.loud_sound():
cpx.pixels.fill((50, 0, 0))
else:
cpx.pixels.fill(0)
Prints the magnitude, and also turns red when you clap or blow on the mic.
Right I knew what you meant. Did you mean updating the code completely? Or just that variable
I ask because none of the code there uses the cpx lib (for the most part) and my plan was to include the examples in my guide written with the cpx class
well at least for the sound meter and the light meter.
There's code in the repo for all of those examples that have equivalents in the cpx lib. It was never used for anything. Which is fine because I think it should be centralised anyway, and not sporadically spread through the main guide.
Either way works, I won't put anything into the new guide that's an exact duplicate, I'll link it instead.
@raven canopy Hey buddy........... how's it going?
Do you know how to run sphinx now? cringes
Because the command I have from before isn't running because, I'm assuming, of directory structure changes
run? like local? negative... Travis is my buddy. 😄
belated lunch time! ttfn.
Yeah only sort of figured it out, but it builds. Obviously it's changed. Need to find out about that on Monday.
@idle owl sorry, on and off the computer. I meant just the variable. Also I don't remember if I fixed the overflow problem in that particular example or not. ... will be off for the evening now
Ok. I'll hang onto the PR then. See if anyone wants to test it first.
So FYI anyone with a CPX who wants to test some code for me, let me know.
I'm experiencing strange behaviour with REPL in paste mode. After an arbitrary period of time, pasting anything while in REPL paste mode will crash the board and bring it back up in safe mode.
While in safe mode, paste mode works without an issue. Resetting it back to normal mode, paste mode will crash it to safe mode every single time. Typing in 4 characters will cause a crash. The crash will occur while typing in the 4. character. CTRL-C or CTRL-D will cause a crash immediately.
Cycli...
@idle owl I can do some later this eveining and tomorrow - Do you want it tested on 2.x or 3.x or both
I'll be off for a few hours so just send me info on what you want tested.
@solar whale Both I would say. It's a change to the Express class cpx lib, but it'll be frozen into both
It's frozen in right now, so to avoid it using the frozen module vs the one you put on the board, put the express.py file into /lib and then use the following code:
from express import cpx
while True:
print(cpx.sound_level)
if cpx.loud_sound():
cpx.pixels.fill((50, 0, 0))
else:
cpx.pixels.fill(0)
Here's the lib .mpy file:
Instead of the full from adafruit_circuitplayground.express import cpx which will use the frozen version.
should print magnitude (cpx.sound_level) and turn red when you clap or blow on it (loud_sound)
Is that 2.x mpy ? Can you post the .py
Thanks. Will try it tonight
Thank you!
Hmm. Wonder why touchio isn’t part of 3.0.
I saw the issue for it but ran out of time to figure out why it’s not in the build 😃
That's why 😄 We figured it was a bit much to try work on at the sprints, so it wasn't included in the list that we were working with then. 😃
New new to python and micro controllers. I have a trinket m0 and an OLED 128x32 I2C (https://www.amazon.com/gp/product/B074VDTYJR/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)
and can't get it running. Installed updated CircuitPython, and I think all the libs (busdevice, register, ssd1306, & framebuf), but no luck. Even
busio.I2C.scan()
returns
>>>
>>> busio.I2C.scan()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'busio' is not defined
>>>```
Amazon.com: [inteq] 2-Pack I2C IIC 0.91” OLED LED LCD Display Screen 128x32 For Arduino ESP32 STM32 (White): Computers & Accessories
You need to import the busio library first. >>> import busio
Once you have the libraries installed, you have to import them to use them.
hmm maybe I don't have the lib
Check out this page for more details on I2C and CircuitPython: https://learn.adafruit.com/circuitpython-essentials/circuitpython-i2c#find-your-sensor
yep, that's where I've been at for 2 days
Ah ok
>>> busio.I2C.scan()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: function takes 1 positional arguments but 0 were given
>>> ```
You can't simply call the scan. You have to do it like the code in the link I sent you. You can do it from the REPL but it needs to be done in that manner.
You have to tell it where to look first.
guess I have a fundamental misunderstanding of some basic python syntax?
If I understand it correctly, it's not smart enough to know where to look if you don't give it a place to start. That's what the i2c = busio.I2C(board.SCL, board.SDA) is doing. Telling the code that those are the I2C pins your sensor (or display) is going to use.
It's possible that you're misunderstanding basic syntax, but it seems like you're on the right track. It's more that you're not including some important steps in your code.
>>> import busio
>>> import board
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> while not i2c.try_lock():
... pass
...
...
...
>>> print("I2C addresses found:", [hex(device_address) for device_address in i2c.scan()])
I2C addresses found: []
I don't have anything on I2C.
So as long as you have it hooked up to the pins on your board that work for SCL and SDA, it should return an address like [0x39] or something like it.
oh, you're supposed to run in from a file? I thought it said to do it from RE
PL
I did that from the REPL.
is there a single place that I can see what is built onto an board and pointers to the libraries for those built in things? For example, I have a circuit express and want to know how to use the buttons and temperature sensor.. how would I know what libraries to use?
@chilly juniper https://learn.adafruit.com/adafruit-circuit-playground-express/circuitpython-playground
@zealous frigate But you can run it from a file if you wanted to, and have it print to the serial output. But I did that from the REPL. That's directly pasted from my REPL output.
if you close the REPL window... do you have to reload the libs?
Yes, the REPL isn't persistent.
@idle owl that is awesome, thanks!
@chilly juniper Sure thing!
That's a good place to try from 😃
side question, in normal CLI I can type "clear" to get a fresh looking window... this a thing within Mu? or just reload it?
@chilly juniper I think that covers most of it. There's also a lib designed to make it all easier to use, it does all of the setup in the background. You import the lib and it's a few lines of code to get going. We don't have a guide yet for it (working on it now) but here's the API documentation for it. It's built into the current version of CircuitPython. https://circuitpython.readthedocs.io/projects/circuitplayground/en/latest/api.html
@zealous frigate I don't think it's a thing within Mu, no. Reload it and re-enter the REPL.
k, thanks
@idle owl i likey. this is even better in some respects. thanks
@chilly juniper Thanks. I wrote it 😊
oh, one more thing.. is there a way to set the brigness on individual pixels? it looked like you could only set the brightness on all of them at the same time.. I'm sure I'm missing something
I don't think you're missing anything. We set individual brightness by assigning a pixel a lower RGB number, I think. I just tried to set it on a single pixel and it returns an error. So if you wanted a pixel half brightness, you'd do pixel[1] = (125, 0, 0) which would be half bright red. It's not great. I think DotStars have a special extra bit that allows for it, but NeoPixels don't.
i tried doing that and it didn't work so well.. i didn't see a clear reduction in brigness. I'll try again with it being set super bright and see.. there is some reduction, but it doesn't seem to be as proportional as you would think.
if i really care, i'll dig into the code more and see if it's something that is able to be set and supported by the hardware or if it's just a code thing.
Yeah, I agree. It's all in human perception I think. If you set them to full brightness and then assign it (0, 10, 0) it is obviously dimmer, but doesn't seem like 10/255ths of the original brightness.
there was some reduction in brighness, but just not as much as you would expect based on how I changed the values.
I did a project with sparkle code, and I divided the current brightness by // 2 and // 10 to get dimmer pixels. It affected random pixels as it went (to get the sparkle affect). It was fairly obvious, but again, I'm not sure about it being half or 1/10th the brightness really.
i guess i would need a light meter or someting to see if it is really doing 10/255th brightness.. it might be, but I just can't distinguish with my analog eyes. 😉
Distinctly possible 😃
progess, up till here... my guess is I'm not supposed to have so many dots?
...
...
...
...
...
... import adafruit_ssd1306
... oled = adafruit_ssd1306.SSD1306_I2C(128, 32, i2c)```
ooops
You needed to add another paren 😃
seen as sent
IT BLINKEDDDDD!!!!
Yay!!
dido. I would like to test another identical screen, would I cycle power to do that? ie, is hotswapping a bad idea?
Hmm... I'd always recommend powering down, just in case something touches where it shouldn't and shorts.
will do
@idle owl the loudness code with express.mpy works fine on CPX 2.3.1
@idle owl expected thsis problem on 3.0 - --- lis3dh uses ucollections, but on 3.0 it is collections lis3dh needs to be updated ```Adafruit CircuitPython 3.0.0-alpha.6-143-g990da6d on 2018-05-19; Adafruit CircuitPlayground Express with samd21g18
import loud
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "loud.py", line 1, in <module>
File "express.py", line 43, in <module>
File "adafruit_lis3dh.py", line 36, in <module>
ImportError: no module named 'ucollections'
loud.py is just your test code ```from express import cpx
while True:
print(cpx.sound_level)
if cpx.loud_sound():
cpx.pixels.fill((50, 0, 0))
else:
cpx.pixels.fill(0)
@idle owl I tried some simple fixes for 3.0 , but I have not been able to get it to work
ah -- it imports touchio - which is not available -- I tried fixing lis3dh, but also had to play with sys.pat and all it did was hang my system when I tried it. no error messages - just hung 😉
I think it is not ready for 3.0...
I can't wait to muck around with a CPX.
@idle owl I was able to workaround the lis3dh issue but then it has some audioio calls that are not compatible with the 3.0 API ```Adafruit CircuitPython 3.0.0-alpha.6-143-g990da6d on 2018-05-19; Adafruit CircuitPlayground Express with samd21g18
from express import cpx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "express.py", line 774, in <module>
File "express.py", line 104, in init
TypeError: extra keyword arguments given
and that was just before a bunch of touchio stuff. I think 3.0 will have to wait for touchio but it will need some work on the audioio and audiobusio stuff.
@ruby atlas the CPX is a great device. packed full of toys!
it's funny. I have two CPXes, and neither have been used yet. i've stayed in debug land for too long.. 😄
There are SWD pads on the back 😉
but i don't have a biscuit (yet). i do have alligator->male jumpers though. 🤔
looking forward to a CRICKIT
hehe. 🕳 🐇
Hmm... I thought we froze it into 3.0 already
froze express.py?
its frozen into 3.0, but it does not work 😉
Ah ok. We did not think that through then. 😄
here it is:
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_BusDevice
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_CircuitPlayground
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_HID
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_LIS3DH
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_NeoPixel
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_Thermistor
good question!
didn't mr mcwethy run through all of libs updating that?
or am i conflating things again?
Conflating I think, they did it with some.
ucollections wasn't part of that. I think we hadn't considered it yet.
At least I thought it wasn't, maybe I'm conflating.
¯_(ツ)_/¯
alright...where is :conflating: when we need it. 😄
Nowhere to be found! It's a conspiracy!
Ok. So, the issues with 3.0 are there regardless. LIS3DH needs to be updated. This is my takeaway @solar whale
lis3dh is only part of the problem
Ok
I had an error with ausiobusio -- did its API change -- I know aduioio did
Oh hmm. Might have, yes.
would adabot...no, she wouldn't. only sphinx building the bundle would fail on the automocks...
well, maybe adabot will, since she looks for autodoc fails.
I stopped when it corrupted my FS -- need to get latest 3.0 master in place to stop that
it just got updated today -- I don't think I had updated my CPX - doing it now
Ah ok
released alpha6 is OK -- the bug was between then and now
oh right
it was a busy week...
I have to stop living on the edge 😉
So even without the new additions, the lib does't work in 3.0 because of the touchio and LIS3DH issues?
right?
right - and I think audiobusio
lis3dh is an easy fix. I was able to get lis3dh_simpletest to work on 3.0
frequency changed to sample_rate in PDMIn.