#circuitpython-dev
1 messages · Page 157 of 1
night!
sorry @idle owl! had to break for dinner and Gotham... and that was the link. 😄
fixed it. ugh. Had no localhost.
🙄
and doing what Scott said to earlier.
and purple LED.
unless it's still doing things.
oh it might be.
@timber mango thanks for the hint about 'vim -n' earlier!
Ok so I unplugged USB, and did all the GDB stuff, and I have a green LED
Does GDB eventually stop Continuing. ?
I'm not sure when I can try plugging it back into USB
@idle owl plug what back into USB? the jlink or the metro?
did you unplug the swd cable?
no
it was still "continuing" on gdbs end, and JLink was Received monitor command: reset Resetting target Starting target CPU...
So I wasn't sure I could
try unplugging the swd cable, plugging into usb, then reconnecting the swd.
Ok I have a green LED but nothing is really happening.
where did gdb end up?
LED on JLink is a little bit blinky
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb)
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb)```
hmm. i would start back at the beginning. or...halt? is that a gdb command? (spoiled by pretty icons on Atmel Studio...but the crashes make up for it)
lol
You can use a label-setting program to change this label (or probably GUI tools if you're into that). For instance, on my Linux system I can sudo dosfslabel /dev/sdb1 TRINKETM00 (sudo may or may not be required depending on details of your system). This will stick around until you do something that causes the board to reformat its own filesystem.
(maybe sudo diskutil on MacOS? https://apple.stackexchange.com/questions/56292/change-label-on-usb-drive-in-osx-terminal)
There is a ...
@slender iron UPS delayed my package - stuck in CT. Should be here tomorrow.
@raven canopy I do have a Beagle, but I tend to like using Wireshark and usbmon on Linux better. The Beagle software is limited in what it will decode unless you pay more.
Even a new build is a purple LED.
@tulip sleet hmm...maybe i should find a possible equivalent setup on Win10. prob doesn't exist... you all get a ton of snow?
Is gdb supposed to do something after Continuing. ?
You can use USBPcap on Windows and Wireshark. Be careful, because there was a bug when upgrading WinPcap through the Wireshark installer - you could lose all USB devices. I think that's fixed but I had to use the PS/2 port on my older computer and a PS/2 keyboard adapter to recover.
I hit reset and got blasted with errors again.
we got a sprinkling of snow. I was head down on HID all day and took a break this evening.
oh joy. i don't have a ps/2 adapter, and new mobo is 100% usb. i'll do some diligent reading though.
pushes a table a couple of inches to the left without much enthusiasm
@idle owl 😄 reminds me of the "two inches to left" episode of That 70's Show.
I don't remember that, heh.
It was an alternative to a table flip since I'm kind of doing this to myself.
Make sure you use the latest version.
Beagle 12 software only decodes descriptor packets, not regular USB packets (like characters). Scott adapted a converter from Beagle CSV export to Wireshark: https://github.com/tannewt/python-pcapng
disclaimer comments are the best: "Most likely this is fixed in 1.2.0.3."
"I mean we probably fixed it."
although, at this point with the diversity in systems...it can be hard to say "tis fixed, guaranteed!".
Ok giving up on that I guess.
still just getting purple?
Yes.
Even with different order of operations with everything. It eventually ends with purple.
trying to get the libs on?
ahhh. well, purple is....hardfault yes?
When I first tried, I got CIRCUITPY.
I loaded a code.py, I managed to get some of the libs on.
purple since then.
if you weren't getting purple, i would say that the bootloader was toast. is the code.py still on there?
no idea.
wait...you can't answer that.
Scott said he thinks it might be the bootloader. Earlier.
sorry. brain left the building for a second.
Nah it's all good
I could have easily missed something
Would the flash eraser work? Or would that be a terrible idea.
??? haven't used or looked at it. i'm not sure what all it touches.
is the jlink connecting ok?
Yah sounds like a terrible idea.
Yep
or at least as far as I knew
I put it away already
Before I really did need a tableflip.
.. as requested in issue #236.
the table thanks you.
@idle owl this won't help your problem, but it may put a smile on your face. Many years ago, while working in SW development @ Motorola, we (engineering) realized that sometimes things get broken, and we called them bugs. The folks on the 2nd floor (marketing) would look at the same issue, and decide to tell the customer how wonderful it was, and therefore it became a feature. Then we realized that often, features were truely broken, so we called them beachers (buggy feature), and a real feature that was broken, we called a fug. Not sure why the industry didn't adopt these terms, but we sure got some weird looks at lunch at the Sizzler (common ground for Apple engineers). So, I ask you, is a purple LED a beacher or a fug? :^)
😄 Good question.
I know it is late in your part of the world, and thought a smile might help
haha. can it be a beacher fug?
now you're not an engineer or marketeer... but in accounting.
answered to perfection! 😄
actually, once I had a junior engineer fix a bug. we told him exactly where to look, and what to fix. before the "fix" was committed, we checked it out. he made the exact change we requested in the wrong piece of code. so I guess beacher fug, or worse can exist.
So I grabbed the still borked CPXs from the other night, installed 2.2.3 and then upgraded to 2.2.4 and they're both fine. Blergh. Ok.
@tulip sleet Microsoft actually has an analyzer: Microsoft Message Analyzer. don't have anything to compare it to, but i've recorded a couple traces. filtered down to our IdVendor number...reports all transfers as successful. some of the values are odd (requested IN xfer length: 4096), however.
was not expecting you to be up... 😄
@raven canopy I have tried to use that in the past, but had trouble filtering the output and went back to wireshark (which I was familiar with from network traces). However, it looked like it was pretty good - not sure it parsed all descriptors I wanted. But good you got it to work.
I have been having trouble with HID and am dubious about the USB stack - having trouble with various things. ... Yes, I should go to bed.
ASF4...thanks for the callback structure and all of that documentation. 😬
the callback stuff is awful. There seem to be layered instances of the HID devices. I couldn't get the HID callbacks to work, but not sure what is wrong. Also the hid generic interface is only a singleton - not sure what they were thinking, since the idea of a generic might be to have multiple devices.
Oi.
i'm beginning to think that they designed each driver as a standalone, without thinking that anyone might use multiples. callbacks would be great if all we were doing was a USB stick and could just set-n-forget.
Could the Trinket M0 work with a USB type c instead of micro USB
As in removing the connector and soldering something else? Or using an adapter?
@idle owl RE: CPXes magically working. The universe realized it had you running circles on something else, and implemented the "mah bad" clause. 😄
@timber mango I use a USBA to USBC adapter all the time, but I don't know if you could simply replace the connector on the board with a USBC socket and have it work. I'm not sure what's involved with that.
@raven canopy Apparently. Ugh.
Hmm
Someone else probably knows better than I do, but that's the best I have for you for now.
afaik they're all electrically identical; just different form factors to work with smaller chassis.
Once USB 3.x comes into it, that changes abruptly -- and a few other weird things that are listed in this article:
https://en.wikipedia.org/wiki/USB#Connector_types
@timber mango so, no. The table shows USB Micro-B receptacle (Trinket M0) only mates with a USB Micro-B plug. If it's a molded plug (or cable-end receptacle) you won't find a commercial means to do it wrong (you'd have to craft your own, and understand the wiring).
In any case, Trinket M0 (and all related targets) have four wires (D+ D- +5V power and ground).
Presumably if your PC is a USB-C host, there's a way to connect older equipment to it.
quote:
Type-A and Type-B adaptors and cables are required for older devices to plug into Type-C hosts.
(corrections encouraged; I'm winging it, here ;)
Oooo
@timber mango
https://assets.tripplite.com/product-pdfs/en/u040006micro.pdf
(the no becomes a yes) /21st_Century
@Mochi#2000 @timber mango Sorry, but I may have passed over a critical factor of USB-C. The data protocols are different. Although I don't know for certain, the Trinket's USB interface circuitry and bootloader are probably not compatible, regardless of however creative the DIY electrical connection. The driver software on the host computer is likely not compatible, as well. Perhaps a USB-C to USB-A/B hub would be needed to throttle and parse the data transfer protocols, but without the appropriate custom driver on the host end, it probably wouldn't work well. Stick to USB 2.0 for now is my advice.
@errant grail actually USC type C is independent of USB 3.0. You can use USB 2.0 over type C just fine with the right resistors hooked up to a couple of the new 3.0 lines
- Also fixed detection of SPI flash chip to correct look in the 2+
spots. - Added support for using QSPI in dual read mode.
Its configured to be green while main runs. See main.c and supervisor/shared/ for related code.
@slender iron you won't believe this...REPL is fixed (I think...still gotta run some more tests).
amazing!
usb_bytes_available was the problem...
huh
bool usb_bytes_available(void) {
if (cdc_enabled() && !pending_read) {
start_read();
}
if (usb_rx_count == 0) {
return false;
}
return usb_rx_count > 0;
}
it was ALWAYS calling cdc_enabled, which would clear the buffer...
bool usb_bytes_available(void) {
if (usb_rx_count > 0) {
return usb_rx_count > 0;
}
if (cdc_enabled() && !pending_read) {
start_read();
}
if (usb_rx_count == 0) {
return false;
}
return usb_rx_count > 0;
}
ah! that makes sense
i'll probably change it to if (usb_rx_count > 64)...but, i've got upto 160chars printing.
only read more if we have nothing buffered
@timber mango @timber mango @errant grail
(thats from my toaster oven. D+ and D- go to the samd51)
great job @raven canopy !
just glad i can take a break from reading ASF....that stuff will make you batty. and, i got a little deep on the "how is this thing working, from top to bottom".
yeah, asf4 will do that to you. especially the usb stack
up to 640 chars... now to make sure it doesn't break anything else.
PR it up and have jerry test it 😃
yeah, i should do the same. but, i'm taking tomorrow off. happy 💤s
@humble mural FYI - I received one of the ESP-F boards and it is indeed just an ESP8266 - Loaded CP3.0 and it is running with no problems. esptool even reports it as an esp8266.
esp8266 or esp8285?
Esp8266
Writing build/firmware-combined.bin to the board
esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
@solar whale thanks. That is just what I wanted to hear.
Hi, I am sorry for opening similar issue, now without RTC feature.
I missing only one feature, It can very help for battery operated devices.
Sleep and wait for button for wakeup, I thing that it can be great advantage to expand cpython to wearables. This guys make something for sleeping but wake not working. Can anybody make this feature?
Will review test failures and update PR.
argh, my test failure doesn't occur with DEBUG=1, which is why I didn't see it locally before pushing 😦
yay for heisenbugs
yay for "gcc -fsanitize=undefined". It quickly turned up that I was calling memcpy(NULL, NULL, 0); which is not OK no matter how hard you wish it should be OK.
TFW you really need to go out the door to work, but need to see if the travis build for your hobby project is green
phone?
just port QT to it ;-)
wahoo, green. now I have no excuse. ttyl
Just a quick update - Making progress on this. I have the basics working for SPI and I2C. Patterned after FocalTouch as suggested and I have the basic "paint" demo working with a 2.4inch TFT. Lots of clean-up/tweaking to do.
Still have to deal with the occasional SPI "mode" issue. Seem like just retrying usually gets it "right".
I noticed that this functionality was now added in uPy and cherry-picked the fix.
As far as testing goes, there is an added test case but unfortunately it looks like the related test is skipped during the unix and qemu builds. ☹️
Closes: #501
hiya - this would be same as https://github.com/adafruit/circuitpython/issues/119 - we'd need https://github.com/adafruit/circuitpython/issues/544 first, because you cannot sleep with USB connected :)
@slender iron Thanks for the USB-C/3.0 clarification! I haven't played around with the USB-C connector yet (it shows), but will add a couple variations to the next DigiKey order so that I can learn from experience. I have a couple of universal power source projects that could benefit from an upgrade. @timber mango @timber mango
Hi Everyone, just joined the board.
I'm building a 18 key chording keyboard using an atsamd21e18, and I've built a modified UF2 bootloader (still awaiting my j-link to flash).
I was hoping to make a modified Trinket M0 circuitpython firmware (single LED, no NeoPixel), but when I build the files I get an error due to a missing module adafruit_usb_descriptor file. Pretty new to Micro/CircuitPython, so any help would be appreciated.
I'm using Mint 18 32-bit build environment running in VirtualBox, and cloned the adafruit/circuitpython repo.
Just thought to search... Doh!
I got past the adafruit_usb_discriptor issue, but now I get the following repeated many times one invoking make:
cc1: error: -Werror=lto-type-mismatch: no option -Wlto-type-mismatch
Looks like a compiler issue.
@jovial pine which compiler and version are you using?
How would I check? The bootloader built using arm-none-eabi-gcc, but I don't get any information out of the make command for circuitpython.
make V=2 states arm-none-eabi-gcc
arm-none-eabi-gcc --version
4.9.3
I was messing with an old build guide for something else...
I'll look at updating the compiler to be a more recent build
@jovial pine there was a very recent update for this situation. see here if you need some assistance: https://github.com/adafruit/circuitpython/tree/master/ports/atmel-samd#setup
See Issue #417.
After all that digging through the USB read functions and ASF4, turns out we were just reading to often, before clearing the local USB buffer. usb_bytes_available now checks if the local USB buffer 1) has data per usb_rx_count, and 2) if we have space for a new USB read (64 bytes max).
I also commented out the recurring calls to start_read in both usb_read and read_complete. I don't think we need them, since usb_bytes_available and usb_cdc_background will a...
Anyone here know for sure if audioio is only on the Express boards? @idle owl and I were looking at this and seems like that's the case -- I was trying to use adafruit_rtttl library on Gemma M0, but looks like that's not currently possible. @slender iron
@jovial pine I can help you with that one. If you have an older gcc version you can safely delete those lines. They work around a bug/limitation in newer versions of gcc.
I compile circuitypthon successfully with gcc 5.4 on debian stretch, the flag is needed with 7.2 (but the project recommends using gcc 7.2 on ubuntu as described in ports/atsamd/README.md)
@split ocean it's only on express boards, but I have compiled custom firmware for the trinket with it enabled (I had to disable analogio to make room)
OK, thanks @stuck elbow I'm doing this for a learn guide, so I'll keep it to pwm tone instead.
I think someone was working on a version of the rttl library that used pwm, but I can't recall the details
@jovial pine that is, you can fix the build problem by finding the -Wno-error=lto-something lines in ports/atsamd/Makefile and just deleting them
I2C before UART doesn't work:
``Adafruit CircuitPython 2.2.4-2-gcfcbb3623 on 2018-03-22; Adafruit Trinket M0 with samd21e18
import board,busio
i2c = busio.I2C(board.SCL, board.SDA)
uart = busio.UART(board.TX, board.RX)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid pins
UART before I2C works:
Adafruit CircuitPython 2.2.4-2-gcfcbb3623 on 2018-03-22; Adafruit Trinket M0 with samd21e18
import board,busio
...
@split ocean I'd like to make RTTTL use pwm as a fallback if it doesn't already
that would be a cool option to have
it currently fails on a GemmaM0 when it tries to import audioio
this is on 2.2.4 btw
great, thanks.
np
@jepler thanks for all the help. Make is doing the business...
In IEEE 754, C and python 2.x, the return type of ceil/floor functions is a floating-point type. python3 changed this, so that the return type is an integral type (a fine choice for a language which has an unbounded integral type like long). On circuitpython builds without support for arbitrary precision longs, why not follow python2 and return a float so that there are no unexpected range problems? I have an untested patch prepared to do this, and I could PR it if it stands a chance to be...
We may turn on longints on the M0 boards if we can get things to fit in 3.0.
@tulip sleet proper long support would be nice
.. my trinket m0 doesn't have much space left though!
@onyx hinge it would make sending 32-bit values to devices a lot easier
RE: "Dynamic" USB Enabled Check
Here is the current usb.c/cdc_enabled:
static bool cdc_enabled(void) {
if (mp_cdc_enabled) {
return true;
}
if (!cdcdf_acm_is_enabled()) {
return false;
}
cdcdf_acm_register_callback(CDCDF_ACM_CB_READ, (FUNC_PTR)read_complete);
cdcdf_acm_register_callback(CDCDF_ACM_CB_WRITE, (FUNC_PTR)write_complete);
cdcdf_acm_register_callback(CDCDF_ACM_CB_STATE_C, (FUNC_PTR)usb_device_cb_state_c);
cdcdf_a...
tried this on a metro_mr_express_revb:
Adafruit CircuitPython 3.0.0-alpha.3-23-gccbe557-dirty on 2018-03-23; Metro M4 Express Rev B (Black) with samd51j19
>>>
>>>
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456789ABCDEF
=== #123456...
Thanks for testing @jerryneedell!! I'll go sniffing...
Just for fun - here is a nice example of it working in "Paste Mode"
Adafruit CircuitPython 3.0.0-alpha.3-23-gccbe557-dirty on 2018-03-23; Metro M4 Express Rev B (Black) with samd51j19
>>>
>>>
>>>
>>>
>>>
>>>
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== import board
=== import digitalio
=== import busio
=== import time
=== import adafruit_bmp280
===
=== # Create library object using our Bus I2C port
=== i2c = busio.I2C(board.SCL, board.SDA)
=== bmp280 = ada...
So, my previous testing was only with continuous strings...testing fail on my part.
Using multiple lines would cause the pyexec_xxx_repl functions to trigger usb_cdc_background which was triggering unwanted reads to the USB buffer. This didn't happen in Paste Mode because it stays in it's own loop before exiting the pyexec_xxx_repl function, thereby not triggering usb_cdc_background.
@jerryneedell you are the ULTIMATE tester. Don't know what we'd do without you... Please give ...
nailed it ! -- almost -- see all three examples
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 3.0.0-alpha.3-24-gf237657-dirty on 2018-03-23; Metro M4 Express Rev B (Black) with samd51j19
>>>
>>>
>>>
>>> import board
>>> import digitalio
>>> import busio
>>> import time
>>> import adafruit_bmp280
>>>
>>> # Create library object using our Bus I2C port
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> bmp280 = adafruit_bmp280.Adafruit_BMP280_...
aha found both places to enable mpz longs. 75% of the remaining flash in trinket m0 ends up used to implement it. eek! (and my board's not here, have to wait to try it later)
yeah. it gets tight on non-express boards..
alright. late lunch break. @solar whale i'll look into that line 1 thing. hopefully there is some commit history on it...
Note - the occasional paste mode failures are not new to the latest commit. They occurred in the previous one as well. I thought it was user error but now it looks like a possible issue.
@raven canopy I'll see if I can find it - It goes way back...
@raven canopy https://github.com/adafruit/circuitpython/issues/124
the syntax errors I was thinking about were from #124
May or may not be relevant...
@raven canopy just put together a trellis board and tried your driver - worked great! Very nice!
@raven canopy So e.g., the ItsyBitsy M0 Express will have more growing room?
@onyx hinge If I am not mistaken, the difference is that the express boards don't have to hold back flash space for the internal FS -- the non-express boards hold 64K for the FS.
gemma_m0
#define BOARD_FLASH_SIZE (0x00040000 - 0x2000 - 0x010000)
vs Itsy Bitsy
#define CIRCUITPY_INTERNAL_NVM_SIZE 0
#define BOARD_FLASH_SIZE (0x00040000 - 0x2000 - CIRCUITPY_INTERNAL_NVM_SIZE)
right
http://ww1.microchip.com/downloads/en/AppNotes/00001953A.pdf
There's a good diagram of USB-C plug on page 4 (Fig. 3) that shows how D- and D+ are only on one side of the reversible connector. @timber mango @errant grail -- USB-C must implement USB 2.0 connection (1.2.1 on page 2).
The datasheet for SAMD21 says it implements USB 2.1 as both host and device.
PDF source:
http://www.microchip.com/promo/usb-type-c which points to
http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en574276
@timber mango so at the receptacle/PCB side, there must be a trace connecting both D+ to the same net, and likewise for D- ?
yup yup
2.4 Passive Cables
A passive USB Type-C cable does not have embedded powered electronics. All passive cables must minimally support USB2.0, and it can support USB Power Delivery up to 60W of power.
@stuck elbow Do you have a link to your custom firmware that does audioio on a trinket? I’d love to be able to do 2 seconds of a wav in a project.
2.7 USB Type-C to Legacy USB Cables
The USB Type-C™ specification also defines the allowable USB Type-C to Legacy USB cable assemblies. The following full cable assemblies are supported:
(yadda yadda)
USB Type-C to Micro-B (USB2.0) << smoking gun
Fig. 4 shows VCONN and CC. Everything else about the plug (right-hand drawing) side of this figure is explainable by understanding USB 2.0.
@onyx hinge You could just wire A6 to B6 and A7 to B7 at the USB-C receptacle.
A6 (D+) on the plug mates with either A6 or B6 on the receptacle (depending on if it is in the flipped or proper orientation -- plugs in either way and 'just works' wow!)
Similarly, A7 (D-) on the plug mates with either A7 or B7 at the receptacle.
@split ocean do you have a pending guide I can look up for hoook up instructions?
@solar whale I can't take much credit on the Trellis library. ladyada and TonyD wrote its parents, and tannewt suggested all of the subsequent changes... but, glad you like it!
insists that you take some credit for your hard work. ;)
haha. i hear that..a lot. 😄
@split ocean I've got code for ya
great, lay it on me
(will submit a PR now to get it in the bundle)
then the full code.py is: ```python
import adafruit_rtttl
import board
adafruit_rtttl.play(board.A2, "Bond:d=4,o=5,b=320:c,8d,8d,d,2d,c,c,c,c,8d#,8d#,2d#,d,d,d,c,8d,8d,d,2d,c,c,c,c,8d#,8d#,d#,2d#,d,c#,c,c6,1b.,g,f,1g.")
works great, thanks!
no problem, no you can google rtttls 😃
I'd rather be consistent with python 3 and always return an int. With MPZ
on it M4 and M0 express boards (have we turned it on?) for 3.0 this should
be less of an issue.
On Fri, Mar 23, 2018 at 9:50 AM Dan Halbert notifications@github.com
wrote:
We may turn on longints on the M0 boards if we can get things to fit in
3.0.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/adafruit/circuitpyth...
@sommersoft that looks ok to me. Did you change the files?
My proposed patch will leave the behavior unchanged on builds that have MPZ enabled.
Go ahead and delete this.
Go ahead and delete this too. Git has it in its history.
Want to use USB_RX_BUF_SIZE here so this changes with it?
The only change I see so far from the fix to #124 is the addition of VFS gc collection. Could have reintroduced the previous problem. Will keep looking, unless wiser minds chime in...
I'd rather throw ValueError on MPZ-less builds. We can consider turning it on for non-Express boards if we have space once everything else is done for 3.0.
Lets get this in and we can chase the syntax error down separately if we want.
Can do. Or, we can use the EP max packet size constant; any future use of USB HS is what would be the determination of going above 64 bytes per EP buffer. Yes?
A board-specific hack could help here. Is hard-coding the approach we want to take for things like this?
is doing email
You know better than I do. :-)
On Fri, Mar 23, 2018 at 2:34 PM sommersoft notifications@github.com wrote:
@sommersoft commented on this pull request.
In ports/atmel-samd/usb.c
https://github.com/adafruit/circuitpython/pull/698#discussion_r176869100
:@@ -243,9 +245,16 @@ static bool cdc_enabled(void) {
}bool usb_bytes_available(void) {
- // Check if the buffer has data, but not enough
- // space to hold another read.
...
No objection from me! Great work on this. I think it will be good for others to use it and see how often the syntax error occurs. For me it is about 25% to 50% of the time but there was a lot of flailing around.
@jepler I agree with you that the user could do it as needed. A lot of our guides reference CIRCUITPY and it'd be good to be exact by default.
How about we add something to storage that can change it during boot.py? That way the process is OS agnostic but still done by the user.
Fixed by #693. Thanks @jepler!
@tannewt interesting idea, I will try to take a look at doing that this weekend. I am not familiar with the storage module yet, but maybe the API should look something like: storage.setlabel(filesystem, "newlabel") ? I'm not actually seeing in the docs what sort of values you might pass for filesystem though, hm.
wooo @slender iron and the rest are sooo responsive to my PRs. Thanks so much. I wish I did as well in the projects where I am in a maintainer role.
@onyx hinge I try! My promise is to go through my email once a day each weekday
huh there's a 🥕 emoji but no stick... unless you want a 🕹 or 💄
we can add more emojis 😃
thanks for all of your work on circuitpython @onyx hinge. its much appreciated
This is definitely on my radar. I think one of our major releases should focus on battery-operated datalogging. Saving battery life isn't simple because of peripheral and clock management too. I'd also like to tackle flash wear leveling to coincide with that.
I'm happy to advise anyone trying to do this earlier but its not a focus for us yet.
@onyx hinge I'd also love to have mpy-cross functionality available through a module for the same reason as setlabel
goes to file an issue
IIRC remount uses the mountpoint. So "/" or "/sd".
Add a mpy_cross module that exposes the same functionality as the mpy-cross binary. That way people can use the REPL to convert py files to mpy. They are usually needed when loading multiple libraries at once. So, loading one at a time to mpy it up should be doable.
has anybody built circuitpython into webassembly or otherwise put it in the browser?
damien has done it with micropython
I'll have to look for that!
If mpy_cross is included in the REPL, would it become possible to have an option for import to convert to mpy from within the code itself?
yeah, not sure if that would save memory though
It might with some of my verbose custom libraries. 😉
if other imports happened before it then it'd still have less memory
Got it. Would be better to replace the .py library with an .mpy version to begin with.
yup, think so
at least having it available built in then you don't need to worry about finding a mpy-cross for your platform
yes, a nice feature indeed.
BTW, stringcar CPy motor controller algorithms are done and are calculating string length very accurately during bench testing, but it's too windy today for the on-the-string tests. Just have to wait. Indoor tests were banned a couple of years ago. The motor voltage parameter and power supply monitoring schemes are working well.
👍 thats awesome!
<-- Happy Camper
I was gonna ditch out and go climb but its about to pour 🌧
Too bad. No rain here (yet), but lots of fast moving dark clouds.
I shoulda gone when the sun was out
at least I don't need to water the garden 😃
its good for the plants I put in last weekend
Ah yes. We had to turn on the irrigation already.
"Indoor tests were banned a couple of years ago." I think there is a story behind that, that we should maybe hear... 😄
@raven canopy should I look at your other PR too?
@raven canopy I deleted the photos. Plausible deniability.
if you're in the mood...have at it. haven't done anything with it yet, but did put the comment in for a question (is there a follow on comment I haven't looked at yet?).
and you let the cat out of the bag on usb....hopefully i don't break too much with futurizing the USB packet sizing. 🙃
is there more you need to do @raven canopy ?
@slender iron still need to address the issue Dan pointed out with regards to disconnecting the USB AFTER boot (i.e. going from USB to battery power)
kk, I'll wait then. just ping me when you think its ready
👍 I put the comment in for what I think will work, but I don't have a battery yet (sitting on this current cart too long). also wanted someone to pre-check my work...
ok, I'll take a quick look
@raven canopy it looks all good to me
a review on this would be good too: https://github.com/adafruit/Adafruit_CircuitPython_RTTTL/pull/5
I saw JP tested it?
yup
Excellent, looks great. I'll take care of it.
i would say "I'll get it", but @ speak-of-the-devil....
thanks @idle owl ! time for me to head to the gym since the rain/hail passed
Have fun!
thanks!
🏋
Oh, missed the question earlier @slender iron I've got piezo on GND and D0/A2 your updated code works great.
@slender iron HID mystery solved: After a buffer is sent, the buffer gets cleared somehow by the USB code or peripheral. So if I copy the data too early, while the previous transaction is in progress, then the data I want to send will get zero'd out. I have to copy it when the endpoint is ready to send and not before (or recopy it on each attempt).
@restive pasture unfortunately I never commited it, but the modification is trivial — just moving some lines in the mpconfigport.h
Trivial if you have the build system set up. 😀 I’m more user at this point. But love where this project is going so I’m lurking. I’ll take a look.
So, I pulled back on all of the "futurization" I mentioned earlier in discord. The only SAM chips that run High Speed USB are M7s; no real reason to put that in for now.
@slender iron pending Travis, REPL fix should be good to merge. I'll work that other one later tonight or tomorrow. It's movie time!
later @raven canopy
hehe. just had this thought: "I should turn off my circuitpython Travis build, when pushing to an open PR. It's mean to make him do the same work twice..."
@tannewt @dhalbert, cdc_enabled is now updated to match the above. I tested on a Trinket with USB->PC and USB->Wall Wart; still functions as before. But, I don't have a battery yet (that I can easily hook up) to reproduce Dan's earlier test. After that test is run again, and if nothing else is needed, this should be good to merge.
I'll look into the new Feather52 USB stuff once I get one in hand.
@raven canopy I don't think travis minds.
as long as he doesn't merge with Skynet...I should be safe. 😄
Moving on to the project to convert the Corrosion Monitor from Arduino to CPy tonight. After a bunch of searching, standing on one foot, and holding my tongue on the right side of my mouth, was able to get the ili9341 drivers to work with the 2.7" TFT FeatherWing driven by a Feather M0 Bluefruit disguised as an M0 Basic. Graphics only at this point (pixel, hline, vline, rectangle). Will take a shot at the bitmapfont stuff after some shut-eye.
🛌
I just started using "Mu" to run through the circuitpython yesterday. It worked well. But, today I open the Mu and save the test code.py again. It doesn't work and nothing show up in the REPL screen. How do I fix it? Thanks!!
A typo in the filename prevented /.fseventsd/no_log from being created.
microcontroller.cpu.temperature
0.0
hmmm is this known breakage in the master branch? (trinket m0)
working up some ideas for version art for major releases
Is there a CircuitPython library for the Adafruit Ethernet FeathrWing?
I am guessing making a CFFI wrapper around the Arduino based library would be out of the question due to all the Arduino library files it requires.
@analog drift a few moments of searching didn't find one yet.
Yea. I am probably going to have to translate the Ethernet2 library written in Arduino to CircuitPython
@onyx hinge microcontroller.cpu.temperature is all commented out for now, and returning 0. I assume it'll be re-enabled after all of the mappings (ADC, etc) are done in 3.x. https://github.com/adafruit/circuitpython/blob/master/ports/atmel-samd/common-hal/microcontroller/Processor.c#L193
@analog drift as you've determined, there isn't a library yet for the Ethernet wing. If you do end up making the library, please feel free to contribute it! This guide will help you with how our standard libraries are made: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/overview
@raven canopy Thanks
@analog drift also, if you do follow that guide, don't set it up as a "Community Bundle" library. I imagine the CircuitPython folks at Adafruit would want to put it in the Featherwing library in the Adafruit Bundle: https://github.com/adafruit/Adafruit_CircuitPython_FeatherWing/tree/6d498560a8af32bacf2ff358c3751a6a85a2e5ff I'll put in an issue for the library, ask the question, and see if we can get you an adafruit github repo created.
(P.S. I am not employed by Adafruit...merely a contributor)
why cat?
@river quest I dig it! And the slightly-subtle tribute to Mosfet, definitely needs to stay no matter how it ends up.
snakes, cats, it's a whole zoo
or a "playground"... they're kind of synonymous. 😄
I think snakes are generally not desirable in the playgrounds
they do appear in zoos and circuses, though
Hm, setting the filesystem label from python on the trinket turns out to be a bit tricky.
why is that?
You can't do it from the REPL, because the filesystem has to be in RW mode to circuitpython
so you can do it in boot.py only
yeah, there is a guide on that
also I was having trouble with output, seems circuitpython doesn't support print(..., file=FP)
so I was getting nothing in the debug log I was trying to write
A user in Discord was looking for an Ethernet FeatherWing library. After discovering there isn't one yet, they mentioned that they were going to port over the Arduino library. I've given them the guide to build a standard library, and mentioned that you all will probably want it in the Adafruit Bundle.
Can someone create the repo for the library for them?
happy to do so, but this is a very big/complex library, its not going to fit in a samd21, do you know what chip were they targeting?
@analog drift issue created ^^^. Feel free to answer ladyada's question on your target chip, if you like.
They didn't mention their targeted platform, but I passed along the issue and question. Will let them respond if they desire...
all good, i was thinking last night about how we could go about adding support, but i would def do so on an M4 :D
@analog drift hiya im also here, i was just poking at the Ethernet2 library (joy!) so can maybe give guidance
😃
Is there a document describing the design of hash() in CircuitPython / MicroPython? It seems to not be a "very good" hash function, but I assume it's based on trade-offs that I'm not aware of
for instance, hash("...") seems to always fit within 8 bits, and hash(float) is just floor(float) unless it's "too big"; then it's -1
i think its just for dictionary lookup speedup
#if MICROPY_QSTR_BYTES_IN_HASH == 1
#define Q_HASH_MASK (0xff)
do you need a 'true' hash function?
looks like yes, string hashes are just 1 byte for compact storage of QSTRs
@timber mango I was looking at autogenerating a device label based on microcontroller.cpu.uid
ooh ok, i know uhashlib works well - https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/CircuitPy_OTP/main.py
kinda overkill tho
Agreed. It looks like it's excluded on my Trinket M0 due to space constraints anyhow
im a fan of just grabbing the last 4 digits in HEX
and appending, we do that with MAC addr's on BLE boards
That's the last 16 bits of the microcontroller.cpu.uid?
yeah
that's what the ESP8266 does as well.
oi yeah trinket is a very odd case because i fit all the pins on a dual sercom, so you could have either 2 sercoms for i2c/usart or one for a full SPI. i think for now we should document this as an unexpected consequence of the way trinket m0 is set up. long term, we can do hardcoding/hinting.
sound good?
These numbers don't look all that random, sadly.>>> [hex(i) for i in struct.unpack("!8h", microcontroller.cpu.uid)]
['0xb05', '0xf00', '0xe0e', '0xd01', '0x0', '0x1', '0x500', '0x10f']
the datasheet remarks at one point that you have to use "all 128 bits" to be guaranteed a unique number; it looks like maybe they even structured the ACTUAL uids so as to catch anybody who didn't follow it
could take a classic CRC-16?
something simple like that sounds good, yeah
we have a ton of CRC examples
_crc16(microcontroller.cpu.uid)
1550
sure could work, at least it's a calculation that involves all 128 bits
The following program constructs three sets. The first contains integers (3,4,5,...). The second contains floating point numbers (3.0, 4.0, 5.0, ...). The third, floating point numbers (3.0, 3.0001, 3.0002, ...).
def make_set(i0, di, n):
s = set()
for i in range(n): s.add(i0 + di * i)
def timeit(f, n=10, r=3):
import time
best = 1e100
for i in range(r):
t0 = time.monotonic()
for j in range(n): f()
t1 = time.monotonic()
...
Enabling MICROPY_FLOAT_HIGH_QUALITY_HASH in mpconfigport.h appears to cost just 64 bytes of flash (tested on trinket m0 with gcc 5.4), and changes the typical performance to
0.154968
0.237976
0.330017
so, yes, both of the hash() suboptimal behaviors I saw are deliberate trade-offs in micropython.
Hello, this is UnknownError from discord. My initial target would be the Adafruit WIZ5500 wiznet ethernet featherwing purely out of necessity. I also have the Adafruit Feather M0 WiFi w/ATWINC1500, but I will have to work on that one later.
Well, 32kb RAM.
You could add a seed value (salt) and store it, so that it can be regenerated again later, to add pseudo-bits of entropy. ;)
who's going to have both present -- a near-serial number, and a (pseudo) random seed value stored, on two different entities?
Then just concatenate and CRC-16 from there.
ooh a pure python implementation definitely wont fit on an m0, especially without external flash. you might be able to fit into C - it looks like micropython (which we derive from) has a wiznet5k module!
https://forum.micropython.org/viewtopic.php?t=378
we haven't tried it at all, but your best bet is to use a feather M0 express so you get that extra flash space, then try to compile circuitpython with the wiznet module enabled :) alternately, you could try waiting for the M4 boards (tons ...
hooray an adabox appears
chatted with @tannewt - we may try compiling this into a future circuitpython build from upstream!
@meager fog the kids saw the word "spy" and took off with it 😉
@meager fog @tannewet and a feather M4 w/perhaps a CS4334 DAC on it would do 85% of what stuff out there does now.
yayy! did you see the schem for the m4 boards?
not yet
sent in PM 😃 take a look!
grabbing now
metro m4 is pretty much 'done' but feather m4 is still up for changes 😃
that said, its never too late to make tweaks
i think id rather make a featherwing with i2s on it, maybe with one of our nice i2s chipsets
in particular, im diggin' the AK4954AEN Audio CODEC
$1.25 by the reel
That sounds like a reel-y good price.
reading the codec datasheet
thats normal/standard, it uses a PLL
M0 does the same. the 32khz xtal does double duty as PLL input to 48MHz as well as low power clock
(that said, iirc its broken in first silicon rev of M4, we use USB timing and internal trim data)
so something like the trinket m0 does?
I'm thinking about µGame with SAMD51, and I will probably skip the crystal on it too
(no need for exact timings)
hmm, I think the revB had an inductor connected to the m4?
looks like a big capacitor
or is that the L1?
plenty of space on feather for D+/D- pogo pads
there is an inductor there, its for the built in 1.8V buck
@ruby lake oh yeah ill add em
but that's not L1 on this schematic?
it's connected to a separate chip
ooh, I see, you have the chip broken up into sections
that's neat
yah, for simplified schematic
is an eagle noob
this software isnt famous for its excellent UI
that codec has an impressive set of tools for the inputs
samd port and pin config has to be one of the most headache-inducing things I've ever read
I thought Silabs C8051F3xx series crossbar was challenging enough. ;)
@ruby lake the sercoms are particularly annoying, but other periphs are not as bad
@meager fog I finally found what I was looking for, that being which pins can be MLCK. (table 6-18)
hey @meager fog You wouldn't happen to have a part number for the inductor on the m4 would you? I found one in a 1210 package that I've used so far in my m4 board but I'm having trouble finding one with the proper saturation current and ESR as specified in the datasheet in a smaller 10xx package like you used on the m4 metro. I'm hoping to shrink the board even more so any spare mm² will come in handy
Quick debug log, in case anyone can readily explain why the below is happening. As this shows, we're ending up at reset_mp, which sets the pixel to 0x8f008f (purple).
<function> (<caller>) <variable>: <variable value>; <variable>: <variable value>
--------------------------------------------------------------------------------------------
new_status_color(reset_mp):: current_status_color: could not evalu...
i really need to find a way to put the correct bootloader back onto my debug trinket. using the feather hex "works", but i can't get to trinketboot anymore. 😄
@raven canopy cant you use the .bin file from the released versions of https://github.com/adafruit/uf2-samd21 or build it yourself from this repository?
@solar whale i was looking into that last night. will most likely give it a go. thanks!
@solar whale worked like a charm. why didn't i scroll down on the releases page last night? hehe
Does circuit python support .mpy files?
@analog drift it does. although i'm not sure that they're interchangeable with micropython .mpy files.
That's fine. I do not need interchangeability between circuit python based .mpy files.
👍 just wanted to make the note, in case.
Nor integration with existing .mpy files
Yea, but that is really need that .mpy files are supported given the limit space.
And is there a way to compile C based libraries to be exposed to CircuitPython? Similarly to the C-API bindings or the CFFI library?
well, all of the core libraries (digitalio, audioio, busio, struct, etc) are written in C. Look at the circuitpython/shared-bindings and circuitpython/ports/???/common-hal to see how they're implemented. but, as deshipu said, we're not able to run C from circuitpython. it is a desired thing though...
@raven canopy I'm guessing all of those libraries are build into the interpreter itself?
yes
@analog drift if you look at the Makefile for each port, you'll see where they get included into the compile.
<-- is clearly on first cup of coffee; can't form complete sentences yet. 😄
Hahaha
interesting, a memory corruption bug in one of the 'cpydiff' (differences from C python 3) tests. A string value has been erroneously used as a pointer...
==32555== Command: ./micropython ../../tests/cpydiff/core_class_superproperty.py
==32555==
==32555== Invalid read of size 8
==32555== at 0x4083F9: make_obj_long_lived (gc_long_lived.c:127)
...==32555== Address 0x7263696d2f62696c is not stack'd, malloc'd or (recently) free'd
Address is actually the string fragment 'rcim/bil'
@raven canopy that calls for another trip to dunkin, or another cup of coffee (region-dependent 😛 )
or more likely, 'lib/micr[opython]'
@prime flower i'm on cup #2...feeling much better. 😄
yey, coffee! I've been really under the weather all week and buried in projects for class, feeling better today
glad to hear it! sudden guilt of ignoring recent attempts to re-start school sets in hehe
also fun lil project ive been working on, finally finishing it up and porting over to cirpy
morse code, or ? @prime flower
Morseing progress! yay!
ok folks @here next #circuitpython-dev newsletter goes out on tues, here's how to contribute to it and sign up - https://blog.adafruit.com/2018/03/22/contribute-to-the-circuitpython-weekly-newsletter-adafruit-on-github-circuitpython/
Adafruit has spam-free newsletters and never shares your email address. We are so bonkers about this we made another site called Adafruitdaily.com where you sign up for our newsletter. We don’…
@onyx hinge yep!
I need to get better at my morse code, that was supposed to say TMI...
at least it didn't say "TNT"...might have been an explosive result. 😄
💥
I noticed that tests/cpydiff/core_class_superproperty.py crashes when running the UNIX port. I minimized the crasher source to
class AA:
@property
def p(self): return super()
Valgrind produces the following information:
~/src/circuitpython/ports/unix$ valgrind ./micropython ~/repro.py
==19124== Memcheck, a memory error detector
==19124== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19124== Using Valgrind-3.12.0.SVN and LibVEX; rerun ...
Minimized from a testcase found by afl-fuzz:
import usocket as socket
s = socket.socket('1')
Stack at time of assertion error:
micropython: modusocket.c:328: mp_obj_t socket_make_new(const mp_obj_type_t *, size_t, size_t, const mp_obj_t *): Assertion `MP_OBJ_IS_SMALL_INT(args[0])' failed.
==20103==
==20103== Process terminating with default action of signal 6 (SIGABRT)
==20103== at 0x5798FCF: raise (raise.c:51)
==20103== by 0x579A3F9: abort (abort.c:89)
==2...
@slender iron let me know if I should file more of these. I have two additional crashes found by afl-fuzz in circuitpython so far. All of the crashes I've discovered today seem to be unique to circuitpython and are not in micropython.
@onyx hinge I would hold off for now. to my knowledge, we don't maintain the unix port at all so that first issue won't be all that bothersome. as for sockets, the only port we maintain that I recall using it is the ESP8266. we keep those ports in the repo so that we can stay up to date with major upstream pulls...
@raven canopy Point taken. As far as I know, though, ports/unix is used (tested) by the travis setup and is actually pretty useful when it comes to developing non-hardware-interfacing code
Running the same block of code on my Trinket M0 hangs it, requring use of the reset button.
@raven canopy thanks for the encouragement to test on an actual circuitpython board. I can't test the 'usocket' one, but only one of the rest produce the same crash.
though .. this is pretty weird
a1 = array.array('O', [1])
a2 = array.array('I', [2]) * 2
a3 = (a1 + a2)
print(a3)
array('O', [1, inf, inf])
array('O', [<trinket hangs>```
Trinket M0, master branch (similar test cases crash interestingly on ports/unix), found with afl-fuzz
>>> import array
>>> array.array('O') + array.array('I', [4])
array('O', [
Trinket M0 serial interface hangs after printing [.
Before this change, microcontroller.cpu.uid returned values
where the top 4 bits of each byte were zero, because of
an incorrect bitmask used in this function.
Testing performed: Looked at the value on my Trinket M0
>>> ''.join('%02X' % c for c in microcontroller.cpu.uid
'1B45FF004E4E4D5120202031251011FF'
Before the fix, the value was shown as 0B050F000E0E0D01000000010500010F, because 4 out of every 8 bits were lost.
ooh nice catch @onyx hinge !
nice catch indeed. my bitwise game is...not that good. 😄
While debugging, I found that make_fun_bc_long_lived is being called with an object of type closure_type. make_property_long_lived should not assume the proxy objects are all of type mp_type_fun_bc.
#2 0x000055555556e244 in make_fun_bc_long_lived (fun_bc=0x7ffff6f110a0,
max_depth=2 '\002') at ../../py/gc_long_lived.c:39
39 fun_bc->globals = make_dict_long_lived(fun_bc->globals, max_depth - 1);
(gdb) p *fun_bc
$12 = {base = {type = 0x5555557f4680 <closure_type>}...
argh, pressing "restart build" on travis destroys the evidence—it discards all the old build logs, and re-does build #NNN rather than starting a new build #MMM with the same branch/ref
.. a failure in thread/thread_lock3.py on unix that occurred just once on a commit touching nothing even vaguely related ☹
race conditions \o/
This was a failing test for several reasons. One of the reasons was the #705 crash, another was lack of handling of properties and descriptors by super() objects. Fix both problems and put core_class_superproperty.py into the set of tests that get run.
@tannewt I'm not sure of the impact of the change in gc_long_lived.c. From my basic understanding, it seems the closure objects that you get when you have an @property which uses super() may not be properly made long-lived. However, I don't understand what would be necessary to allow them to become long-lived objects.
my God, and I thought that it would be only one instruction. It is really complicated thing.
The 'afl' fuzz tester found cases where all of these assertions could be triggered with valid Python code that used unexpected types (or values, in the case of the 3-argument pow() one). This PR converts them to Python exceptions, so that the whole device doesn't crash.
I only reproduced these failures in the unix port, but I believe they affect all ports.
(lambda: None)(**{len: None}) 🎆
progress of afl-fuzz on circuitpython
I am regarding the hangs as largely uninteresting. It's way too easy to write infinite loops!
@onyx hinge If you surround code with one backtick on either side (in the upper left of a US keyboard, on the same key as the tilde, and next to the 1), you get inline code, if you surround it with three backticks on either side, you get a code blockMakes it easier to read code 😃
@idle owl I'll try to remember that
It took me a while to figure it out, but now it's so much a habit I find myself doing it in places where it's not supported 😄
Python2/3 don't accept array type 'O'.
A related problem can be triggered with slice assignment
>>> io = array.array('Q', [2,3,4])
>>> ao[0:2] = io
>>> ao
array('O', ['', 1, Segmentation fault
and it's not clear if this result from concatenating different-type arrays is desirable (python2/3 reject it with a typeerror, even when the types have the same size)
>>> array.array('B', [2,3,4]) + array.array('I', [5,6,7])
array('B', [2, 3, 4, 5, 0, 0, 0, 6, 0, 0, 0, 7, 0...
@idle owl I just wish my tilde-markup from github came through properly, since I seem to be writing lots of code on issue comments today
@onyx hinge It should work the same way, with one backtick on either side. Is it not?
ah, hm, do backticks work there as well?
TIL
For all the GitHub fun available: https://guides.github.com/features/mastering-markdown/
I had to look up how to do links at least 20 times before I came up with a way to remember.
Brackets then parens... alphabetical order. 😄
afk, thanks again for the tip and the link @idle owl
You're welcome!
Yay, I have a running clock!
>>> time.localtime()
struct_time(tm_year=2018, tm_mon=3, tm_mday=25, tm_hour=23, tm_min=36, tm_sec=25, tm_wday=6, tm_yday=84, tm_isdst=-1)
rtc module diff
asf4 diff
samd21 diff
I'll see if I can make a PR next weekend so we can discuss the details.
@prime flower Morse Code resources: http://www.arrl.org/learning-morse-code Learning to receive is much harder than learning to send. For sending, using a straight key and a code practice oscillator are fine.
Key to learning is not to learn visually, but aurally. Receiving is like muscle memory. Having an extra mental step of converting dits and dahs into a visual image of dots and dashes and then the letter will slow you down.
Intermediate update. After expanding my breakpoints, seems at this point, that tick_rgb_status_animation either never calls new_status_color to update the color, or something during those calls is failing/causing purple. Atmel Studio continues to be an obstruction on retrieving some values (unless this is just the nature of hardware debug that I don't know; could also be since I'm running off of the ELF object).
Getting closer (I hope). Time to go do some adulting... 😒
new_stat...
Will revise pull request
Shall we fix slice assignment and concatenation so that different types are rejected, as in Python 2/3? If so I can work on generating a PR.
Another one to fix: constructing object arrays from bytearrays.
>>> array.array('O', bytearray("baaaaaaa"))array('O', [Segmentation fault
A bad typecode should be caught. In CPython 3:
>>> array.array('O', [1])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, q, Q, f or d)
and I agree slice assignment and concatenation should check that the types match.
Thank you for checking all this! I'm sure upstream (micropython) would be interested as well.
Can anyone else help with this. I’m not sure where to go with it. https://forums.adafruit.com/viewtopic.php?f=60&t=133095
@solar whale Looking.
Hmm... I don't know either. I think I've tried something like this before and had issues, but that doesn't mean it doesn't work, that simply means I don't know how to do it.
It's something in the syntax, it has to be
Or I'm totally off. But that's my first thought
That’s where I am too. I think the poster is missing something but I’m not sure what. Seems like they have some experience with python so I’m not sure what to suggest.
I've made that assumption about people and been wrong before, their knowledge may not necessarily apply to this issue. I would suggest having them try to simplify things, put the function in main.py or something, make sure it even works... I don't really know either. But start with something working first and then try to complicate it.
I’ll ask them to post their code and go from there. Thanks!
Thank you for helping them!
one bit of help might be to point them to this: https://learn.adafruit.com/welcome-to-circuitpython/creating-and-editing-code#naming-your-program-file
ask to see demo.py, not sure why import demo and demo.tester() didn't work
hey all... is there a reference somewhere for what properties are on the 'board' object, specifically for gemma M0?
@thin badge can just do dir(board) at REPL
... <grumble> I wish I was smart enough to know what you meant... Im literally doing "vi main.py" (because Im a dinosaur)
(although google helps)
😉
yah, google probably helped with the acronym. but check here:
https://learn.adafruit.com/welcome-to-circuitpython/the-repl
<nods> thanks... Im there... 😃
👍
I have to say... you folks / this community is one of the most (if not the most) friendly, helpful, and knowledgeable community I've ever stumbled upon. Thank you for being you
when you get to REPL, try this:
Adafruit CircuitPython 2.2.4 on 2018-03-07; Adafruit Gemma M0 with samd21e18
>>> import board
>>> dir(board)
['A1', 'D2', 'RX', 'SCL', 'A2', 'D0', 'TX', 'SDA', 'A0', 'D1', 'L', 'D13', 'APA102_MOSI', 'APA102_SCK']
>>>
hopefully that's what you are after. i don't think we have anything that documents this for each board (that i know of). it varies from board to board. but you can do this with any of them.
yeah... basically setting up a "blink" example and what I thought should blink (pin lable D1 / ~A1) is actually blinking the onboard led (Gemma M0)
*label
the on board LED in on D13, which is only routed internally and not available on any of the pads
do you have an external LED attached to D1?
I have a small neopixel strip attacted to D1/~A1 which I had working via arduino / C but now I want to learn circuit python (that Im not under a time crunch for a hallowwen costume) 😉
and yeah... mu seems to be a lot nicer than the arduino editor...
#helpfulErrorLogs
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
main.py output:
Traceback (most recent call last):
File "main.py", line 5, in <module>
ImportError: no module named 'neopixel'
while I understand that lack of a library shouldn't be why Im seeing blinks on the embedded LED, this should be something I need to track down, right?
@thin badge If you surround a bit of code with one backtick on either side (the one in the upper left of a US keyboard, on the tilde key, next to the 1), you get inline code and if you surround code with three backticks on either side, you get a codeblock
It can make it easier to read code snippets 😃
just like slack... 😃
yep. you need the neopixel library if you're going to work with neopixels.
they aren't like regular standalone LEDs
that same guide covers libraries: https://learn.adafruit.com/welcome-to-circuitpython/circuitpython-libraries
ok... so not embedded by default in circuit python... Is this a situation where I install it into my python install and... or I could read the "fine" manual... <hangs head in shame>
when you read the guide, keep in mind you have a "non-express" board with the gemma m0
thank you... Im certain that would have been a future question... 😉
and this could help as well in case you haven't found it yet:
https://learn.adafruit.com/adafruit-gemma-m0/circuitpython-neopixel-2
although that guide has a circuit diagram with the pixels attached to D1/A0, but the code uses board.A1 ?? hmmmmm.....
Oops. Good catch.
YES. that is exactly what Im looking for!
'O' and 'P' arrays are deliberate MicroPython extensions inherited by CircuitPython—see tests/basics/array_micropython.py.
array.array also accepts an 'S' typecode in MicroPython/CircuitPython, but it looks like that one may be an accident. It seems to be in support of the ustruct typecode extension in MicroPython but not in CircuitPython:
This module implements most of character typecodes from CPython, with
some extensions: …
S - Pointer to a string (returned as a...
@tidal kiln Can you look at the NeoPixel page again please? I updated the diagram
@idle owl looks like correct pin. where'd the green squares on the pads come from?
yah. that was my guess.
weird oddity though... I went through this... thing where mu must have used the gemma as a location to store temp files or something and whenever I started it, it would fill up the gemma drive with images / sounds / etc... started it with the gemma off and all was fine.
@thin badge its a known problem with Mu. they're working on getting it taken care of
images of a cute alien by any chance?
if they haven't already...
This'll give me a good starting point. Going to try to port a variant of the "cosmic turtle" necklace over to circuit python... Should keep me busy for a bit.
yes, alien
@tidal kiln ^^
thank you all for helping me get off the crazy bus.
fixed. but will be in next release:
https://github.com/mu-editor/mu/issues/358
One more:
>>> array.array('O') + 'baaaaaaaa'
array('O', [Segmentation fault
ok... one last question, only to satisfy my EE ignorance... When I crack out 'ye olde multimeter' and I measure DC voltage on ground & Vout, I get something in the 4-4.5 range (expected) but when I measure ground and D1, I have to flip the meter to AC voltage because the "signal wire" communicates with AC, right?
even in AC mode, you won't get any meaningful measurement on the data line with a multimeter
you'd need a oscope or a logic analyzer to see what's going on
I mean, I see the values 'pulsing' (for lack of a better term) between 0 and 185micro volts. (I think thats what the greek letter mu means, right?)
it just tells me that there's voltage "there" not what it's actually doing...
(and an oscope is a bit out of my price range unfortunately)
you'll see some indication of activity, but it doesn't really tell you much. it's a very fast digital signal.
<nods> but it was something that wasn't there before... 😉
ok... back to my cave... thank you AGAIN collective hive-mind. You're the best!
i guess it can tell you something is happening vs. something is not happening
@thin badge some multimeters have a "frequency / duty cycle" mode that can be helpful in detecting pulse activity on a pin. On the EXTECH meter it's called Hz%.
As discusesed in #707 there are a number of ways to cause crashes with array('O'). This PR fixes the ones I know about, and adds testcases related to each one.
In #530 we discussed the idea of setting the device's label to something other than CIRCUITPYTHON (for instance, named after the board type or incorporating part of the board's unique serial number). This PR adds the ability to get and set the filesystem label with a sequence like storage.getmount("/").getlabel().
However, it's not particularly satisfactory as in normal usage you can't setlabel the main storage from main.py, since it is mounted to the PC and is readonly to CircuitPython...
In light of the problems I outline in the summary, I don't think this one's actually worthy of being merged into CircuitPython. It takes up a small amount of flash for no real benefit.
'O' and 'P' arrays are deliberate MicroPython extensions inherited by CircuitPython—see tests/basics/array_micropython.py.
Ha! I didn't realize that. I looked in the MPy readthedocs and that wasn't listed. I thought 'O' was just the result of some fuzzing testing.
This change adds the -Wno-error=lto-type-mismatch only when supported by the underlying gcc (7.2 supports and needs it, 5.4 doesn't support or need it).
It also removes one -Wno-error=lto-type-mismatch that is unnecessary since #686 was merged.
@jepler Are you personally interested in building with gcc 5? Our general philosophy has been to use the latest release (after testing). We're not trying to be backwards compatible, because we're building with a known toolchain for our own purposes and only a limited set of architectures. We keep up with the latest release to get better optimizations, bugfixes, etc.
For instance, I would like to remove the -Wno-error=lto-type-mismatch once the fix for the 81440 gcc bug gets into the ARM re...
One last update for tonight. Still expanding the breakpoints, but not exactly closer. Trying to rectify why tick_rgb_status_animation never calls new_status_color, like its supposed to. Two things I'm focusing on are values for neopixel/apa102_in_use (can't get trace info on it), and the reset_pin function which doesn't seem to be firing. Those two together are logical reasons why `common_...
You've been awesome with feedback so I'll nitpick just a smidge more. This should be USB_RX_BUF_SIZE - usb_rx_count > CDC_BULKOUT_SIZE here and below. This works now because USB_RX_BUF_SIZE is 128. This will break if we make that buffer bigger.
😃
@onyx hinge keep on rocking finding issues! will follow up on issues now. I try to step away on the weekend (though if you ever want to collaborate and weekends are best just let me know.)
@jepler please enable the high quality hash in our builds.
Yup! I'd be great to have this.
@jakebird451 what do you want to do with it? HTTP API? MQTT? We may want to abstract away the lowest level of the network in favor of providing CPython staples like requests.
Thank you for finding and fixing this error!
This makes the super().p case match CPython now right? Could you please update/remove the comment in the test because it implies its still incompatible.
Your change to gc_long_lived is more correct. make_obj_long_lived is already smart enough to long-live the fun_bc as it did before. The closure object itself will be made long lived (aka moved) but any pointers within it will not. This will fragment the heap a bit but its not the end of t...
@jepler Overall, we choose to align with CPython instead of MicroPython. So, my vote would be to remove 'O' and 'P' support.
+1 To using the latest arm gcc release.
No need to have a break after a return.
USB_RX_BUF_SIZE - usb_rx_count > CDC_BULKOUT_SIZE caused REPL to be non-responsive. Puzzled me until I thought about the truth table.
usb_rx_count = 0 # REPL will always start at zero
USB_RX_BUF_SIZE = 128
CDC_BULKOUT_SIZE = 64
if ((128 - 0) > 64) { return > 0;}
All that was needed was flipping the buffer to the other side of the eval. Tests successfully.
@raven canopy you are supposed to be asleep 😛
says who? hehe. I'm still ahead of my goal of "before 2AM"...
are you west coast of the US?
Central. head hangs slightly lower in shame 😄
😄
thats why you should be asleep. thats why I working this late for myself 😄
gives me a jump on the week
its this spring forward business. gets me every year...
Great job finding and fixing these errors! However, I'd rather not support an array type that CPython doesn't. We want CircuitPython to be portable to CPython and supporting things like this risks breaking that.
takes me a couple weeks to adjust. it gets worse...then i finally get tired enough.
ok. shutting down vagrant...again. 😄 i should probably program the coffee maker. might need that last "alarm clock" in the morn...well, 4ish hours from now. (it's a built-in grinder type)
good luck! its all much appreciated
Awesome work! A early PR would be very welcome!
If you are only able to be online weekends we can coordinate times so we can chat. I usually try to avoid work on the weekend but can trade weekday time to weekend time to coordinate with folks. Let me know. (Discord is an easy way to contact me too.)
What version of upstream? We're on 1.9.3 still. (We only update to released MicroPython generally.)
That purple color could be my fault... I may have added it during debugging. I did reshuffle the order of reset_mp calls which may have made this more obvious.
I vote you remove the purple line.
To reproduce:
- Write a file with an infinite loop but no
inputcalls. - Type a bunch of characters besides ctrl-c.
- Type ctrl-c to break out of the loop.
- The first of a bunch of characters satisfies the any keypress to enter repl and then the repl gets the rest.
Instead, we should clear the input buffer after main finishes and before we wait for another character.
One last thing. This will always be true because USB_RX_BUF_SIZE - CDC_BULKOUT_SIZE is always more than zero. So, just return true;.
@dhalbert I use Debian Stable, and gcc5 happens to be the ARM toolchain that is available there as a proper debian package. Aside from the issue with this flag (which, as you say, is actually a workaround for the 7.2 compiler being broken in a particular way!) gcc5 seems to do a perfectly adequate job at building circuitpython.
I can (and will have to) continue carrying this patch locally, but I wanted to offer it in a cleaned up form for anyone else who runs into the same problem.
As ...
@tannewt prefers to remove support for these micropython extensions to CPython, so here's a PR to do that. This is mutually exclusive with #711 so that one should be closed if this one is accepted, and vice versa.
@tulip sleet @slender iron It appears that PulseIn is not implemented for the ESP8266 - Is this a known issue? https://github.com/adafruit/circuitpython/blob/master/ports/esp8266/common-hal/pulseio/PulseIn.c#L37
I found that the DHT22 driver does not work under CP3.0 - It works under 2.x - I filed an issue in the Driver but I wonder if it is a CP issue. Any thoughts? https://github.com/adafruit/Adafruit_CircuitPython_DHT/issues/7
I only tested with the tip of the mater branch at micropython.
I think the fix is simple, these assertions should just be changed to generate Python exceptions. I can roll a patch to do that.
This may just affect the ports/unix environment used for testing (the filename is ports/unix/modusocket.c so it's not shared with real hardware). I don't have any CP board with networking so I can't test there.
It looks like 'O' and 'P' typecodes were usable in both struct (aka ustruct) and array.array. Instead of testing for the exceptional case, could you #ifdef out the support for 'O' and 'P' (and 'S'?) in all places where it's mentioned (like the switch statements in pybinary.c -- not sure if elsewhere)? Use something like MICROPY_NONSTANDARD_TYPECODES which you can add to mpconfig.h with a default value of 1 and then set to 0 in atmel-samd, nrf, and esp8266? That way the cod...
Closing in favor of #715.
OK, I took care of making it a property. I'm not sure what to do about the exception in setlabel; do we want just a special case for the "read only" case, and otherwise return the current numeric error?
002797a is good. d57397f will break frozen module support in circuitplayground_express for gcc 6 and up: that's the primary reason for including -Wno-error=lto-type-mismatch.
Another example of toolchain version issues we've dealt with is https://github.com/micropython/micropython/issues/3526, which is a bug that appeared with gcc 7. This was closed upstream with a fix I'm not sure is going to work for us.
Thanks for the offer, but I'm not much of a chatter :-)
I mostly do Linux kernel development so I'm used to discussions on mail which suits me fine.
And since I love reading code more than writing it, I prefer to dig around the code base to answer my own questions when I'm stuck. I've set up elixir so I can browse the CP source like I can do with Linux: https://elixir.bootlin.com/linux/latest/ident/start_kernel
Ofc the code itself isn't so ...
When trying to use a DHT22 on an ESP8266 - this error is returned:
>>> import dht22_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dht22_test.py", line 7, in <module>
File "adafruit_dht.py", line 190, in temperature
File "adafruit_dht.py", line 143, in measure
File "adafruit_dht.py", line 106, in _get_pulses
NotImplementedError:
https://github.com/adafruit/Adafruit_CircuitPython_DHT/blob/master/adafruit_dht.py#L106
I did no...
@dhalbert d57397f just removes one of the three sites where that flag is added. It leaves the ones which are actually required to get a clean build on travis.
I think I put a few too many irons on the fire, with all those pull requests...
Ah, got it. Yes, a PR with those two would great. Thanks!
It is also not implemented for the nrf52. Changed title.
@solar whale I didn't think 2.x esp8266 had pulsein either
it doesnt -- so dht support was lost with recent changes
I guess it only worked via "machine" before.
I'm trying ... I was suprised it is not implemented in nrf52 either
its early days for nrf 😃
true - I had not realized how long its been since I played with a dht on anything other than an atmel-samd
😃 we'll get there, it just takes time
Not a problem for me - I was just trying to help a forum post re:dht22 ...
otherwise I think the progress has been at blinding speed!
It looks like I pushed the wrong branch when trying to update this PR, will fix it when I get home and can double check things.
@dhalbert I'll re-roll this PR based on your requests.
@slender iron removed that new_status_color(purple) line in reset_mp; no dice. Will have to continue hammering i think, after work.
anybody built circuitpython to boot on bare metal x86 ? Just noticing an article recently on the adafruit blog, https://blog.adafruit.com/2018/03/24/implementing-micropython-as-a-uefi-test-framework-micropython-intelsoftware-by-intel_brian/
@raven canopy weird!
@onyx hinge I haven't tried it. I know someone was working on rpi bare metal
Is this related to my purple LED?
@idle owl ish. it doesn't depend on a freeze. its just the wrong color by correctly running main
Yeah. Unless there's been changes in the few days that might have resolved it.
4 days since I last pulled apparently.
there's a helpers meeting this PM, correct @slender iron?
<@&356864093652516868> Meeting in nine minutes! Sorry I forgot the heads up last night
@idle owl k, lets take a look after the meeting
here but textonly
awesome @timber mango
@slender iron Thanks!
np
text only as well, strep got the better of my throat this past week (almost better though!!)
@idle owl really good guide on that (https://grathio.com/2012/04/flying-with-homemade-electronics/), btw TSA didn't check my luggage which had a Saleae two weeks ago (YMMV, but the soft-case it has is pretty incognito)
<@&356864093652516868> Meeting time!
@meager fog are you going to listen in but only type back?
I had that thought too @idle owl !! 😁
Either clock or we're actually having a VALUE_EXCEPTION...
my big hug goes out to @onyx hinge for fuzzing work. I’ve used fuzzing for a web app’s bug, but it’s really fascinating to watch you hunt bugs and resolve them. @dan for USB-HID work. @slender iron for the newsletter, it’s lookin’ great!
group hug
@slender iron cant listen in - just hanging out
👍
group hug!
HUGS: @Dan Halbert for tackling the thankless USB HID in ASF. @kattni, @jerryn, @CGrover, @siddacious, @Andon, and others I'm sure I missed, for helping out on discord and forums; seeing multiple people state how they appreciate the community is awesome!!! So...group hug!
@meager fog any hug reports?
Sorry to be late. No mic today, just text.
@slender iron thanks to the git contributors, y'all are doing some great work and finding sneaky bugs! jepler, sommersoft, arturo182 and others!
Group hugs for amazingly prolific work on 3.0 and an extra special one to @slender iron for a quick review of some string car code. It was extremely valuable and helped me to move forward in my quest to learn Python.
I put a little GIF of a CPX running the morse code hid keyboard code in #show-and-tell yesterday. Going to try to finish that up this week, it’ll be a arduino and CP dual-guide, along with an adafruitio guide idea I’m playing with.
Also - I’m looking for people to take a look at the code examples in MetroX-CircuitPython. example or two (https://github.com/adafruit/METROX-CircuitPython/issues/3).
I can toss a guide PDF or link to match the tutorial guide, if you dont have learn author access but want to use the wiring from there too
defer for a bit, please...
I can't unmute
I will type
I have another batch of the µGames ordered from the fab
I'm also working on a much simplified and cheaper version that could be useful as a conference badge
(with the flash chip and with an OLED display)
not going to PyCon.US, but going to EuroPython
UART, I2C, CPU temp are all mirrored in.
Storage is finished, waiting on final approval.
HID Mouse and Keyboard are finished and waiting on first revision.
That's it!
Finished the StringCar CPy code -- new motor control and string length schemes. Adapted the string car code to a model train controller that will become a learning guide. Starting the Corrosion Monitor conversion from Arduino to CPy. Made excellent progress with Feather M0-RFM69 and ILI9341 FeatherWing display drivers. Snowman (holiday lights) parts arrive from DigiKey today. Will probably develop a learning guide around that, as well.
🎉
So... I made this thing. I call it a Trampolantern. https://t.co/guiizO9EAI
511
2816
STATUS: light polishing on REPL fix, but is pretty much done. serial_connected just needs one last test (battery swap) before merge. Working on 3.x purple pixel. Put FRAM on the back burner to focus more on 3.x issues that are in my skill set/ability; will scoop future projects from there.
@meager fog any status updates?
Running the basic test fails under CP3..0 alpha (current master)
It works under CP 2.2.4
Same boards, only change is reloading CP and libraries.
Adafruit CircuitPython 3.0.0-alpha.3-31-g8b6aeb9-dirty on 2018-03-26; Adafruit Feather M0 Express with samd21g18
>>> import lora_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "lora_test.py", line 26, in <module>
File "adafruit_rfm9x.py", line 363, in __init__
File "adafruit_rfm9x.py", line ...
that would surprise people who didn't look at the repl
@stuck elbow totally agree
Can we inherit (_main_) versus import?
g2g, 👋
>>> execfile(blink1.py)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'execfile' is not defined
"reset and run this file"
that would be perfect for my game picker menu
any one of them works for me
no, wait
as long as it doesn't survive hard reset, any one is good
the way I would use it, I would have a menu app in the main.py and then it would reset and run your game
so I still want to run main.py by default
yes, reset_and_run("filename.py") would work for me very well
come again?
but then I have no way to go back to the menu
and with broken games?
as long as the name you set is not "sticky"
👍
Thanks for the warm words, @prime flower @timber mango and others. I enjoy finding and fixing bugs.
another thing that would be great is the ability to display the REPL output (including exception tracebacks) on my own device, like the display
micropython on the esp8266 has some weird system of cloning the repl
but I haven't figured out how to use that
Thanks everyone!
Thanks everyone!! Go forth and be awesome (so, stay the same)!!
thanks!
WebUSB OTA updates? Hahaha
... unless the NeoPixels are from different generations. Older ones are more sensitive to cable length; data voltage threshold issue.
Alrighty, back to the day job...
The keyboard thump-click sound is so becoming the part of my weekly experience that I'm shopping for a new clicky keyboard for the desktop. Been wanting to go back to the ol' VT100 style keyboard where I did a lot of Fortran and PDP-11 macro assembler coding anyway.
It's a very soothing sound. I've been shopping on WASD already.
I have cherry browns in mine
oooh is it time to talk about keyboards? 😍
always 😃
I divide my time between a WASDv2 TKL and a Unicomp and love them both
Got to order the sampler and test the difference for myself.
make BOARD=metro_m4_express DEBUG=1
-j3
gotta step out, thanks guys!
I don't know how it would work out exactly, but I wish I could put CircuitPython in a keyboard, and enter the in-keyboard REPL with a keystroke.
i hate to admit it, but i have no idea what i'm doing
period
i haven't even gotten to coding anything, i'm having trouble getting mu even properly set up i think
It'd also be useful if a file to run on reset could be specified. This would let people use this in main.py to specify a different file to run and eliminate the need to rename. Or it could be used in a more complex way like a menu system to allow selecting one of the other .py files to be run programmatically.
@unreal ginkgo were you trying to follow this?
https://learn.adafruit.com/welcome-to-circuitpython/installing-mu-editor
@onyx hinge I know of two keyboards running circuitpython
@unreal ginkgo what OS are you using?
@slender iron links please!
windows 10
@onyx hinge https://imgur.com/a/AAtnz
@slender iron that looks great!
@slender iron I'l take one when you go into production
that won't be happening any time soon. I'm happy to show you how to make one though
either i can't find the way to launch it with what the install came with
or the .exe i downloaded from codewith doesn't let me use adafruit stuff
@slender iron you could even make a Adafruit feather powered PC cooling
@unreal ginkgo what happened when you ran the .exe that got downloaded?
just automatically went to the microbit one and there was nothing in the corner that i could interact with to change it
so it at least ran?
yeah
just didn't show any adafruit releated options?
not a one
dht_simpletest yields:
Adafruit CircuitPython 3.0.0-alpha.3-31-g8b6aeb9-dirty on 2018-03-26; Adafruit Feather M0 Express with samd21g18
>>>
>>>
>>> import dht_simpletest
('A full buffer was not returned. Try again.',)
('A full buffer was not returned. Try again.',)
('A full buffer was not returned. Try again.',)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dht_simpletest.py", line 18, in <module>
KeyboardInterrupt:
>>>
under ...
@unreal ginkgo what is the name of the file you downloaded?
I’ll check when I get home, sorry to keep you waiting
Have a good afternoon or whatever your timezone... - have to go off for a bit
later @solar whale! Have a good one!
<@&356864093652516868> Here is the video of today's meeting: https://youtu.be/G1VCdbNQvyU
Notes with timecodes are available here: https://gist.github.com/tannewt/c4477bf1c7f87c6ed7e8ba10b8e4f6aa Join here for the chat all week: http://adafru.it/d...
@notro All good! Feel free to email me at scott@adafruit.com if you have questions. I'm happy to talk about cultural stuff.
Yeah, first take a look to see if its been fixed up stream.
@unreal ginkgo I installed mu_2018-02-21_15_12_master_2a33437_32bit.exe on Windows 10 and it asked me on launch to select between Adafruit and the other modes. The download link I used is here: https://learn.adafruit.com/welcome-to-circuitpython?view=all#installing-mu-for-windows-or-mac-os-x
@raven canopy @slender iron thanks for that fix!
Yeah, limiting to the read-only case would be good. :-) Thanks!
Yeah, that’s the thing
I couldn’t figure with what I installed where to launch from
I had to get something to launch with from a separate site
@unreal ginkgo It just showed up in my Start Menu as "mu", and I clicked that. So sounds like you were running the old version using the other thing.
it is under "M" in the Start Menu and also showed up at the top as "recently installed"
Alright thanks
see you later if you have trouble
@raven canopy Tried the latest CP 3.0 master with your REPL fix on feather_m0_express and metro_m4_express_revb -- works great!
thanks for your testing @solar whale. wouldn't have been as great without it. 😄
oh why did I say to myself "I can probably duplicate the core functionality of numpy in a day or two"? (not related to circuitpython, but related to python..) 💩
"it'll be easy, I'll just use boost::python and boost::ublas" and now I have a single, 550 line file that takes as long to build as circuitpython does for trinket_m0
ok! @here this is published ! Nicholas Tollervey - Visits Adafruit, talks code, community & Mu https://youtu.be/L1wYvTRzM2c
ntoll visits Adafruit and talks with Ladyada about all things Python, education, communities, and the Mu editor. Mu is a simple code editor for beginner prog...
yay \o/
this is also in our newsletter that comes out on tues - http://www.adafruitdaily.com
Yay, it’s one of my favourite people, Ntoll!
we take links and more in github for each one.. https://github.com/adafruit/circuitpython-weekly-newsletter
We added a check to make sure the pins are in a high state before
initing the bus. This leads to a friendly error message when someone
forgets to add the pull up resistors to their circuit.
yaaas! do you want to briefly turn on the weak pull down resistors, then turn off and check that they float up within 1ms or so? that will detect missing pullups & floating pins
huh, that's weird.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: 22
this is FAT
os.stat("/") works as expected
I don't think it actually has "." entries
I bet you're right
maybe i just didn't read the answer to this when it was right in my face
but all i can seem to get this to do is the basic stuff for code.py
there's probably just something in my face that i'm completely misunderstanding
but i'm slowly kinda sorta figuring it out?
all i've got lit up is the green led and the red led that i can kinda sometimes make blink like that one thing showed how
should this use MICROPY_FATFS_USE_LABEL instead?
i'll be honest i have almost no grasp on coding
@unreal ginkgo nothing wrong with that! we all started at zero... 😄 Which board do you have?
finally got my circuit playground express today
ok. I was kind of hoping it was a CPX. You could try starting with Microsoft MakeCode for the CPX. It's a web-based visual, "block" based system which is designed to teach things like program structure and flow. It actually a pretty robust system. https://makecode.adafruit.com/
Then, once you're comfortable, you can come back to CircuitPython with a little more knowledge. Just a sugestion. Python, and CircuitPython we hope, is fairly easy to learn compared to other languages...
i was using that but i wasn't sure how to use IR remotes or add in custom assets
i have most of what i made in there, it's simply starting off with getting used to how things work that's got me confused
Ahhh. Good deal. Yeah, there are some things like IR that aren't quite available in MakeCode (yet?).
yeah, i have most of the extra sounds i'll be using as well, just kinda not sure where to start off with all this in general
i can get the red light to blink, and that's about it
are you following any specific guide?
okay then
i guess the guide i was using wasn't exactly working
huh
tried using the remote control ornament with a non-adafruit remote
it got the red light to light up when hitting buttons but no other lights
ok. i was just looking at that guide. did you read the codes that your remote is sending, and update your program?
this will help you with reading the codes that your remote will send for each button. https://learn.adafruit.com/ir-sensor/circuitpython
i think it's from the fact i'm using just some remote i found in a box
yeah. you'll need to re-map the code to respond to your remote. the code in the guide is specific to the adafruit remote.
not necessary; you just have to do a little work/learning to use what you have on-hand. win/win if you ask me. 😄
i understand what you're saying and i agree
it's just a pretty old and probably almost a foot long remote, and wouldn't really be practical in the long run
well, back to uh
whatever i was doing
hehe. good luck! we're here most of the time if you hit any more speed bumps.
thank you!
wahoo, ripping out support for nonstandard array('O') and related items frees up 368 bytes flash over here and fixes several crashes you could get by using it
hopefully I understood properly what @tulip sleet was requesting, and that travis likes my branch...!
All Hail Lord Travis! 👑 😝
honestly
all i need to do until i get a remote is figure out how to convert this into python stuff
just 4 or 5 simple things
i think it's more of the like
putting in what colors things will be and then using those things later on that's gonna have me the most confused
im the kind of person that will sift through the tutorials, looking for that one thing i need, and mess with it to my own liking, i'll just take help along the way
OK, this is now completely revised with @dhalbert's most recent suggestions. Eliminating these non-python3 compatible typecodes saves about 360 bytes of flash, so that's nice.
@tannewt I revised the doc-comment at the top of tests/basics/core_class_superproperty.py to reflect that we now match cpython3's behavior here.
havent played with circuit python too much yet...thinking of sewing some LEDS into an overwatch hoodie of mine and getting some lucio sound files from the game to play at the push of a button..is this something that circuit python can handle?
this question is important to me for difference franchises
❤ ive been a blizzard fan boy as long as i can remember
What's the easiest way to build a V2.2.4 for a new board (Trinket based)?
I tried the vagrant instructions but it builds V3...
@onyx hinge you understand me perfectly! thanks!
@jovial pine checkout the 2.x branch
https://emergent.unpythonic.net/01522108310 I wrote a little blog post about using afl-fuzz on circuitpython.
hhhhuh
do any of the tutorials for circuitpython involve the A or B buttons?
@unreal ginkgo for the CircuitPlayground Express?
yeah
hmmm. there this little example here:
http://circuitpython.readthedocs.io/projects/circuitplayground/en/1.2.1/?highlight=python#usage-example
and also some short examples in the ref doc:
thanks
@idle owl know of any others? (see above)
@unreal ginkgo @tidal kiln https://learn.adafruit.com/adafruit-circuit-playground-express/circuitpython-digital-in-out
thanks!
there's a lot of the stuff that i see, and miss a ton of stuff while browsing
@onyx hinge I'll add that for the newsletter next week!
Is there a way to get REPL in Atom editor
Not easily. I usually just have it in a separate window
OK
If you wanted to hook Circuit Playground express to network can you use ESP8266
I've updated this PR so that it only removes the -Wno-error... flag where it is not needed even for buggy gcc 7.2. I think the other of "those two" that @dhalbert mentioned in comments was already merged in #686.
This assertion could be triggered by a number of patterns found by afl-fuzz, such as del str.partition, property.start = 0, etc.
basically making it flash real fast
sorry for all the questions, but hey, i guess it's learning?
if the answer was staring me in my face i'll be amazed, lets try
When we build projects using the CircuitPython boards, we will often connect to them output devices, such as character displays, LCDs, OLEDs, LED matrices, thermal printers and so on. That potentially gives us the ability to display debugging output and exception traceback in a more convenient way, without having to connect to the computer to see the serial communications. We just need some way to plug our own function into the REPL output.
As far as I know, the ESP8266 has that capability...
thanks for helping me get another PR to the point it could be merged @tulip sleet
@stuck elbow have you looked at pygame zero at all?
anyone want to try and replicate this? https://forums.adafruit.com/viewtopic.php?f=60&t=133109
@slender iron I don't have the DS1x280, but I can try with some other sensors. I have the same display and I expect this is the problem. - Might it help just to add a gc.collect() in the loop?
I'll try it this evening if I can get to it.
@solar whale perhaps. I was also guessing that there is a bytearray thats allocated every change and then transmitted. instead, it could be created once and then updated
thanks @solar whale !
@slender iron @solar whale i happen to have all that hw. i'll take a look.
....and running. there's a ~5min delay in the program. crashing after 10-30 minutes is only 2-6 passes through the loop.
well, i've exceeded their reported 30 min max run time. still no issues. so can't recreate.
@slender iron I did, briefly, when Daniel just started on it
i'm going to take out the delays and start it over.
@tidal kiln good luck - hard to debug an irreproducible error. .... I wonder if it is worth monitoring gc.mem_free() as it is executing to see if it varies wildly. I have a similar test using an OLED and the free memory clearly cycles.
I have written a bunch of oled drivers for mp that avoid memory allocation alltogether
could be ported easily, especially the spi ones
but the ht16k33 driver I wrote a long time ago, and I didn't care about such details back then
It would be nice to reduce the ht16k33 footprint since I have found it hard to use on an M0 with sensors. Run out of memory pretty fast.
the font data takes up a lot of space, being stored as a dict of tuples
could be stored as a single bytestring instead, that would be much smaller
It will be a good learning experience - I'll be happy to dig into it.
@slender iron @solar whale so far, can't replicate the issue. i've asked for version info in case that matters.
thanks @tidal kiln
hi hi @here 1 more day to sign up before the next @river quest #circuitpython-dev newsletter from http://www.adafruitdaily.com is sent out - ALL THINGS PYTHON ON HARDWARE & MORE!
newsletter
"irritant-in-residence" 👍
Which branch do I compile for V2.2.4? I've successfully built and installed a custom UF2 bootloader, and can build the V3 beta, but need USB_HID which I gather requires V2. I'm unsure which branch to select for V2.2.4. I need to do a custom pin assignment for my OneHand keyboard.
@jovial pine - just do ```git checkout 2.x
make -C mpy-cross
cd atmel_samd
make BOARD=<yourboard> clean
make BOARD =<yourboard>
Thanks I'll give it a whirl.
you need to rebuild mpy-cross then build the board. in 2.x there is not "ports" folder.
The branches I tried kept giving compile errors on the board make.
what board are you building for
don't forget git submodule update --init --recursive [FIXED]
oops - sorry!
I was trying the default zero.
isn't it git submodule update --init --recursive ?
oops yes
CircuitPyhon is a fantastic system, but I've been more bare metal up til now.
hhhhhuh
it's always hard to figure out ~if~ how something is gonna work when you dont have that something
@jovial pine so after checkout of 2.x do the git submodule update --init --recursive then it "should" make...