#circuitpython-dev
1 messages ยท Page 275 of 1
Still works on SAMD21: Trinket and Metro M0
@idle owl I would deinitely say "Bluetooth Low Energy (BLE)" or something like that. Plain "Bluetooth" usually implies classic Bluetooth
@ivory yew Hope your vague attempt goes well enough ๐
@tulip sleet Yeah that's why I asked. Ok thank you.
@onyx hinge maybe the bitscope doesn't get a stay of execution. that's much cleaner.
or do I have those backwards
@idle owl and "Bluetooth LE" is correct, "Bluetooth BLE" is not
800khz is "right" isn't it?
yes
ok so I labeled them backwards
but .. timing is changing by ~10%, and that's enough to matter
@tulip sleet Right like ATM machine. I'll go with the full name and acronym in parens. Thanks!
there is some trickery at the bottom of neopixel_write that fiddles with the timing values also
@tulip sleet yeah I looked at that and wondered if it was interrupts -- I introduced disable/enable interrupts indirectly in current_tick() , but getting rid of that didn't fix it
@tulip sleet Is it worth using words like "central" and "peripheral"? Or call them something less technical? Or both is what I was thinking? e.g. "This one acts as the peripheral, or some better word here."
I realise people have already done guides with these, so whatever they did probably works, but I figure if I'm going to do this, I might as well do it the best way.
@idle owl the trouble is that central and peripheral are best used before a connection is set up. Then the important distinction is server and client. A client talks to a remote service on a server. Usually a peripheral provides services, so it's a server, but there are exceptions, like a peripheral talking to the Current Time Service on an iPhone acting as a central
@onyx hinge I was looking for BLE pulse ox devices on Amazon
@tulip sleet ah ok.
@minor plume We do not have a driver for it, and no one is working on one internally. Please move forward with porting the driver, and remember we're here to help you along the way!
@tulip sleet So the controller is the server and the target is the client?
no, opposite
bugger ok
I'm going to come up with something else to call them for this guide then. Because it's not even clear to me ๐
the UART Service lives on the CPB, and is remote to the phone
This is two CPBs.
the client is the one sending the colors
Ok, got it, thanks
it sends to a remote UART service
i will get lunch
@hierophect This looks good to me. Let's also make sure that the SPI objects always default to 0,0 as well. If they had, then this would have worked.
That's a good point. I'm not sure what the optimizer was doing in that case then, it was definitely causing some weird timing when I was varying between different settings. But testing the latest version with them gone seems to work fine, so I'll remove them.
When I wrote my first CircuitPython library, which was a complex one, I referenced the Data Sheet and the Arduino Driver and looked at other CircuitPython libraries and the learn guides for reference.
Oh and I asked questions on Discord if I got stuck, but I think that was mostly at the end with the publishing part of it.
tested bin with 2.4" featherwing. REPL terminal and drawing work well - nice work :)
Oh and I asked questions on Discord if I got stuck, but I think that was mostly at the end with the publishing part of it.
@tulip sleet how is the filesystem stuff coming?
approval based on testing only :)
@slender iron it's really the .ld templating stuff right now. I'm about to get back to it after this morning's reviews and PRs.
๐
atmel-samd works; working on nrf
cool, I'm excited for bonding ๐
@meager fog @slender iron let me know if you've got anything immediate you'd like me to work on - otherwise I'll be moving back to implementing the Blackpill and meowbit
adding boards sounds good to me @ionic elk . I'm wrapping up my morning reviews now
also @meager fog let me know if you'd like me to pick up one of these https://www.st.com/en/evaluation-tools/stm32f4discovery.html. Makes sense to support since it's a 407
huh if you re-run an action on a commit, it throws out the old log
@dhalbert the 9th bit would be handled by the peripheral as part of the parity system, so it isn't actually part of the data. I assume when parity is used in 8 bit mode it simply disregards the 8th bit of data if you provide it.
@slender iron should I go ahead and merge Displayio?
no, did you reply to my comment?
"Let's also make sure that the SPI objects always default to 0,0 as well."
Oh sorry yes the defaults are at 0,0, I fixed both the core SPI module and the Fourwire library
ah, there it is
Looks good! Thank you!
Did you test this after you removed the nops? I'd expect it to change the timing slightly (more so on the slower clock speeds.)
@hierophect Looks like RS485 can use the 9th (formerly parity) bit to distinguish between data and command (eek). On SAMD, you can send 9 bits of data plus a parity bit plus a stop bit. 9-bit SPI is also available. So it can be a real data bit.
Yes, they're still within tolerance - works on the PYB Nano, Discovery. I'll give dynamic code another shot once the F401 gets added, since I'll have 3 test cases at that point.
@dhalbert I looked into it more and while it appears at first glance that you'd need to use the LLs to properly handle 9 bit data (they have specific 9 bit send and receive functions) it actually looks like the ST peripheral will simply spread the data out across two bytes for every send and receive when using 9 bit data without parity. From the user's perspective they'll appear to receive and send twice as much data, they just have to manage that conversion themselves.
I'm not sure what the python equivalent of this would be but if it was in C you'd simply cast the 16 bit array holding your 9 bit words as 8 bit and it should work ok.
https://community.st.com/s/question/0D50X00009XkWx7SAF/9bit-uart-transmission-stm32-cubemx-hal-driver
there were more, in the same file; but obscured by the way diff presented itself. I fixed them all.
fixed. I think it's ready for re-review @tannewt
@urish can you tell me more about your board? microcontroller, and which type of audio output, would be a good start. I tried your file on a pyportal and it seemed to be playing at the right speed and without any background static.
Updating from the discord conversation.
@jepler has a much better analyzer than me. It seems the issue is that the timing is about ~10% faster:
bad (917khz):

good (800khz):

This is a duplicate of #2338 but the discussion there is better.
@urish can you tell me more about your board? microcontroller, and which type of audio output, would be a good start. I tried your file on a pyportal and it seemed to be playing at the right speed and without any background static.
Sure, nRF52840 and PWM audio with a piezo buzzer. Should I build again and retry?
@urish I make a distinction between a piezo buzzer (runs on DC and includes a tiny oscillator) and a piezo speaker. Could you be confusing the two? (I'm new here, sorry for the kibitzing should I be getting in your way.)
It's a piezo speaker then, though its datasheet definitely calls it a "Buzzer"
If you play a wave file or rawsample with the same specs (sample rate, channel count, bit depth) is it playing at the right frequency or the wrong frequency? is the static noise the same or different? This will help us determine whether it's mp3s or any type of audio to move things forward.
This is also one of the problems that @urish encountered on #2337.
Reproducer:
import audiopwmio
import audiocore
import board
import digitalio
import time
values = {
'b': (-128, 127),
'B': (0, 255),
'h': (-32768, 32767),
'H': (0, 65535),
}
def go(at = 'h', channel_count = 1):
wave = array.array(at, [values[at][0]]) * channel_count * 24
for i in range(len(wave)//2, len(wave)):
wave[i] = values[at][1]
print(wave)
...
@jepler I converted the mp3 file to wav using Audacity, and the Wav file exhibits the same issues
@urish Ah, yes, the data sheet calls it a Piezoelectric Passive Buzzer. I guess a "passive buzzer" is a speaker. The company seems to make also make those with the circuit inside, what I have been calling buzzer. I guess I will have to accept that some speakers are called buzzers.
A workaround for this seems to be to specify a second channel: ```audio = audiopwmio.PWMAudioOut(board.SPEAKER, right_channel=board.A1)
Doesn't seem to do the trick for me, here's my complete code:
import board
import audiocore
import audiopwmio
print("PLAY")
mp3file = open("promo.mp3", "rb")
m = audiocore.MP3File(mp3file)
audio = audiopwmio.PWMAudioOut(board.SDA, right_channel=board.LED)
audio.play(m)
while True:
pass
I can see the LED connected to the board.LED pin light up when the file is playing (and turn off as soon as it's done playing), so obviously some output goes there, but the ...
@idle owl does your code that hard fault do scanning?
This? python if not uart_connection: print("Scanning...") for adv in ble.start_scan(ProvideServicesAdvertisement, timeout=5): if UARTService in adv.services: print("Found a UARTService advertisement.") uart_connection = ble.connect(adv) break # Stop scanning whether or not we are connected. ble.stop_scan()
yup
Then yes.
kk, I just crashed during scanning + usb
It does like to crash on reload, which means it goes back into scanning each time.
welp, it is happening a lot but the backtrace isn't very helpful. ๐
@urish does your board have an RC filter on the PWM output? Do you have a way to try fitting one? When using the CircuitPlayground Bluefruit's built in speaker there is a lot of "hiss" which I think probably comes from the interaction between the ~60-70kHz PWM carrier frequency and whatever the amplifier is doing. I get better audio when I use a PAM8302A amplifier breakout, and really quite good audio when I added an RC filter with R*C = 16kHz, chosen almost at random.
@idle owl what board are you testing with? CPB?
Yes
@gentle bronze @slender iron can you glean any significance from this set of steps?
serial_connected () at ../../supervisor/shared/serial.c:43
43 return tud_cdc_connected();
(gdb) s
tud_cdc_connected () at ../../lib/tinyusb/src/class/cdc/cdc_device.h:128
128 return tud_cdc_n_connected(0);
(gdb) s
tud_cdc_n_connected (itf=0 '\000') at ../../lib/tinyusb/src/class/cdc/cdc_device.c:97
97 return tud_ready() && tu_bit_test(_cdcd_itf[itf].line_state, 0);
(gdb) s
tud_ready () at ../../lib/tinyusb/src/device/usbd.h:56
56 return tud_mounted() && !tud_suspended();
(gdb) s
tud_mounted () at ../../lib/tinyusb/src/device/usbd.c:200
200 return _usbd_dev.configured;
This is on a F411 board I've been plugging at for a while. Seems to work ok but USB won't enumerate - doesn't show up on beagle, nothing. But given that other F411 boards like the pyb nano work just fine I'm puzzled.
does the 411 let you have different pins for usb?
No, everything's consistent. I've been comparing the blackpill schematic to the PybNano and the Discovery - there aren't any differences in terms of the USB connection other than the ID pin, which isn't part of USB C. I tied the usual ID pin down just in case, but it doesn't help.
if the beagle doesn't see anything then it points to a connection problem
that stack trace implies tinyusb doesn't see anything either
As in, physical hardware?
ya
Just to clarify, will tinyUSB care about the ID and VBUS pins?
I don't think so
hmmmm
you could start by getting the tinyusb example going instead of circuitpython
I saw this a bunch with the RGB LED. Here is the backtrace and then the backtrace after breaking when given the bad input. The cause is that when discovering the services available over a connection we're not handling the case where the discovery is terminated by disconnect. In that case, the service list to tuple code will read the internal connection pointer which is NULL and then attempt to convert the data at the list offset to a tuple. Fixed in https://github.com/tannewt/circuitpython/tr...
I'm worried they mixed up the pins or something, but since USBC SMT parts don't have a standard layout it's not really possible for me to check
@slender iron not getting anything with Thach's example sketches either, sadly
Calling it a night for now
@ionic elk was mobile today - yes meowbit might be fun now cause its has a screen you can use ๐ '407 is also fine...its a subset of '405 but i dunno if we want to bother implementing stuff like Ethernet? at least not yet ๐
@jepler not at all, but I can definitely order a new rev and fit in an RC filter. Currently I don't have an amp, so the audio output is directly fed to the speaker, but I'm thinking about adding an LM386 to the next revision.
I looked at the Bluefruit's schematic, and it seems like it includes an RC filter at the amplifier's input:

Or did I miss something?
That combination of resistor and capacitor in series looks like it is converting the audio signal to be AC-coupled.
The kind of RC filter I'm talking about looks more like this:

the resistor in series limits how quickly the capacitor can charge/discharge, smoothing the square wave of the PWM signal into a triangle(ish) wave of lower amplitude. The product R * C tells you t...
(also I'd choose a R*C product more like 20kHz than 200kHz, since 20kHz frequently represents an upper end of human hearing. Something that is above the 62.5kHz PWM frequency of the CPB will not help anything)
@urish It's I, Dar, butting in again. Have you checked out the speaker/buzzer for sound quality? Perhaps that is the weakest point in your audio chain. The same company makes buzzers with an oscillator inside that look much the same. Buzzers are typically designed to make an irritating BAAZP! sound. The one you have takes an external oscillator and is optimized for 4kHz IIRC. It should work as a speaker, but perhaps it is a very poor speaker.
@urish BTW, the piezo speaker is a capacitive load. For a low-pass filter, you might be able to just put a resistor in series with the speaker. (Or increase the value of it, if you already have one.) I don't know your circuit, but some drivers have a limit on the capacitance of the load, so again consider the resistor. Also, many assume an inductive load, as with your usual dynamic speaker, and a capacitive load might not work as well. I wish you well in your project and I look forward to hea...
This PR adds support for the STM32F411 "blackpill" style board found here:
https://www.aliexpress.com/item/4000068998794.html
Tested with a DRV2605 (I2C), BMP280 (SPI) + GD25Q16C flash, and Neopixel (when merged with Neopixel PR) with success. Test Pinmaps were:
B7: Neopixel
B8: SCL
B9: SDA
B13: SCK
B14: MISO
B15: MOSI
Bin:
firmware.bin.zip
Important notes about this board:
- For USB to work on thi...
wow thats...kinda terrible. why is that? :)
wow thats...kinda terrible. why is that? :)

If you're referring to the VBUS issue, it's because they didn't connect the USB's VBUS to the PA09 pin (presumably so they could expose the PA09 pin, which none of our other boards do), which as far as I can tell is required for the FS USB spec for any device that could be self powered (which is the case if the user had any other powe...
the built in DFU bootloader doesnt require PA09 to be pulled high, right?
@tulip sleet how is the fs stuff coming? did you finish nrf?
closer; I am just finishing removing CPy-dependent stuff from samd-peripherals. About to submit a PR for that. Just checking some builds.
nrf is really close to building or already does. This is a major refactor
how is the peripheral stuff related?
CALIBRATE_CRYSTALLESS and internal flash config region size setting
kk, coolio
I'm going to take a stab at a _bleio.PacketBuffer today
need it for media service
it is all configurable, and the firmware size region calculation is a lot easier to understand
could you accept my BLE library PR if it's OK by you now? That will help some users.
and fix the nameless advertising
ya, its queued up in my tabs to look at
great
i am paying off a lot of old technical debt right now; sorry, it takes a while
ya, it's good to do from time to time. just have to remember the goal of having bonding
not forgetting; the bonding region is all set up in flash now
I tried doing an ANCS demo at a meetup last night and kept getting disconnected
bonding will hopefully help auto-reconnect things
i am not going to do the .ld refactor on stm32f4 or spresense yet to save time
sgtm
the built in DFU bootloader doesnt require PA09 to be pulled high, right?
I don't believe it will, not without NOVBUSSENS on OTG_FS_GCCFG.
These sample_objs can also be mp_obj_t right? That'd make it clearer that the first field is the Python type pointer.
How about adding a per-board configuration to dictate whether NOVBUSSENS on OTG_FS_GCCFG is set? That way one doesn't need to manually connect the two.
@tidal kiln ping me when yr around and you wanna try MCP2221 - had good success
@tulip sleet this PR of mine is waiting for you: https://github.com/adafruit/circuitpython/pull/2356
i also would like to poke into whether we can receive multiple i2c bytes on ft232h - right now its 1 byte per ms i think
but wow MCP2221 is incredibly undocumented, i had to reverse engineer half their protocol based on what packet responses came back ๐
yah good suggestion - i think that would be a good board-level definition. i just know that nobody will remember to connect that pin and we'll see more low-cost STM boards that don't...
That'd be fine but if the user has an external power source, like a battery, or a power supply, then USB won't work.
Just a request for more doc. Looks good!
Comments about what these values represent would be nice.
agree but also that's a rarer situtation - to start most people plug right into USB and then will go ??? why doesnt this work :)
@slender iron I grabbed the UF2 you posted yesterday. I verified one more time that it would crash into the hardfault handler on reset (it did), and then loaded your firmware. It hasn't crashed since. Sometimes it took a while, but it was being really consistent for a bit there as well.
Thanks! This one was up there on the frustrating scale. ๐
BTLE is like that for sure
@slender iron im going to try out the BLE lightbulb once i get thru emails and meetings
so yr thinking is we have these as examples for now...then add as libraries? they feel...librarish
I'd be fine splitting them into separate libraries
Its easier to evolve them all in one as they are now but I can see how it'll get unwieldy
yah yah - ok its def ok for now!
the light has more characteristics than the github documents
I haven't tried poking at them
agree but also that's a rarer situtation - to start most people plug right into USB and then will go ??? why doesnt this work :)
I don't quite get what you mean but I'm happy to go with whichever option you prefer. I think the NOVBUSSENS conversations should probably involve Thach though, I don't know if he already does stuff with this. He doesn't use the macro in tinyusb from what I see in search.
Why won't USB work when on an external power source?
i mean most folks who have these little stick-boards dont wire things to them like batteries when they do initial testing. they plug it into USB and see if it enumerates :)
@tannewt If I'm interpreting the documentation correctly, the PA09 USB FS VBUS pin is used to detect whether USB is connected or not. If it is not connected to VBUS, then the usb peripheral has no way of detecting whether a line is attached or not, and relies on the main power line as the indicator on whether or not to try, and won't continue trying if it's unsuccessful.
I'm happy to be proven wrong on this, if I'm misreading or if there's another way around it, but so far my own test rig...
@hierophect I'm surprised that it wouldn't work if not connected because the SAMDs work just fine without a separate VBus pin. I imagine it is the host that initiates the connection rather than the device side.
Have you tried turning off VBUSSENS and tried it? From your post above, that sounded like an option.
Wait no I'm a dumb, there's no connection to VBUS that's separate from 5V so it'd be pointless to try and match that use case. Should we still check with Thach on NOVBUSSENS or should I just pop it as an option in supervisor/usb.c?
Hard code it to check that it works like we think and then add parameterize it if it does. No need to wait on Thach. He can always chime in later if need be.
Tested UF2 posted by @tannewt in Discord with a fix and so far I have not run into the Hardfault_Handler again.
@tulip sleet Now I'm getting this: Traceback (most recent call last): File "code.py", line 93, in <module> File "code.py", line 33, in send_packet File "code.py", line 26, in send_packet File "adafruit_ble/services/nordic.py", line 108, in write File "adafruit_ble/characteristics/stream.py", line 49, in write _bleio.BluetoothError: Unknown soft device error: 3002
Among other things. I changed the code, it's probably a code problem.
@idle owl that error is "invalid connection handle", so sounds like the connection got broken at an inconvenient time
Also getting <BLEConnection object at 20009cf0> object has no service <class 'UARTService'>
it may be connecting to another BLE device
@tulip sleet There aren't any others. It started after I added the switch to be sending a button packet.
I added KeyError to the send_packet try/except at the top and it's catching both of them now.
I just ate lunch and think we should add length checking to Advertisement. Then, subclasses like AdafruitRadio can set
extended_supported=Truewhen initing the superclass.
@tannewt So I can accept this and we need a PR to the BLE library? I think that's what you mean.
@hathach would it be possible to add a CFLAG option for disabling VBUS detection for the following part of dcd_synopsys?
// Enable VBUS hardware sensing, enable pullup, enable peripheral.
#ifdef USB_OTG_GCCFG_VBDEN
USB_OTG_FS->GCCFG |= USB_OTG_GCCFG_VBDEN | USB_OTG_GCCFG_PWRDWN;
#else
USB_OTG_FS->GCCFG |= USB_OTG_GCCFG_VBUSBSEN | USB_OTG_GCCFG_PWRDWN;
#endif
Thanks for all the info @jepler and @Dar-Scott! I guess I'm going back to the drawing board for now :)
Will update once I have a new design
@tannewt Ok, I've tried a hard coded version. See commit - it requires a new addition to the usb.h api, because it can't be placed before TinyUSB init or it gets overwritten, so it has to be inserted into supervisor/shared/serial.c.
Doing it in this kind of crude way, I've verified that it'll connect to USB the first time USB is plugged in even without VBUS, even if you power the board externally first. However, if you unplug the USB and plug it back in while the board is still on, it won...
@urish Great, keep in touch! I hope to have a chance to address the playback rate probems next week.
@tannewt also I'm interested in the fact that SAMD51s don't need to do this. It's considered a necessary feature by ST and the USB Specification. But there's clearly no vbus monitoring pin in the Feather M4, and it is FS, so I'm scratching my head a bit.
https://www.st.com/content/ccc/resource/technical/document/application_note/group0/37/48/d5/c9/ea/8d/4b/26/CD00004193/files/CD00004193.pdf/jcr:content/translations/en.CD00004193.pdf
@meager fog I'm curious, on CPB did you consider whether to put an RC filter between the PWM outut and that on-board amplifier? I suspect the lack of one is why there's high pitched hiss when playing waves/mp3s (interaction between the pwm carrier and the amplifier's oscillator). with an external amplifier it's better by default but adding an RC filter makes it even better. There's more in the notes on that mp3 PR.
@onyx hinge hmm i didnt think of it
if you give me the values you used i could probably wiggle one in
on a PCB revision
I picked something random out of the junk pile, and it's not in front of me right now. I think that R*C ~= 14kHz. Something that is going to almost fully attenuate the 62.5kHz+ PWM carrier frequency but leave audio intact.
it might have been 470 ohm and 100nF for 21.3kHz
OK... once this lands I'll make sure the radio library has a flag (as @dhalbert suggests) to stop using extended advertising with the assumption that the programmer / user knows what they're doing. As always, I'm ears wide open for suggestions, constructive criticism and ideas. :+1:
@meager fog i'm back if you wanna chat MCP2221
anything new beyond your code updates? going to work those in now and push them to my PR.
@tidal kiln nope
repeated oled drawing & MLX90640 handling is really gruesome
so if it still works with your kit, we probably have fully coverage
yep. will work in your changes and test here then push it up.
awesome work on it BTW.
Instead of HardFaulting it will now raise a ConnectionError when a disconnect happens while discovering services.
Fixes #2347
@idle owl the missing service error is the exception I used to throw when the hard fault occurred. (it happens when a disconnect happens while discovering services.) the PR with the fix will raise _bleio.ConnectionError instead because it is clearer
@tidal kiln from dark places comes nifty code
@meager fog my i2c battle arena still works. so looks good. pushing changes to PR.
wow. and no linting needed.
@tidal kiln back
ill test your PR
and we can merg
merrrrrrrrrrg
the final breakout will be ~$5 - very nice alternative to mucking with an arduino
@carter meerrrged
@jepler Thank you for this. I snagged it and am testing with Feather M4 Express and the Adafruit UDA1334A I2S DAC. Left works, with some faint clicks, perhaps when the audio is loud. Right is very noisy and the sound is attenuated. I tried it with stereo and mono. The files are MP3 64000 bps. I will go on to a different DAC. I can use whatever files you recommend.
Thanks! Things can go wrong all the time when talking to to other computers :)
What is the advice/status of using YAML files for config in circuitpython?
just to clarify -- this issue is not limited to the "status" neopixel -- For example, on a grand central_m4_express, I cannot operate a neopixel ring on Pin A1
@cedar beacon There is no YAML library. There is native JSON support on SAMD51 ("M4") and nRF52840 boards.
Thanks @tulip sleet
or you can do an import of a dictionary - see https://learn.adafruit.com/circuitpython-tv-zapper-with-circuit-playground-express
I probably have a DAC compatibility problem. Maybe some bits of L are in the MSB of R, shifting R quieter but adding a lot of seemingly random noise. The DAC might be expecting data to change on the other edge of the clock, or there is an LR clock problem in framing the bits. Or an off-by-one problem.
This adapts the "inline assembler" code from the UF2 bootloader, which in turn is said to be adapted from the arduino neopixel library.
It also ensures that the timing-critical code is also aligned with a cache line, so it should not be sensitive to changes in unrelated code like the old version was.
This requires the cache remain ON when using M0, and be turned OFF on M4 (determined by trial and error)
Testing performed on a Metro M4:
- measured timings using o'scope and found all...
@theacodes can you let me know if this works for you?
@Dar-Scott I've also been using UDA 1334 I2S DAC via Adafruit's breakout board, and I have not noticed an effect like that. That said, I2S is not as standard as it should be, and for instance on the UDA, the SF0/1 pins can select 4 incompatible "I2S-ish" standards for how the bits are aligned. "classic I2S" is what you should be getting if you didn't pull either of those pins high, however.
Among the things I am going to do Monday are finish preparing a creative commons licensed set of m...
Trying to tweak the existing code back into working was super nerve wracking and ultimately futile (I had gotten it to work on SAMD51 but that left 21 broken); the code from the bootloader "just worked" after being copied in, which I take as a good sign. (also, the use ofasm and placement in its own function seem to be key ideas that are likely to make it more robust against future changes, which is great if true)
fingers extremely crossed
Yep, works for Sol boards. :)
@tidal kiln hey dya know why i failed to bump blinka on pypi
its not just releasing a new vers?
looking...
hmmm. it just worked for MCP9600.
all i did was tag the new release
and a few minutes later 1.0.2 is live:
Successfully installed adafruit-circuitpython-mcp9600-1.0.2
@meager fog it looks ok? quick test, fresh venv, pip install blinka, it grabbed 3.2.0
how are you checking?
maybe? that looks ok too. yay caches.
or maybe it was super laggy for some reason? and i just happen to be showing up at the right time.
๐คทโโ๏ธ
so far the MCP2221 has worked with everything ive thrown at it
i think people considered it flakey cause it didnt have good code. once you send it what it expects, its pretty fast
nice. glad we decided to work up our own little driver.
yah its got some things it does better than the more $ FT232H
im thinking this could be a great chip for using jupyter notebooks as datacollection
i don't think even the C driver supports multi-byte
yeah it doesnt
thus the ???
i looked at the packets to see what it seemed to be doing
ds said 65535 in/out
there's an internal counter for bytes-sent
you can see it in status packet
good eye. i saw some of those codes that weren't in the C source, so wasn't sure what to make of them.
that easy? ok. will try that next time.
๐ค
yah, if this little thing can be put out there for $5, it's a super easy way to tether I2C sensors off USB
yah
right now people do computer->arduino->sensor which means you can't easily tweak settings
plus of course added complexity, and slow UART
what if, you skip the whole arduino step - read right into your compy for instant graphing & data collection
totes
and since im doing stemma/qwiic - its a great mix
and it's a wee little board thats not much bigger than the USB connector
chain all the sensors you want
so looks like magic
no soldering
yeah its magic - thanks to blinka
like ideal demo i think would be running kinematics
stuff that arduino doesnt do so great at
Is this going to be a new product? I'm intrigued.
maybe?
any updates on https://github.com/adafruit/circuitpython/issues/1050 ? I think this could be super useful ๐
not just for making bluetooth mice/keyboards, but for other HID devices. the MS surface dial is an HID device, for example.
None of the SF0/1 pins are pulled high. I converted my file to wav (both stereo and mono) and the left sounds very good. The right is noisy. Perhaps I broke my DAC board. Even so, it seems strange that the wav generated from the mp3 sounds better (on the left) than the mp3. I have a couple other DACs to try.
@graceful heart we are ironing out the last bugs for BLE hiD, and we need to implement bonding so you don't have to pair every time. That is in progress right now.
Iโd greatly appreciate some help with burning the bootloader to an atsamd21e18. Iโm using a blink edu, I also have a blink edu mini here too, and have burned uf2 bootloaders into samd51 chips countless times before, with mostly no hiccups. However this time Iโm trying to burn the trinket bootloader onto a bare atsamd21e18 and Iโm having some odd issues.
Once I get the chip connected and I flash it using jlinkโs utility
โโโ
Loadbin /absolute/path/to/file 0x00
โโโ
And the upload verified and works. However when I power cycle after disconnecting the debugger the board will not register over usb
The d13 led pun flashes like normal. Iโm on Mac but when I plug it into a windows machine it recognizes there is a usb device but it can not resolve what it is. I can only assume there is a bug in the bootloader firmware?
Any and all help would be appreciated. Please ping me๐
that last conclusion might be wrong as i tried flashing some old version of the bootloader and i'm getting the same result
It is failing to find the device descriptor
When connected on windows this is what is in the device events log in the device manager
Looks like the right vid/pid
FWIW - fixes my grandcentral_m4 and metro_m4_airlift -- Thanks!
For anyone interested -- homebrew now installs the latest gcc (9-2019-q4-major) for the Mac https://github.com/ARMmbed/homebrew-formulae -- seems to work OK
@hierophect seem like I am late to the party, just back from the vacation, and placed order for those 2 board stm32f411 and f401 from your aliexpress link.
@hathach would it be possible to add a CFLAG option for disabling VBUS detection for the following part of dcd_synopsys?
// Enable VBUS hardware sensing, enable pullup, enable peripheral. #ifdef USB_OTG_GCCFG_VBDEN USB_OTG_FS->GCCFG |= USB_OTG_GCCFG_VBDEN | USB_OTG_GCCFG_PWRDWN; #else USB_OTG_FS->GCCF...
200! https://github.com/adafruit/Adafruit_CircuitPython_Bundle/blob/master/circuitpython_library_list.md
Hi all, our CircuitPython community meeting is tomorrow at 11am Pacific / 2pm Eastern here in our Discord voice chat. Everyone is encouraged to attend. The notes doc with more info is available here: https://docs.google.com/document/d/1ldHCkUp7F9_pI76nMbmEpiWUzQbxCCy38CRS_zv3UBA/edit?usp=sharing <@&356864093652516868>
@marble hornet What are you expecting to happen that doesn't?
I'm expecting the board to register as a trinket in bootloader mode.
and I'm seeing nothing.
@graceful heart its being worked on - no ETA but we're getting closer ๐ its much harder than expected ๐ฎ
@main meteor for your intrigue: https://youtu.be/afOqJdf2MlU
@tidal kiln that is super cool
@ivory yew thanks. yah, hopefully it will be. credit to ladyada though for figuring out the final under the hood magic incantation.
Ladyada is a master of deep magic.
thats the only thing i can do
i cant like, tie my shoes or eat on a regular schedule
deep packet inspection โ๏ธ
A whole mood.
@slender iron any thoughts ?
The SAMD solution works "perfect" (at least with the internal RTC which is what I am using). Would you like a PR?
I've also tried the following code:
timeutils_struct_time_t tm;
struct_time_to_tm(rtc_get_time_source_time(), &tm);
mp_uint_t secs = timeutils_seconds_since_epoch(tm.tm_year, tm.tm_mon, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec);
Then files cannot be written anymore, not even `boot_out.t...
woof, getting "down" headers AND the debug header on the stm32f405 feather took way too long. but now, with stacking feather headers in a breadboard, I can get it right side up and with debugging.
(and involved sanding a few thou off the down pin headers, possibly because the debug header was not exactly where it needed to be .. or maybe they really aren't meant to fit at the same time)
@marble hornet not many. a restart on mac may help if it shows on windows. a usb sniffer can be helpful when debugging a new board
Okay, I will look into getting one. In the mean time: it is just the chip on a qfn breakout not a new board Per se. And supporting electronics in a Breadboard
is the usb running through a breadboard?
@graceful heart you should be able to do your rotary BLE HID with the latest CP master and the latest library
start with this example: https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/master/examples/ble_hid_periph.py
thank you! @slender iron I'll give that look!
FYI CircuitPython works as a BLE peripheral with the latest CircuitPython master and the BLE library master. Here is the demo code: https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/master/examples/ble_hid_periph.py
I'll leave this open because I intend on supporting other BLE HID devices from CircuitPython as well.
@prime flower forum post for ya when you have time: https://forums.adafruit.com/viewtopic.php?f=60&t=159594
@slender iron yes the usb is going through bread board
i'll try soldering it
@slender iron Will take a look at it during my AM support, thanks!
@onyx hinge I've been using the stacking headers to elevate mine:
oh that would have worked better, since the plastic is on the top side that way
You also mean the F405 feather, right? Or do we have a new prototype coming along ๐
Lol I think the only difference is the 7 has ethernet or something
incidentally this shows how far I got with "learning" the stm32 last week
that we aren't even going to do for a whiel
yep just ethernet
what are you using to debug?
@onyx hinge st-util or openocd?
@ionic elk I have a j-link. using JLinkGDBServerCL as gdbserver on linux
dfu-util -a 0 --dfuse-address 0x08000000 -D build-feather_stm32f405_express/firmware.uf2 oh gee why doesn't the device work after this. sigh.
did somebody do the uf2 bootloader?
For the most part so far I've done everything with an ST Link and st-util/openocd
does that upload firmware any faster than dfu-util?
I haven't worked on it
It uploads it... very fast? I'm not sure. It takes like 2s
is dfu util faster?
no, it's over 1 minute
https://github.com/mmoskal/uf2-stm32f oh hey this has files for the feather
something called feather_f405 anyway
I think it needs .ld file magic in CP that is beyond me though
the uf2 bootloader locates at 0x08000000, so circuitpython has to move up by 32kB
doesn't stm32duino have one too?
How big is the bootloader? that could be very problematic for our internal flash filesystem
I'll do some research
Ideally we want it out in one of the 128kb sectors at the end of the flash
yeah it looks like it occupies all those 16kB sectors at the start
yeah that's no bueno. Means no internal flash, like at all
the other thing I was trying to figure out is, can I enter the DFU bootloader from software? I didn't find an answer yet. (I recall this was possible on the first USB DFU device I played with, some Atmel AVR)
Though I guess that's less of an issue for feathers, to be fair. Basically only affects discovery boards and maybe you just don't care for those anyway since they have a built in st-link. Biggest issue would be off brand boards without flash or a programmer built in
It'd be nice if we could just shift it out to one of the big sectors but we'd need some serious magic to get that to load up properly
this is totally a detour for me
anyway, I can upload firmware via gdb now and it is faster than dfu
Transfer rate: 44730 KB/sec, 14313 bytes/write.
I am not totally sure about a boot into DFU... it requires the boot pins, maybe there's some kind of thing that'd let you persist that past reset but I kinda doubt it
how fast is it for you? For the cp build? just for my reference
how long does "make" take from "clean"?
user 0m21.882s
https://community.st.com/s/question/0D50X00009Xkh7wSAB/jumping-to-the-bootloader-via-software-does-not-permit-dfu-mode some people have these notes about entering DFU via software reset without boot0 but it's going a bit over my head
OK OK back to nRF audio playback rate, which is where I intended to start the day ๐
@hathach no problem I figured you'd have an opinion on the best way to get it done. I figure that the best way to handle it would probably be a segment in the port level supervisor/usb.c with a mpconfigboard flag to activate it. Though I agree that this is one of the few boards that I've ever seen let PA09 be disconnected like that. Let me know when you've gotten a change to play with the new boards and I'm happy to proceed on whatever you think is the best case scenario for this.
@tannew...
@onyx hinge sorry I meant how long does it take you to flash your finished binary for the Cpy build - mine takes about 5s to flash. If it takes a lot longer than that and starts getting on your nerves, you could try the ST link as another option.
Yeah that sounds fine I wouldn't worry about it then
groan, whole-computer lock-up while running gdb on a nRF
I had hoped those would be gone with my upgrade earlier this year but no such luck
@slender iron The only way around the new error you introduced is to import _bleio and then except _bleio.BluetoothError as far as I can tell. It's better than the hardfault handler, but I really feel like I shouldn't be importing _bleio. You didn't base it on anything so I can't except something general to catch it.
For context, I'm consistently getting that error if I soft-reload/reset the receiver while the controller and the receiver are connected and packets are being sent from the controller to the receiver.
The "spacing" of "buffer structure" is confusing, use the "channel count" instead.
Testing performed on nrf52840 feather:
Play stereo and mono, 8- and 16-bit, 8kHz RawSamples representing 333.33Hz square waves.
Use both mono and stereo PWMAudioOut instances.
Scope the RC-filtered signal and use the scope's frequency measurement function, verify the frequency is 333 or 334Hz in all tested cases.
In the "stereo output" cases, verify both the L and R channels. Verify the output a...
@idle owl we can make the ble library provide them as well. using general errors is less good because it catches more than you want and is less clear. Is your code that is doing the sending checking to see if the connection is still connected?
@tidal kiln fyi https://www.silabs.com/products/interface/usb-bridges/classic-usb-bridges/device.cp2112 i didnt catch this one
The CP2112 HID USB to SMBus/I2C Bridge provides a complete plug and play interface solution that includes royalty-free drivers. This USB 2.0 compliant device includes 8 digital I/O pins and is availble in a 4x4 mm ย QFN24 package.
Download USB to UART Bridge VCP Drivers >
@slender iron I'm not sure what sending checking code looks like. There is a lot of checking going on in this code.
can you link me to it?
Having the BLE library provide it is at least one step better than requiring an import of _bleio.
Yeah hold on.
ble is tricky because the connection can be lost at any time
I assume it's something in the controller code. That's what's crashing.
is the controller.
@tidal kiln its fairly cheap, about same price as MCP2221 - clearly they're meant to compete ๐
oh nvmd "Not Recommended for New Design"
its about to be killed. we can skip
๐ฆ is there a suggested replacement?
@idle owl the uart_connection.connected is what I was thinking
@slender iron So what you were asking about is in there then?
yes
Ok
but I wonder if it should be checked in send_packet too
all of the sleeps could build up to cause the .connected to be far away from the use
the tiny sleeps are debouncing for button packets, and there were no button presses when I got it to crash to this error. The final time.sleep is required to avoid a bad checksum error from sending too fast.
how would I add it to send_packet?
@tidal kiln nope - that chip is EOL
if uart_connection.connected at the beginning?
I thought that's what it does right now. Dan wrote that for me, I only technically understand it.
as it is it is reactive by catching exceptions
you could also be proactive and check that the connection is still valid
I'm not following what you want me to do. I checked to see if not uart_connection.connected and it's never getting to that bit in send_packet when it fails this way.
all I did was print
but it did not print
Traceback has send_packet in it. So I guess it's trying? I must be checking in the wrong place.
Checking the connection first always leaves the chance of the connection dropping by the time you interact with it.
I don't understand how to write the code. I understand the concept, I think.
It seems to me when interacting with a library where almost any method could throw a connection error at any time you need to be reactive and use try catch.
I have one, but the issue is that Scott introduced a new error that is in _bleio and would require importing that to catch it. It's _ so I'm hesitant to be importing it.
Should probably alias it in the Python ble library
@ivory yew I've been thinking about the best way to handle ble disconnects. It'd be nice if there were only a few spots to catch the exception and check connected
does anyone know where micropython stores pin information for pyb.SCREEN()? I'm trying to figure out what the Meowbit screen is from their micropython port but I can't seem to find anything about the screen on the board level.
Scratch that I found it.
yep blegh thanks for looking though
man micropython does not really give a dang about keeping its definitions in one place huh
kinda dreading that that'll keep showing up...
tbh micropython doesn't really give a dang about much anything that is not pyboard
lol
Well, if anyone happens to have a reverse engineered schematic of the Meowbit it'd save me some dredging
and you can't really blame them, it's what puts bread on their table
yeah true
I think you can steal the pin mapping from the makecode arcade bootloader configuration
Does that have peripheral info? The MCU map I've got, its the peripheral maps I need.
Where would I find that?
nvm you're right, it's all in here https://github.com/KittenBot/uf2-meowbit/blob/fat/boards/meowbit/board.h
bootloader for meowbit based on https://github.com/mmoskal/uf2-stm32f - KittenBot/uf2-meowbit
News from the future ... "There was an issue with your delivery"
That's how AppleTV works...
@tidal kiln ahhh hidapi isnt a trivial pip install - wanna keep hacking on it?
sudo apt-get install libusb-1.0-0-dev
"CircuitPython snakes its way to Scott's TV"
lurking
Lurking
Also lurking.
@meager fog to remove the requirement for hidapi? and just use libusb? write our own hid read/write?
lurking today
lurking
lurking today
@tidal kiln i mean you need to apt-get install libusb so that hidapi can build
lurking
@tidal kiln thats' done in the travis setup
BTW, huge hugs to everyone who did Blinka! I am now controlling a Sphero RVR with a Raspberry Pi because of it!!!
hmm. ok. let me look...
rebooting
That's great to hear @drowsy geyser
lurking
200 CircuitPython Libraries!
https://github.com/adafruit/Adafruit_CircuitPython_Bundle/blob/master/circuitpython_library_list.md
https://circuitpython.org/libraries
The Binho Nova is a Multi-Protocol USB host adapter with support for I2C, SPI, UART, 1-WIRE, SWI protocols all in one slim, robust package, and now it supports CircuitPython BLINKA!
https://support.binho.io/learn-and-grow/binho-+-circuitpython
CircuitPython slithers to the pages of MAKE Magazine!
Make: Vol. 71 FIX OUR PLANET featuring CircuitPython! On page 82 is a CircuitPython powered edge-lit LED heart by Geek Mom Projects. AND! In TOOLBOX, the CircuitPython ruler from Digi-Key and Adafruit!
https://makezine.com/
@meager fog ah, gotcha, for travis, yah, ok need to this:
https://learn.adafruit.com/circuitpython-on-any-computer-with-ft232h/linux#install-libusb-5-2
ADABOX 14 in the wild
Approx 4,000+ CircuitPython devices in the wild ๐
I do have a hug report only today, lurking for the rest.
Adafruit joins the LoRa Alliance
https://learn.adafruit.com/using-lorawan-and-the-things-network-with-circuitpython
https://blog.adafruit.com/2019/12/05/adafruit-joins-the-lora-alliance-loraalliance-lora-lorawan-adafruit/
@tidal kiln try it!
Engineered Sandwich is a small rechargeable freestanding light-emitting sculpture. A translucent 3D-printed lens press fits between two hand-finished wood buns. A circuit python controller randomly changes RGB LEDs, continuously projecting a cool gradient on all sides of the lens and through a series of slots at the top of the piece.
http://www.extrasleepy.com/#/engineered-sandwich/
https://www.instagram.com/p/B5yclN6h7pD/?igshid=1tuxoudkzvu2t
On Wednesday, Dec 11th at 8pm EST, Particle's Senior Manager of Developer Relations, Brandon Satrom will be on ASK AN ENGINEER!
https://twitter.com/BrandonSatrom
https://www.adafruit.com/ask
18th is ADABOX unboxing
Show and Tell and AAE on 25th, and Jan 1st!
Making & breaking things for @particle | Founder of @CarrotPantsPub | ๐ฐ๐ท๐ฅ|writer, speaker, maker & optimistic nay-sayer | ๐น http://twitch.tv/brandonsatrom
18850
4014
Adafruit Industries, Unique & fun DIY electronics and kits : Adafruit's Ask an Engineer - Tools Gift Certificates Arduino Cables Sensors LEDs Books Breakout Boards Power EL Wire/Tape/Panel Components & Parts LCDs & Displays Wearables Prototyping Raspberry Pi Wireless Young En...
DRAFT IS HERE!
https://github.com/adafruit/circuitpython-weekly-newsletter/blob/gh-pages/_drafts/2019-12-10-draft.md
Yes, thanks for anyone who gives us Newsletter info
Just lurking today
Just lurking for hug reports
Not sure if you caught it earlier, but hugs to everyone who worked on Blinka! I'm able to control my Sphero RVR with a Raspberry Pi because of it.
@drowsy geyser Added to the notes! Are you text only or do you want to read it off yourself?
Text only today. Sorry!
No worries, simply wanted to know ๐
key-cad vs. k-eye-cad......
๐
kai-cad ?
(I just copied that code from somewhere else ๐ ๐ )
"the other Fritzing"
๐ for blinka section
<late and lurking>
haaa haaa haaaa haaaa
Amazing alliteration!
Very alliterative
@pastel panther I see what you did there ๐
๐
is this a new attendance record?
@tidal kiln Not quite, I think
pretty close
"I caused the problem and then fixed it by copying someone else's code" kind of sums up software engineering.
I think the record happened in February because I kind of remember it.
@onyx hinge Once you use stencils, you'll never go back. They're soooooooo much a better use of your time
and pony up for stainless because kapton is kinda meh
yeah I went cheap this time. so if I hate it I'll buy metal and not just give up..
I have to duck out for a 2:00 meeting. Have a great week, all!
I think my metal stencil from PCBWay was like $10.
๐ @old smelt
@ivory yew how big? Most breakout sized things are around $10 from OSH Stencils
(make sure the neopixel fix is in it?)
Not sure but you can see it in the background of this picture.
@solar whale Could use the interupts for MCP23017
terminal pixels
This is much bigger than most breakout/devboards.
@inland tusk not sure how that would work, but will look at it
It does not talk directly to the RPi GPiO pins. Not sure how to trigger
@solar whale The chip has two interrupt pins which can be bound as one. Take a look at the datasheet.
OK -- will do
Thanks
Thanks!
@ruby atlas probably some good ideas to steal from PixelBlaze and or possibly FadeCandy:
https://www.bhencke.com/pixelblazegettingstarted
https://learn.adafruit.com/led-art-with-fadecandy/intro
ah yeah I bet fadecandy was what I was trying to think of
the visualizations @ruby atlas mentioned reminded me of pixelblaze
think we need a PyxelBlaze
or a BlinkaBlinker
or somesuch
yeah they're not particularly fancy - yet.
Dropping off. Need to prep some things for dinner later. Cheers!
@minor plume let me know if/when you want some pointers for writing a library for the MAC3010X
@tidal kiln I raise you a magnetometer scatter plot ๐
Need to do some hackin' to make it plot in real-time though, 3D space is fun to scatter plot
this'll be interesting for ML down the road
nice. ill be curious to see how you do live plotting.
oh yah, was it just a solder bridge?
@hierophect thanks for testing! I don't think we do the proper thing when plugging in a second time. Looks like we should. :-) Is vbus monitoring available on a different pin?
@hathach A define is best for us because we don't use TinyUSB's board_init. Could we add it soon to unblock us rather than waiting until you have the exact hardware? Turning it off should be testable on existing hardware already.
@hierophect thanks for testing! I don't think we do the proper thing when plugging in a second time. Looks like we should. :-) Is vbus monitoring available on a different pin?
@hathach A define is best for us because we don't use TinyUSB's
board_init. Could we add it soon to unblock us rather than waiting until you have the exact hardware? Turning it off should be testable on existing hardware already.
I think VBUS is completely exclusive to PA09 on all MCUs we currently support...
@hierophect It looked like one could programmatically monitor power on a different pin and then set the USB peripheral's state accordingly. I think most of our boards do have a battery monitoring pin we could use to do it ourselves.
I think a warning around the define is enough. It was going to be a support issue it would already be due to the SAMD behavior. Now we know for future board designs and versions of the software.
How does this work on a 48mhz core and a 120mhz core with the same delay values? What would happen if we changed the SAMD51 clock up to 180mhz?
- Add
board.POWER_SWITCHpin to CPB, akaD35.POWER_SWITCHcontrols the power to onboard peripherals and NeoPixels. If high, it turns them off. - Set pin to output low on each soft reload. This disables power saving until it's re-enabled. This prevents confusion ("why aren't my NeoPixels working?") at the cost of a brief power-glitch on reload.
@tannewt when tinyusb drop VBUSEN configure entirely, circuitpython can put those into port_init() for board that have vbus en (and not for one like blackpill). I will do some datasheet reading and make the necessary changes first, then doing hand-on testing/correction with the actual hardware later.
Hey @Makabongwe-Nkabinde , did you ever get this figured out? I'm having the same problem. Triple checked my wiring...
@jonathanmccormick please provide more details about your issue. What boards are you using. What code? Are you using the latest libraries. Are you using a raspberry pi or if not, what MCU and what version of CIrcuitPython. I have been running these libraries successfully.
I started looking into that, it's actually the next callback function: https://github.com/adafruit/circuitpython/blob/7f744a2369a5036cadfa05575da1704f709c98bb/shared-module/usb_hid/Device.c#L85-L97
However, from my testing it shows that report_type is always 0 when this callback is called, which means HID_REPORT_TYPE_INVALID. Looks like it's being called here: https://github.com/hathach/tinyusb/blob/e413c9efa303d70de019a91aa415384fe80ca78f/src/class/hid/hid_device.c#L309-L324
...
This is work in progress. Currently the report_type is always HID_REPORT_TYPE_INVALID for some reason, while it should be HID_REPORT_TYPE_OUTPUT. Possibly a bug or missing feature in the tinyusb library.
@meager fog @tidal kiln I scrolled back and saw you mention "not recommended for new design" but was that for the CP2112? I could not find that, it even has a fresh Catalina driver. However, the MCP2221 is EOL and has a replacement with one diff: faster UART. See https://www.microchip.com/wwwproducts/ProductCompare/MCP2221/MCP2221A
@jonathanmccormick the issue was with the chip itself, I bought a new one and that solved the issue. The other issue could could be the interrupt request pin, make sure that is configured correctly.
@tulip sleet @idle owl @solar whale Over the past week and a bit I've been working on the Bluefruit equipment and thanks to all of you this has been a very positive experience. My most recent work with Bluefruit has been to extend the learn project written by @split ocean . I have written additional code for use with the Feather nRF52840 and to use it as a client so that it advertises a color, similar to that CPB. My final step with that was to make the on board NeoPixel to display the color that is be advertised. I was able to get this to work but not by using the learn guide "Introducing the Adafruit nRF52840 Feather". I found that on the Pinout page it states to use PIN_NEOPIXEL to access the rgb NeoPixel but this didn't work. I used other coding that did do the job and works well. I'm sharing the code to all and maybe the learn guide can be updated. Also if JP wants to add the nRF52840 to his learn guide for Hide and Seek since the Feather nRF52840 can also be used as a hidden item. (I'm going to read and work through the guides that have been written so I can use GitHub better and in the future, thanks)
@sterile bronze PIN_NEOPIXEL may be Arduino. It should be board.NEOPIXEL for all CircuitPython board with a built in NeoPixel.
Congrats on figuring it out!
@tulip sleet would you have a moment later? I took a stab at that USB HID LED support, but I suspect tinyusb doesn't support it fully
unfortunately the tinyusb source code is just a string of three-letter acronyms to me
@sterile bronze Glad it is working for you and thanks for the example. I agree that the guide is a bit confusing regarding the pin names -- As @idle owl pointed out, those are used for Arduino. Just FYI, you can check the pin names at the REPL by doing import board dir(board) that will list all the pins. also you can look at the boards pins.c file -- for the feather_nRF52840_express https://github.com/adafruit/circuitpython/blob/master/ports/nrf/boards/feather_nrf52840_express/pins.c
@solar whale thanks for the link to the GitHub files that is a great help. I keep learning more proving that an old dog can learn new tricks.
Glad to help a fellow "old dog"
@timber mango the A variant of MCP2221 is what is being used, just being lazy when talking about it. not sure about the CP2112 EOL thing though.
@tidal kiln Ah yes, thanks.
@tulip sleet Please let me know when you're around, I added the rest of the error handling to my code, and commented it, and I would appreciate another look at it.
@idle owl I am back; going to dentist at 1:30
@tulip sleet Sent the files. Controller is what has the added error handling around send_packet because it's failing to the new _bleio error.
Really looking forward to the wrapper lib you want to write, because the error handling in this code is beyond ridiculous.
You can put the try with a catch-all except in send_packet() instead of in the main program. So change except (OSError, KeyError): to except: and add the pylint comment
oh.
I thought I tried that. Probably didn't.
I'll test it now.
That works! Much better, thank you.
@timber mango yes we are using A rev of silicon
(Partial) fix for issue #2335 (nrf port).
Test:
import os
import time
def current_time(lt = time.localtime()):
return "{:2d}-{:02d}-{:02d} {:2d}:{:02d}:{:02d}".format(lt.tm_year, lt.tm_mon, lt.tm_mday, lt.tm_hour, lt.tm_min, lt.tm_sec)
print("now: ", current_time())
file = '/test.txt'
try:
os.remove(file)
except:
pass
with open(file, 'w') as f:
f.write("hi from MCU")
print("mtime:", current_time(time.localtime(os.stat(file)[7])))
...
@stuck elbow I'll take a look but may not have time for a few days. Does the example help any? https://github.com/hathach/tinyusb/blob/master/examples/device/hid_composite/src/main.c. I know it doesn't do anything but the setup might help. The INVALID report type is pretty suspicious.
This looks good! Just use include files to get the external functions.
#include shared-bindings/rtc/RTC.h and shared-bindings/time__init__.h to get these definitions.
@tulip sleet I will be away for the rest of the week anyways, and there is no hurry
sure, it's in the PR's so I'll review the open ones from time to time.
that example doesn't actually look at the report type, I suspect nobody ever tested it
there are some TODOs in the tinyusb code around that area too
@tidal kiln Sorry to bug you, but if you have time to reply to the LED animations review, I'd appreciate it. I managed to back myself into a corner with needing it for a guide. I wasn't thinking it would grow like it did, or that it would take a while to get reviewed (that's on me). Thank you for reviewing it!
@idle owl done
Thanks!
@jepler I looked at the Feather M4 Express output on a logic analyzer and it looks good to me. (No DAC connected.) It clocks at 1.04 MHz for this file. I have some new DAC boards on the way in case I broke mine.


lots of good python on hardware in this one, thanks everyone who sent in links / issues / PRs and more! https://www.adafruitdaily.com/2019/12/10/200-circuitpython-libraries-binho-ble-and-more-python-adafruit-circuitpython-pythonhardware-circuitpython-micropython-thepsf-adafruit/
Ok, @hathach. Let us know what we need to do on our side.
@hierophect want to get this in with requiring the external connection for now? Any changes you need to do that?
@stuck elbow it does look like HID set report isn't fully implemented
since INVALID is always reported. Does the data change at all?
it doesn't support multiple interfaces, but that's probably not required
it does
I compiled that code and used it in my keyboard and it works
the report is always 1 byte long
that sounds right. it's length is defined in the hid descriptor
and if there is only one report, then the report id is omitted
@slender iron @tulip sleet Are we still able to do beta.1 today?
@slender iron are you saying it thinks the report is invalid because there is no id?
@stuck elbow I don't think it knows its invalid. I think it should be OUT
not sure how feature reports are handled though
so a typo?
ok, I will look and see if I can figure out where this is called from
@idle owl it'd be nice to see if #2363 could be merged in first but I'm not sure if @onyx hinge is around today
Agreed. Fair enough.
@stuck elbow ya, I think its a typo. but I'm not sure how feature reports are handled (or what they are)
hehe, I have no idea how USB works, it's going to be fun
the usb complete book is a pretty good primer
thanks for the pointers, this is really helpful, by the way
HID is definitely more complicated than other classes
the xfer_cb is called through a function pointer
iirc
yeah, in the CFG_TUD_HID
(my brain is fresh on hid from doing it for ble)
I wonder if I should just make a pull request to tinyusb changing that to OUTPUT and see what the other devs say :P
thach would probably be fine with that
downloads the spec to see how feature reports work
the golden labrador school of development
uh, sorry, I didn't mean to make you do it
@slender iron to answer your question on #2363: I don't know how the same delay numbers work on M0 and M4, but the boards I tested work. The code is not code I can say I understand, it's code I lifted from the uf2 loader.
I think the hand-wave explanation is, with caches disabled on the m4 parts, they perform slower
a 180MHz board, I'm not sure if the delay values would need to be tweaked or not. But would that be different than with the previous code?
@stuck elbow glancing at the spec doesn't explain how feature reports are transferred
@onyx hinge ya, the old code would suffer from it too. it would be nice for the new code to work better too. I think we can merge as-is and follow up later
I investigated some implementations of neopixel that change systick during neopixel driving, but I don't think that's a good fit for circuitpython. those said they worked in the presence of "overclocking"..
I think it can be macro-ized to allow a compile time different delay on the hypothetical 180MHz boards
well limor was hoping to allow dynamic overclocking I think
we can cross that bridge when we get there
or rewritten to use dma'd pwm which is what nRF does
yup
that would be good for getting neopixel off of the cpu
@onyx hinge anything else close to done that you want to get in?
We chatted on Discord and assume that the delays work on both due to the disabled cache on the SAMD51.
@slender iron nothing that is currently a filed PR. I have a simple fix for nRF playback rate bug but didn't actually PR it yet. So it depends how motiviated/time constrained you are by other things. Totally get if you want to go ahead asap
@slender iron we could dispatch to one of two copies of the code (nominal speed and overclocked speed), or clock down during neopixel writes too
Thank you ! @slender iron
#2342 is waiting for you too
oof thanks
yeah I started to look at that and tried to factor MOAR and it spiraled out of control
also I think it might have broken the spresense port but I didn't have a board to check on at the time. now I do.
I started doing a more extensive re-factor but it kinda got out of control. I feel like background and tick could both have a lot more commonality than they have, especially on systems which directly use ARM SysTick. I'd be content closing this unmerged now and returning to it in 6.0 -- nobody's assigned this a 5-ish milestone. Thoughts? @tannewt @dhalbert
I don't think this is the right API because output reports can theoretically be used for other things besides LEDs. A better api would be a circular buffer of reports that can be read through a receive_report function.
I'm impartial. Either way is fine with me.
@onyx hinge how close is mp3?
we probably have one more release we'll do before the end of the year
I agree a more general API would be more useful, but I think it will require a considerable amount of planning. How large should the buffer be? How many entries of what size? Do we pre-allocate it always? Do we let the user choose the size that fits best their use case? How can the user make an informed decision about it?
I think that the particular combination of HID_USAGE_DESKTOP_KEYBOARD and HID_USAGE_PAGE_DESKTOP is only used for keyboard lamps, though, so we could leave it as ...
We want to redo timekeeping anyway to be able to sleep, so ok by me to wait.
@slender iron now that "protocols" is merged, mp3 needs to be rebased
so let's not try to do it today
I think mp3 is pretty solid but it makes people see bugs that exist in audio more generically
okay
I'd rather not add a special API because I'm going to be doing the BLE HID library soon and it'll expose this same API.
We can limit the buffer a bunch for now though. How about an 8 byte buffer that only queues 1 byte reports and return 1 byte bytestrings? When we have other reports to support we'll just make the implementation smarter.
I like that. I could even live with just one one-byte report, because I only care about the most recent one. This would make the internals easy enough even for me to implement, and would have an API that could be expanded later when needed. Thanks!
@tannewt @ladyada cool cool. Did we get a chance to double check the board?
my order hasnt come in yet :(
@onyx hinge @slender iron am I correct in interpreting that you are considering dynamic Neopixel timing? I was working on that module last week using the DWT, which should be shared between the samd and stm32 ports, but I put it off because it was having annoying variance. I can revisit it as a new PR if you two want to brainstorm a bit.
@ionic elk later but not now
k
All good we can probably just revisit. I tested it pretty thoroughly I don't think we should see any issues.
Here's the selection of mp3 files I've been testing with, some piano music from wikipedia:
We can always fix it later. :-)
yay, objective achieved: I can now add mp3file without touching anything in audiocore!
@slender iron Why does the code check to see if any existing connections are providing a UARTService before the while True:? It is only outside the loop until it enters the loop, and it hasn't scanned or connected outside the loop. I'm confused by the inclusion of this code before the loop. ```python
See if any existing connections are providing UARTService.
if ble.connected:
for connection in ble.connections:
if UARTService in connection:
uart_connection = connection
break```
How would it have any existing connections?
hmm. ok
Thank you.
@tannewt sure thing I kept all the USB editing stuff to the last commit, I'll just roll it back.
@ionic elk DWT sounds like an interesting way to do sensitive timing. did you start to have positive results?
@onyx hinge nah lol
but it "should" work
eventually
The primary issue seemed to be that the instructions to turn the GPIOs on and off were taking a long time, but compensating by subtracting an equivalent amount of time from the delay loops wasn't working as it should have.
I was extra confused because the Arduino neopixel library uses ideal timings, but I don't know how that could possibly work when just turning the pin on and off takes .3us which is a neopixel low bit by itself.
Also, my latest merge is attempting to inject lines from mpconfigboard into py/proto.c???
<<<<<<< HEAD:ports/stm32f4/boards/stm32f411ce_blackpill/mpconfigboard.h
#define FLASH_SIZE (0x80000)
//etc etc
=======
const void *mp_proto_get_or_throw(uint16_t name, mp_const_obj_t obj) {
//etc etc
>>>>>>> master:py/proto.c
@onyx hinge you wrote this new proto.c file, right? Any ideas? I didn't even know a merge could do that.
what the !?
yes I wrote that file, but I have no idea what git thinks it's trying to do
Jupyter Notebooks + CircuitPython for Computers
Wait, that's a fun GIF. Here we go...
@tidal kiln Seems like JupyterLab has some issues to be worked out in regards to displaying animated/interactive plots without first converting the graph to HTML first. Which loses the interactivity and the real-time-ness of it.
or I'm just bad at JupyterLab and Matplotlib ๐คทโโ๏ธ
Oh man I'm in a git hole now D:
Welp nevermind github knew what to do just fine. it was just my local git that was freaking out
@ionic elk oh phew, you recovered all your work?
@onyx hinge yeah I think the issue was that there were commits in master via my PYB nano branch that actually deleted old versions of the new PR's files. So my git wanted to delete them but couldn't and was flipping out. But Github's commit system had no problems with it at all? Who knows.
Background tasks and ticks are close-but-not-quite copypasted between ports. For instance, during for background tasks, what a port needs to do is mostly controlled by the modules that are enabled, not by the port itself. For ticks, everything but spresense uses ARM SysTick. Unify them to the extent that is possible, while allowing the necessary customization points for current and reasonably-anticipated future ports. See #2342 for one PR that got stuck due to the non-factored nature of t...
@prime flower i hacked up something that sort of worked, but i didn't use that animate feature. i'll DM it to you.
OK mp3 rebased and re-tested (on nRF pwm out). It LGTM
@indigo wedge got my serpente (USB-C) board today -- works great!
Hurray :)
well that's weird
#0 reset_into_safe_mode (reason=reason@entry=NORDIC_SOFT_DEVICE_ASSERT)
at ../../supervisor/shared/safe_mode.c:85
#1 0x00056fb4 in softdevice_assert_handler (id=<optimized out>,
pc=<optimized out>, info=<optimized out>) at common-hal/_bleio/Adapter.c:58
#2 0x00024a44 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(this is working on the "write file via usb" crash)
at ../../supervisor/shared/safe_mode.c:86
86 if (current_safe_mode > BROWNOUT && reason > BROWNOUT) {
(gdb) where
#0 reset_into_safe_mode (reason=HARD_CRASH)
at ../../supervisor/shared/safe_mode.c:86
#1 0x00054dd6 in HardFault_Handler () at supervisor/port.c:168
#2 <signal handler called>
#3 0x000276ee in gc_free (ptr=<optimized out>) at ../../py/gc.c:673
#4 0x08029000 in ?? ()
``` multiple personalities
@onyx hinge want to sneak mp3 into the release? I haven't started it yet
@slender iron sort of! I feel a bit icky about that change to fat that ended up being needed for nRF!
the one I commented on
looks
it turns out that nRF needs the (read) buffer to be word aligned but we don't provide that in the general case. mp3 triggers it frequently.
but you can trigger it just by doing an unusual read
I am positive this is one of those things you will feel I tackled at a wrong layer
that doesn't surprise me. tinyusb does copying for that reason
fat USUALLY does it via a copy too, but when you have at least 1024 bytes of contiguous read it doesn't.
other than that one thing, it has little scope to interfere with anything so I'd feel comfortable tossing it in even if it turns out to need some rework. and we know we have people who are excited about mp3 reaching master, let alone a release. but excitement isn't a reason to hurry
switching gears to work on a 3d model for a friend but I'll keep an eye on discord notifications
its not clear to me what its doing
.. or will in a minute
initially, rbuf just points at buf
it's advanced as the read is partially done
there's a fast-case for when a read is at least a full sector /* Read maximum contiguous sectors directly */
at what point does it need to be aligned? in fatfs?
in this case, it reads directly to "rbuff", but there's no alignment guarantee for it
so my change just stops "unaligned rbuff" from hitting this fast path
mem_cpy can't handle misaligned copies?
ah
full traceback at https://github.com/adafruit/circuitpython/issues/2332
the alignment check makes it skip down to where it does a disk_read into fp->buf instead, and then that is copied into rbuff with mem_cpy
fp->buf has an alignment guarantee
would the better fix be to make spi_flash_read_data handle misaligned buffers?
I liked this approach in part because it avoided any new allocations
there's already an aligned buffer available to us
it costs a copy though
now, there could be other users of spi_flash_read_data who will be sad
wouldn't fixing spi_flash_read_data also do a copy?
read_data would only need to read a word to align the buffer and then do its normal thing
I was thinking you'd do an extra small aligned read
ah okay, to just a uint32_t on stack or something
OK, I'll add notes to 2332 then
k, thanks!
As we chatted about. We'll leave #2332 open with ideas for a proper fix.
Yay! Super excited for this.
(I'll reopen it too)
๐
@slender iron what if the read is the last 3 bytes of flash?
will the chip return junk in the 4th byte and all is okay?
you can still read the last three into a buffer of 4 bytes
also tagging @hathach FYI since this could happen in arduino :)
oh you think it can read "just three" ?
(based on discord discussion) For now we are going to take the band-aid fix but @tannewt wants to avoid the copy that this introduces by handling it in nrfx_qspi_read (or maybe spi_flash_read_data) for nRF: when the input buffer is unaligned, do a (1, 2, or 3-byte) read to a 4-byte, aligned region on the stack, and copy enough bytes from there to re-align the data pointer. Then do the bulk of the read as now, avoiding any extra copies.
@onyx hinge ok ready for your next project!?!?
@meager fog I think so! Want me to look at stm32 audio or do you have a different direction?
(are you excited for mp3 in beta1? I am!)
i ammm!
your next project is to make a zune
well, zune like ๐
MP3 player for pygamer
... yes.
okay, I think I see what you're asking for. That'll get me into some stuff I don't know yet which is always awesome
ff/rew by time .. oof, that'll need some stuff we don't have yet:)
okok
so the "deliverable" is some python code, probably some graphics, and whatever core changes turn out to be needed?
but basically - demo the mp3 playback with a simple UI
ya
you will fnd out very fast if you need to fix anything
yup no doubt
especially with buttons/screen/mp3 all at once
but also, great demo ๐
i dont think you'll be able to play mp3 from SD
we know there are problems updating the screen while playing audio, I worry they are not going to be simple
but, try it
actually I did that successfully, maybe you missed hearing it
oh ok well gr8, use Sd
that was on pyportal, not sure if it makes a difference
yeah this isnt going to be huge amt of UI
pyrocker? pytunez?
Automated website update for release 5.0.0-beta.1 by Blinka.
New boards:
- shirtty
- pyb_nano_v2
New languages:
- ko
lol
is the logo a snake in a coccoon?
.. who later emerges, a beautiful buttersnake
ok can I unsee that idea now?
Buttersnake? Hahaha. I can't breathe.
๐ง 
@slender iron the very first sentence of the release notes said "This is release 5.0.0 beta.0." I fixed that on github
haha, oops. ๐ thanks!
np, thanks for doing the release!
waiting for the release files to do the posts and website merge
why is it a draft now?
I thought it was a draft, sorry; make it a release.
I publish because then github adds the tag and triggers the build
i hope it doesn't trigger twice
looks like I was able to cancel it
ah, our file count is higher because we added korean
and two boards
@slender iron Thank you!
np @idle owl. good to keep the release train rolling
There are a number of tricky cases that exist when there is the possibility to enter background
tasks early in initialization. I discovered and fixed several of them, which were due to trying operations on the GC heap while it was not initialized. This closes #2338 according to my testing. An assertion which clarifies problematic calls to m_free was added, but is not strictly necessary.
@slender iron working on migrating adabot to actions. wrt the bundle update script, i've kind of hit a roadblock on adabot's email. repo secrets aren't available in Python as env vars, and non-public emails aren't available through the API (rightfully).
the only real way i can see to do it, and keep the email secret, is to encrypt it into a file in the repo, and then decrypt on-the-fly.
thoughts?
@raven canopy you should be able to provide secrets. you have to be explicit in the yaml to tell it to provide the secret to the step
@peak thicket the image demo is done in arduino and not circuitpython I believe
scrolls up. sees the with: ๐คฆ
np ๐
thanks!
is there anything like a helper lib for playing tones? like what's in the CPX lib, but more stand alone
omg. i had previously used env: to pass in a secret in the library workflow. double ๐คฆ... this is what happens when you stop working on something in the middle of it.
@tidal kiln there's this, but its def not as complete as the CPX lib. https://github.com/adafruit/Adafruit_CircuitPython_SimpleIO/blob/master/examples/simpleio_tone_demo.py
@raven canopy thanks. that looks like it would work OK actually.
or i can at least borrow heavily from it. and might need to adapt for CPB.
I revamped the internal flash layout, and I am still seeing some problems. CIRCUITPY will appear but then the board will crash. This does not sounds like your symptoms.
I do NOT see a problem if I compile with DEBUG=1, so it may be some kind of timing problem. Sometimes when I switch back to a non-debug build it will work for one or two times and then fail. There is no difference in the flash layout between the debug and non-debug builds, except that the firmware is bigger because it's n...
Neither the README.md nor the CONTRIBUTING.md have build or submodule commands in them, nor is there a shell script with them in it.
I'm probably not the only forgetful developer out there. I like to find build instructions within the project repo in a README, COMPILING or CONTRIBUTING file. When I run into odd issues, like submodules not updated, I find myself grepping the codebase for the appropriate git commands... to no avail.
A shell script would also be great, because global sea...
Use preprocessor macros to define the size and position of flash regions. This reduces all the different linker .ld files to a single template file, boards/common.template.ld.
The needed preprocessor values are made available in ports/*/ld_defines.c. . At build time, that file is run through the C preprocessor, generating ld_defines.pp. Then tools/gen_ld_files.py reads ld_defines.pp, common.template.ld files, and generates common.ld in the board build directory.
(There is ...
@dhalbert Thanks, did that.
-ttmetro
@ladyada yeah, right, it could be an possible issue with arduino as well. nrfx_qspi_write also require memory to be 4 bytes aligned as well. I will file an issue on Arduino SPIFLash repo here https://github.com/adafruit/Adafruit_SPIFlash/issues/40
@tannewt @hierophect I submit an PR to dcd_synopsys to not enforce VBUS sensing here, waiting for William to review since he is original write for the driver https://github.com/hathach/tinyusb/pull/234 . If that PR is merged, @hierophect can simply have the macro VBUS SENSE option for stm32 board.h and use that to either enable or disable vubs sensing in init_usb_hardware() of stm32 port without affecting other ports.
@hierophect also the issue with reconnection may not be related to the VBUS, since dcd_synopsys doesn't implement disconnection detection just yet https://github.com/hathach/tinyusb/issues/209 . I will try to implement that later on to test with.
ON my PCA10059 -- I can load 5.0 Beta.1 and even execute a program that is stored on it. It is only when I try to delete a file from the board that it crashes -- hangs then disconnects
I can refresh the .uf2 file if I just do a doubletap after trying to delete one file.
I have not repeated the storage.erase_filesystem() test when it requires the J-Link to recover....
hmph "I shoulda tested"
.. playing mp3 back in stereo on samd dac doesn't work. the way it handles stereo is different than nRF, where I did most of my testing, because L/R get separate DMA channels.
do you mean I2S DMA?
I think I mean DAC (headphones on pygamer)
oh, never mind, DAC
I wonder if there's another mode
do you mean the L and R need to be in different buffers, or just that you set up two DMA transactions? I have a vague memory of a way to set an increment for DMA so the data bytes/words don't have to be consecutive.
so L/R could still be interleaved
I don't know the specifics yet. I recall that there is special handling in the audio sample API ("single channel") that I think is related. I only just now tested this combination, and it doesn't work, so now I need to figure out what's up.
I assume that stereo works, generally, though I'll try a wave file to be sure
huh a wave file with these specs shouldn't be a problem ... should it ? bwv-854-abr-fm.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz
(it doesn't sound right)
@jepler I think I am now using adafruit:master. (I'm a github noob, so maybe.) MP3 I2S works there. Well, the signals look good to me. I am now playing both channels on my DAC, but am still getting a bad clipping-like sound, which I don't think is an I2S problem. I'm sorry that I am not able to provide a more complete report.
I do get a crazy memory error when I (accidentally) try to play a wav file as mp3, and when I try to play the cbr studio MP3 file from your mp3 set. Let me know if yo...
@Dar-Scott let's see if we can't make sure of the version you're using. The problem reading the cbr studio MP3 file sounds like one I believed I had found and fixed.
You could just try the 5.0 beta 1 release from circuitpython.org, it has MP3 in it. Or, you could verify that you built what you intended.
Open up the serial connection to your board, hit ctrl-c several times until you are dropped in the REPL. Paste in the lne just above the ">>>" prompt. It should look something like...
Last evening I built and flashed a uf2 bootloader onto an Arduino nano 33 ble board, hoping to try out CP 5.0 Beta.1. Unfortunately I think I am running into this issue as well.
After a double reset press the boot disk (NANO33BOOT) appears and I can successfully drag the CP .uf2 file to it. When the board resets, CIRCUITPY appears to mount. At this point If I'm quick I can open code.py in the mu editor, but any attempts to edit or save it fail with the board hanging and then disconnec...
@jepler Here's what I got:
Adafruit CircuitPython 5.0.0-beta.0-122-g67097e0e0-dirty on 2019-12-10; Adafruit Feather M4 Express with samd51j19
Whoops. Hit Comment instead of Preview. I'll switch to 5.0 beta 1 release. I missed that it was out.
Hi @sarfata, I need to add this board to the circuitpython.org website so it doesn't show up as an unknown board. I found the URL https://github.com/sarfata/shirtty-addon. Do you have any more info such as a photo of the board we could use? Thanks!
This is probably incorrect handling of the "single_channel" flag by audiomp3_mp3file_get_buffer
In 5.0beta1, play a stereo mp3 file to a stereo samd dac audio target. It doesn't play, or maybe gets stuck on the first buffer.
A mono output works fine with a stereo or mono source mp3.
nRF is not affected. i2s on samd may or may not be affected, should check.
@jepler I have acquired the latest 5.0 beta and the latest library bundle. Leveling up.
Adafruit CircuitPython 5.0.0-beta.1 on 2019-12-10; Adafruit Feather M4 Express with samd51j19
I can now play cbr studio.
I still have the noise, more for louder sounds, and maybe more for higher bit rates. My new DAC boards have not arrived, so I'm using the only one I have. I did notice that more and perhaps different noise when my hand is near the BCLK wire. I have a 6" patch, I'll try to sho...
@hathach if VBUS isn't actually required to connect and disconnect, why is it even a part of the self-powered devices spec for USB at all? Just power savings, I guess? The pullup resistor they mention in that appnote I linked above?
Adding with the limited info I had. If I get better info from the author, I'll update.
Iam just starting out so having very basic doubts , lets assume I made a school project in circuit python kit on adafruit kit , if I want to make it as a product what would be next steps
for example : Adafruit ItsyBitsy M0
@stuck elbow did you mention you had worked with the Meowbit before?
At a minimum, you could just buy ItsyBitsy boards, load your code on them, and resell them. But I could be misunderstanding what you have in mind.
@main meteor , I mean how would you make it like a finished project with circuit enclosed in plastic
@main meteor lets assume my project has components more than what I need , how could I reduce the components I dont need from my end product
Oh, you're thinking of a custom board and enclosure, that's somewhat more advanced.
@quasi pulsar You could start by looking at the schematic for the Itsybitsy or a feather, and get familiar with what's included. In general, the strict minimum that a processor needs is the processor itself with all the right pins connected to power/ground/left alone as appropriate, capacitors on the power lines, a set of crystal oscillators (which generate a clock signal that the processor uses) and typically a voltage regulator to make sure the voltage coming in is appropriate. The ItsyBitsy is pretty stripped down already so it's probably close to the minimum already.
You could also look at the Trinket, which is even more minimal/small.
Then you'd need to learn how to lay out a circuit, with Kicad or Eagle or whatever. Then you need to make sure you know how to upload firmware to it with something like JTAG, without the use of an Arduino bootloader, which won't be on there by default (though you could add it later)
Or, as @main meteor says, you can just take one of these minimal boards and stick it on an expanded PCB you design. There's no shame in that, tons of people do it to save time/money. I've seen itsy bitsys/etc mounted in 3d printers, drones, all over the place.
It also super depends on your project. There's lots of things out there that use the dev board (itsybitsy/whatever) and just have all the peripheral components on another circuit board and connect them together.
haha jinx, @ionic elk.
lol we on the same page. When I did my first big project I was very obsessed with doing it the "right" way, which lead me to spend a ton of time switching over to STM32 and new "professiona" toolchains that didn't even save us anything. It'd probably have been way cheaper if I'd just mounted an arduino on there for the first 500 units.
Here's an example: The let's split keyboard uses an Arduino Pro Micro and the PCB for it just holds the keyswitches and diodes: https://mehkee.com/products/lets-split-pcb?variant=5227242749980
@ionic elk yeah, I had similar thought process when designing winterbloom sol, but ultimately I did want to learn to make my own self-contained boards so.
I've been known to do exactly that, like this project where I just put a Teensy on top
Ofc, doing it entirely yourself is a good learning experience. But you should be mentally prepared to mess up a couple times if you do.
Yep. First revision of Winterbloom Sol didn't work at all. I forgot one of the power connections and totally wired the programming header to the wrong pins.
It's so easy when you're new to it to accidentally forget a power line, or not read up totally on a boot setting, or whatever. It can be kinda painful, especially if the board literally blows up on you.
There's also this one where I implemented an Arduino-like circuit along with my own customizations
I had a project where we didn't connect VBAT, and had to manually fix like 15 boards with an x-acto and magnet wire. So yeah - leave yourself space for a couple screw-ups
Is that all through-hole? It's so pretty.
I like to call these puzzle-piece engineering
lol
The beta boards have a teeny bodge because KiCad's footprint for tac switches isn't quite what I expected.
I think it'd actually be rad if you could take that even further - swap the 0.1" connectors for something super duper low profile and design them to be ordered in bulk with a bootloader already attached
you could probably make a business out of that... hmmm....
Looks good! Will merge and we can follow up with any USB changes later.
This is deliberate because the build info is in a Learn guide here: https://learn.adafruit.com/building-circuitpython/
Having it in both places would lead to instruction drift.
I'd be game to add a make command at the top level to sync (really update) submodules though. That way a git grep would find it.
@hierophect ok this is using the internal flash only right? or soldering a 2MB on the bottom?
@makermelissa FYI
@ladyada it's currently designed for internal flash only, with the options for internal flash left commented in mpconfigboard .mk and .h with instructions
The concern here is that not everyone thinks the same way and goes looking for a URL to get build instructions from.
Both a shell script and a small doc (say BUILDING.md) that references the build page, submodules, ports, and maybe mentions the unit tests would be wonderful. That way there is minimal content in the repo, and some hints to get people who think differently get going or get unstuck.
I don't actually think we need recursive. Pulling in the TinyUSB submodules doesn't help and just slows us down.
Swap these two lines so .len is second to match the other definition's order.
A few minor things. Overall this looks like an awesome improvement! Thanks!
Isn't the Pynt the smaller version? Is it the same exact screen?
yes pyportal pynt is same screen - ILI9431 - smaller 2.4" instead of 3.2" :)
Ok, thanks! I suppose we can always make a real board out of it if needed.
Yeah, it makes the website board management much easier to have it build as a separate board like this.
Originally I had it just below the bootloader, but I realized that would break any existing on-chip filesystems. We don't have such boards, but there are third-party boards that use on-chip filesystems. The same is true of the atmel-samd layout: I didn't want to destroy all the on-chip filesystems with this upgrade.
We could still decide to do this, but we need BIG WARNINGS.
The uf2 submodule also has (one) submodule, so we do need recursive. But I think we should remove the build instructions from here anyway (per the discussion in #2370), so I'll do that. The flash instructions are more specific to the port.
~/repos/circuitpython$ find . -name .gitmodules
./tools/uf2/.gitmodules
./lib/tinyusb/tools/uf2/.gitmodules
./lib/tinyusb/.gitmodules
./.gitmodules
Thank you, yes, those are through-hole.
The last boards I made that needed a bootloader flashed used an ordinary 0.1" rectangular header pattern. For the prototype boards, I'd solder on a header as I was flashing them a lot. For the production boards, I used pogo pins and the same pads. These days, I'd look at TagConnect as it's compact and headerless.
I've also gotten fond of spring loaded pogo pin clips for the 6-pin FTDI style connectors
wooooohoooooo adabox 014 is in da mail!
@tulip sleet you around?
yah - I was out for hours but am back.
I'm confused about the current ordering of things in the fs vs what they are now
does the existing nrf linker already have a bleconfig area?
not really - there's a mention in the comments: ...
hold on for link
but I don't think that's even right.
I agree the goal is to have the fs in the same spot as before
and if we have flexibility to change the ble config size that is a bonus
how many bonds can we store in 32k?