i should take the atmel impl, because it tries to maximize resolution
#circuitpython-dev
ionic elk
no, I'm pretty sure it's going for raw frequency resolution too
The setting for max duty cycle resolution is to simply set the prescaler to the lowest possible value.
tulip sleet
you mean divide the least?
tulip sleet
so that's what the nRF impl is already doing too. It starts at divide/1, and goes to /2, /4, etc, until the counter can be in range (4..32767)
ionic elk
It's going for max frequency resolution. You can only factor in duty cycle res by multiplying the user frequency by the duty cycle resolution.
tulip sleet
it maximizes the maximum usuable COUNTER value
solid zealot
If I wanted to use two circuit playground boards to detect when the IR connection between the becomes interrupted, like someone walking between them, and have it ready, how would I go about setting that up?
ionic elk
@tulip sleet do you feel like it's making sense? It'd be easier to brainstorm with a whiteboard π
But for now I think that appnote is the best resource. That table is the best way to think about it
tulip sleet
i'll do some computations on paper π
idle owl
@solid zealot You'd probably be better off asking in #help-with-circuitpython or on the Adafruit forums. This channel is more for development discussion.
solid zealot
Ah ok ty
idle owl
Don't want your question to get lost in the current lively discussion π
idle owl
@ionic elk That's what it's for!
solid zealot
Sorry itβs hard to see all the channels on my phone π
idle owl
@solid zealot No worries! Simply wanted to make sure you get the assistance you're looking for if it's available π
ionic elk
@tulip sleet if you verify the frequency problem, should we make an issue for that?
tulip sleet
yes, still thinking about it; i'll take responsibility for that
timber mango
Been reading along; might I suggest 10 bit is a better compromise. I would want a bit better than 1 degree accuracy from servos!
tulip sleet
@ionic elk ^
ionic elk
Can do, but note, that lowers max frequency to 70kHz.
umbral dagger
Anyone ever see anything like this: "When I follow the posted instructions for installing circuitpython onto my Hallowing M0 as soon as the UF2 file has been loaded, my Lenovo Flex 5 (Windows 10) loses touchpad capability, and the readout on the LCD display for the Hallowing is garbled."
Same process/board works fine on a different Windows 10 machine. But the same behavior is seen when reconnected to the Flex 5.
timber mango
@ionic elk I saw that, yes, and to me that sounds perfectly fine. I can imagine that fast pwm people wouldn't agree...
tulip sleet
@umbral dagger the trackpad going off is due to the mouse HID device in CircuitPython, so they could change a setting to not disable the trackpad when an external pointing device is plugged in. The "garbling" I don't know, would need to see a picture.
ionic elk
At some point we might need to add a setting that makes this tradeoff more clear.
@timber mango Actually, that could be it - add a new optional setting to the binding that allows you to override the default bit resolution of PWMOut. Lower for faster PWM, higher for better servo resolution.
@tulip sleet what do you think about that?
tulip sleet
I think that might make sense. We could discuss this in an "in the weeds" session, or in an issue.
ionic elk
this makes this so much cleaner too. Observe (duty*PULSE_RESOLUTION)/65535
beautiful
I'm actually a big fan of the idea. It'd be ideal for STM32, and would probably work pretty well with Atmel and NRF too. Covers all use cases, only one extra optional input to PWMOut, makes it clear what the actual resolution and max frequencies are, etc.
ionic elk
@ivory yew what was the range for audio, again?
Because this 10 bit business also wrecks frequency granularity. 20kHz and 16500Hz both land on 20kHz, for instance.
ivory yew
20hz - 20kHz
ionic elk
would you hear the difference between 17k and 20k?
ivory yew
absolutely
ionic elk
K I'm dropping back to 8 bit PWM resolution. And given this info I highly recommend we get this feature in ASAP.
ivory yew
This doesn't list all the way up to 20k (because above 8k is basically "overtones" but you'd still hear it): https://pages.mtu.edu/~suits/notefreqs.html
ionic elk
Yeah even on 8 bit that's pushing it. 8 bit intervals are 20507, 19301, 18229
ivory yew
I doubt anyone would output a "note" that high
but lower notes have less distance between them.
ionic elk
Oh, yeah I was looking at the wrong data
ivory yew
if that makes sense
ionic elk
It should adjust for that
at lower frequencies it'll be near exact. Only at high ones will you hit the big gaps
main meteor
Yes, it's reciprocal
ivory yew
that's probably okay.
this page is super helpful for that: https://pages.mtu.edu/~suits/notefreqs.html
like we'll need to be able to set to 16.35hz and 17.32hz at the lowest end
but 7458.62 and 7902.13 are the highest two notes.
so like 7450 and 7900 are probably passible there
ionic elk
lets see if I can dot hat
ivory yew
but 16.00 and 17.00 probably won't sound right
(note: you likely won't be able to hear <60hz on tiny little speakers anyway)
ivory yew
that's off by enough to sound out of tune to most people
raven canopy
the pessimist in me feels bad for the SAMD21 implementation. its likely going to miss out on all of this.. π
due to build size. not capability.
ionic elk
It won't if it implements dynamic duty cycle resolution adjustment like I've suggested
ivory yew
@ionic elk "Below 500 Hz, the JND is about 3 Hz for sine waves, and 1 Hz for complex tones; above 1000 Hz, the JND for sine waves is about 0.6% (about 10 cents)."
ionic elk
I was overly pessimistic you can actually hit 7457
ivory yew
JND: Just noticeable difference: https://en.wikipedia.org/wiki/Just-noticeable_difference
PWM falls into "complex tones" as a square wave has ostensibly infinite harmonics.
ionic elk
It rounds, doesn't average, so people will have to either mess around or I have to put in a better rounding algorithm
onyx hinge
"10 cents", or 0.5% frequency difference, can typically be distinguished in ABX testing. The ratio between those two high 7458.62 and 7902.13 notes is 1.059, but the ratio between the PWM frequencies 7630 and 8003 is just 1.048, so it will not sound like a half step. The difference between the ideal and produced pitch ratios is about 18 cents off.
ivory yew
this also comes into play if they use this for note output alongside other audio equipment
7630 will sound wildly out of tune.
ionic elk
Fortunately that's the one that I can fix, you can hit 7457
you just have to undershoot with what you plug in
ivory yew
ah
ionic elk
it always rounds up
ivory yew
(again pretty rare that someone would ever play a note that high)
like a lot of analog oscillators have a "sweet spot" as well
onyx hinge
yeah, I was focusing on the relative error (whether you can play a tune and have it sound IN TUNE) but absolute error is important if you wanted to play in tune with a piano, etc., in the real world
ionic elk
but I want to note that even dropping to 7 bit resolution literally halves this error
ivory yew
like there's plenty of professional grade things out there that only sound in tune from C3-C6.
onyx hinge
nRF's PWM audio is not great for absolute pitch either, though (assuming the base oscillator is accurate) I could match popular audio sampling frequencies to within 4 cents
ivory yew
Basically - we don't need the whole range, we should just probably document the range where it's accurate for audio.
manic glacierBOT
onyx hinge
(it makes different choices than the "regular" PWM out, it will choose non-round top values like 167(!) for nominal 48kHz audio. not all PWM modules might do this)
ivory yew
people who want really accurate tuning probably won't use PWMs anyway. π
onyx hinge
no "true DAC" on nRF so it was the fallback choice
ionic elk
Well, just to be clear: at 4 bit resolution, 7458 goes to 7460, and 7902 goes to 7903. We can easily hit super accurate frequencies. But it comes at the expense of the servo people
timber mango
@ionic elk Frequencies of timers 1,8,9,10,11 are sysclock times 2, right? So 168 MHz instead of 84. Is that right and are they free and would that help?
onyx hinge
saying you care about C6 and not C8 is like letting you have two bits of PWM back
ionic elk
Raising the max frequency could help a little but this is really more of a resolution problem
I'm going to leave this up to @tulip sleet and @slender iron. If I put in a sliding scale for how many bits people want, it makes everybody happy, so hopefully we can just do that. Otherwise I think 8bit resolution probably comes close enough to each to be ok.
The servos won't get sub 1Λ actuation and we won't be able to hit a couple of high notes but I think it's generally pretty decent for overlap
onyx hinge
hmmm, so if you want to have a single cycle of a 587.33Hz sine wave (D5) in a 22025Hz wave file, you can choose between having 37 or 38 cycles, and the ideal's nearly 37.5 for an error of 23 cents. π¦
but if you have 10 cycles instead, which is just 375 samples, you can pretty much nail it
this makes me think the "tone out" function should (A) use several cycles and (B) pick DAC over PWM. I think it uses a single cycle, and prefers PWM anyway...
ensuring that you have at least a couple hundred samples and at least one full cycle pushes the max error in cents way down for the example values I'm playing with anyway
"dithered pwm" would help but not a lot of devices seem to have it
ionic elk
Has anybody actually used the nrf or atmel boards with servos, by the way? The way they're set up now, they seem completely optimized for frequency resolution, which should be coming at the expense of people's PWM
at least at certain frequencies that are close to a prescaler value
@onyx hinge I've got a dithered pwm appnote that I could implement but i don't think it's very high priority.
onyx hinge
I have some servos but no way to really measure the absolute accuracy of their rotations
also no concept of what is considered "good accuracy" of a servo
ionic elk
also @timber mango only a handful of the advanced timers support above 84MHz, and we don't distinguish between the advanced and standard ones, so I think higher frequencies are off the table.
onyx hinge
you basically have a small DMA buffer and fill it with X or X+1, according to the "in between" value you're seeking
at least that's my very quick read of it
and yeah agree that our excitement to talk about this topic shouldn't become a drag on actually implementing something that can be evaluated in a real world, instead of theoretical, sense.
sly falcon
@crimson ferry Howdy! Sorry I haven't gotten back to you sooner.....my city and county are in the middle of a wildfire and things have been hectic since last thur/fri.
I was able to test the v1.5.0 release of NINA firmware, though, for two days last week at the office, and it worked fine. Oh - and that was on a WPA2 Enterprise network.
So yeah...haven't been able to do any other testing, but I plan on some more eventually once life is back to normal...or at least normalish π
crimson ferry
I can't imagine, been reading about the fires, but wow. Thanks for the update, good to have some regression π
Stay safe.
sly falcon
Thanks!
onyx hinge
urgh a fan is going bad in my home circuitpy development machine. rrrrrrr-rrrrrrr-rrrrr
sly falcon
I'm in Santa Rosa....and one of the fortunate ones - I've had power, cable tv and internet this whole time....and lots of anxiety and frazzled nerves π heh
onyx hinge
@sly falcon hang in there and take care of yourself before seeing to circuitpython π
sly falcon
@onyx hinge ugh.....my desktop at work has a noisy fan on the video card...otherwise the machine is silent....it gets annoying at times, so can totally empathize! π¦
@onyx hinge thanks!
manic glacierBOT
timber mango
Hi.
I need some guidance regarding circuitpython and adafruit featherboards. I wanted to get a board with wifi-support. Here is adafruit feather huzzah mentioned (I assume the ESP8266) https://github.com/adafruit/awesome-circuitpython#hardware but checking https://circuitpython.org/downloads and https://github.com/adafruit/circuitpython/releases/tag/4.1.0-rc.1 there are no bin-files for the huzzah with ESP8266 https://www.adafruit.com/product/2821
Any idea if its possible to get the adafruit huzzah ESP8266 running with circuitpython?
raven canopy
@timber mango CircuitPython support for the ESP8266 was dropped as of version 4.x. The main rationale for this was due to the ESP's lack of USB Drive capability. The current WiFi approach is to use a PyPortal, Airlift board, or an Airlift breakout (all use an ESP32 as a wifi co-processor over SPI).
timber mango
@raven canopy thanks.
raven canopy
I'm trying to see if I can find any of the old instructions for loading 3.x and earlier on the ESP8266...
timber mango
acutylly I have adafruit featherboard ESP23 and though I buy an featherboard which has support for micropython, where I was thinking te ESP8266 had it... But no luck on this side....
sorry... support for circuitpython...
onyx hinge
@timber mango you can also use micropython on ESP8266 and ESP32. You can't access all the circuitpython libraries without adapting them, but it might still let you achieve your goals.
timber mango
Your right. Micropython is running. I am not that good in python to adapt libraries, or in other words, I think it will be to time consuming. I wanted to connect Adafruit Flora LSM303 sensor, but could not find libraries. Circuitpython has working sensor-libraries, so I thought buy a proper circuitpython board and use the available libraries to connect.
timber mango
With the current information, I have to change my tactic. Now I am heading for accelerometer and gyro sensors, which have micropyhton support. Cross fingers π
onyx hinge
@timber mango yes they are quite different. It sounds like trying with circuitpython 3 is possibly your best bet, I'm just not sure where to download a build that old ...!
timber mango
If you have hints or advices, they are very welcom π
onyx hinge
https://github.com/adafruit/circuitpython/releases/tag/3.1.1 hmm is feather huzzah the one with esp32? Not sure.
but here are the files from the 3.1.1 release
no, that's 8266
afk, time to make some dinner π€€
timber mango
Enjoy your dinner. I will hit my bed. Anyway Thanks!
solar whale
@timber mango FYI - there has never been a CP build for the ESP32 β only for the ESP8266 and as noted it was dropped with 4.0.
onyx hinge
(hmmmm is "blinka, except for micropython" a concept just a little too far out there ...? i.e., a layer that lets you use many circuitpython libs on a base of micropython. I bet a motivated person could do it.)
main meteor
That's impressive.
manic glacierBOT
tulip sleet
re ulab numpy-like library: this looks very interesting and if it fits, it would make a good addition to the builds for the higher-capability microcontrollers we are now supporting. It is not quite dropin due to some API changes we've made. Also there are some bugs to fix
manic glacierBOT
ionic elk
@tulip sleet and @slender iron I found this piece of linux c magick that would allow me to grab the containing struct of a UART pointer without actually needing a root pointer array. It's what stm32duino uses:
serial_t *get_serial_obj(UART_HandleTypeDef *huart)
{
struct serial_s *obj_s;
serial_t *obj;
obj_s = (struct serial_s *)((char *)huart - offsetof(struct serial_s, handle));
obj = (serial_t *)((char *)obj_s - offsetof(serial_t, uart));
return (obj);
}
do you think it'd play nice with the GC or not so much?
tulip sleet
is this struct serial_s allocated on the heap or statically?
the point of the root pointer list is to note objects that, even though they have no other pointers to them, should be used as starting points to mark used objects during the mark phase of GC.
ionic elk
It's a protected variable in a c++ class
So I guess I'd want to keep the items in the root pointer list, but maybe I wouldn't need to actually fetch them out of it
onyx hinge
Will an internal pointer alone keep an object live for gc? I dunno
Unless it's documented I'd guess not a good idea to depend on it
Looks like the definition of BLOCK_FROM_PTR assumes it is passed the first byte of the allocation
graceful heart
@tulip sleet would it need to be included in the build of CPy or is possible to include it as an optional library?
tulip sleet
it would need to be part of the build, as it is C code
@ionic elk right, the root pointers list is not mean to fetch from, it's just a list for the GC to use
but is it static or was it malloc'd?
ionic elk
@tulip sleet I guess I'm confused, neither? Why would it be? It's just a component of a C++ class
the wizard function grabs it from anywhere
tulip sleet
@ionic elk is the instance of that class allocated at compile time or at run-time? Who calls the constructor?
Is there C++ code in the HAL? I thought it was all C. I'm a little worried about which version of new any C++ code is using: it needs to allocate storage in a way that's compatible with the GC.
meager fog
@tidal kiln no rush - checkin' if your gizmo guide will be done today
tidal kiln
ooo. probably not. sry. i keep tweaking the code...but could be getting into feature creep land at this point.
meager fog
yeah i think... tweaking is done - time to document π
dont have to write guide today but the project works well as is
tidal kiln
okie doke
ionic elk
@tulip sleet sorry for the confusion, let me start over. The linux function I posted comes from stm32duino, it's not a part of the ST HAL. They're using it to link the HAL handle of the UART (which is the only context you have in an ST IRQ) to their own UART object which contains their rx buffer and other essential tools.
I have to do the same thing in my own code, only I iterate through the list of root pointers to all the cpy busio uart objects and see which one has a handle that matches the one in the IRQ.
Their solution, while it contains more magic, has the appeal of not needing to iterate through the root pointers and check each one for a match, and so is probably faster.
but it's probably not that important either way, and the root pointer approach is probably safer, since I think the above could potentially start looking for a struct that doesn't exist.
tulip sleet
I was confused when you said root pointers, and thought you were talking about CIRCUITPY_COMMON_ROOT_POINTERS, or something. Do you just mean the table of UART objects you keep?
is the HAL object allocated dynamically?
ionic elk
It's in MICROPY_PORT_ROOT_POINTERS
tulip sleet
what's the name of what is in MICROPY_PORT_ROOT_POINTERS?
i don't see anything stm32f4-specific in the source tree that adds stuff to MICROPY_PORT_ROOT_POINTERS
ionic elk
I have an array of busio_uart_obj_t type pointers in the MICROPY_PORT_ROOT_POINTERS alongside CIRCUITPY_COMMON_ROOT_POINTERS called cpy_uart_obj_all. Whenever a uart object is created, it is added to this list.
I mean there's nothing in master yet, this all is UART specific
I would have used a static array, but tannewt was concerned that I'd get bad references since the GC could eliminate members of it at any time.
tulip sleet
But are these busio_uart_obj_t objects the objects you return when someone calls busio.UART() ?
let's audio chat, cause it will be faster
ionic elk
I don't really understand that question. Sorry @tulip sleet I don't mean to waste your time with this. I thought it was an interesting linux function, that's all
tulip sleet
amelia earhart
ionic elk
@meager fog Hiyo, as I'm debugging I've found a funny problem with that debugging gps library you sent me. When I soft reboot the device, whether through writing to the sketch or manually, it just returns all 1s or all 2s. But from my debugging text, it isn't actually attempting to perform a read at all.
But it's only on the STM32. So I'm trying to figure out what I'm missing
timber mango
Hi! I've been looking at issue 2076 in core ("Transparency setting for shape fill color cannot be dynamically changed after initialization") and it looks like the issue is really in the adafruit_display_shapes library. What is the proper procedure for this? Should I open an issue against the library and reference that in issue 2076? I've about got a PR ready for the library
idle owl
@timber mango That would be perfect!
timber mango
thanks! Will do
manic glacierBOT
tulip sleet
@ionic elk before you write that PWM issue, I want to talk to you again; I talked to Limor this evening about this. We can do some kind of whiteboardy thing if necessary
remote zenith
out of curiosity, is this normal? I'm not having any issues with my board and my code runs as expected so I'm guessing it has no effects. I'm using a CPX
tulip sleet
@remote zenith probably you just unplugged or reset the board without ejecting it, and Windows isn't sure it was unmounted cleanly. If you scan and repair, it will probably say there are no errors. To avoid this, you can "Eject" the drive before you unplug or reset it.
remote zenith
ahhhhh, I see, thank you!
tulip sleet
windows especially can take up to 90 seconds to write everything to the drive; this is being fixed, we think (it's a decades-old problem)
remote zenith
oh wow, that's quite a while
tulip sleet
this is especially true for very small drives (FAT12)
it's from code that was written for floppies
remote zenith
okay that brings up an important question
that's not serious in the slightest - if I grab an I2C port expander, can I bitbang PATA?
remote zenith
PATA uses a 40 pin connector I think, of which half are ground
never mind, about 29 data pins unless I messed up my counting
tulip sleet
you could try it π if there a minimum speeds on some things, it might be an issue, but maybe that's not true
remote zenith
First I'd need to go find a PC with PATA!
Actually-
I just need to get a USB CompactFlash adapter
tulip sleet
i have had USB external drives that supported PATA
I mean enclosures for PATA drives
remote zenith
oh wow
tulip sleet
i think
remote zenith
I mean, fair enough, for some time that would have been cheaper than SATA
remote zenith
yes they are
This is off-topic for this channel but just for kicks and giggles...connect the I2C port expander to the link port on my TI-84+ and bit-bang I2C to bit-bang PATA...all with Z80 assembly. This is definitely a good idea and absolutely nothing could go wrong with this.
tulip sleet
https://www.microcenter.com/product/285941 is something like what I have
but they have several like that, not hard to find
you should know that @ tannewt here is using circuitpython to control GameBoys via the cartridge port
tulip sleet
these are all over the place: amazon, etc. not rare
remote zenith
I never knew these existed, thank you!
tulip sleet
just search for USB IDE adapter
remote zenith
These are way cheaper than I would've thought
tulip sleet
well, they were a high volume item when IDE was common, and when the transition to SATA was happening, and there are still IDE disks people want to read
remote zenith
So now I only need to bitbang USB host π
tulip sleet
good luck with that π
remote zenith
(just joking but the TI-84+ actually does do that already)
I most likely could write a driver for usb8x, which does USB host on the TI-84+
(link: https://en.wikipedia.org/wiki/Usb8x)
This is very off-topic from this channel now
tulip sleet
i'm on my way to π€ but it was fun
remote zenith
sleep well and I'll see you around!
main meteor
I followed one of those USB-IDE adapters with an IDE-PCMCIA adapter to read an ancient 6MB memory card once.
remote zenith
hahahaha wow nice!
manic glacierBOT
ionic elk
@tulip sleet happy to talk whenever you want
tulip sleet
@ionic elk now is fine
slender iron
The counter clock frequency (CK_CNT) is equal to fCK_PSC / (PSC[15:0] + 1).
meager fog
@ionic elk hihi back, if you wanted to look at the gps library again
ionic elk
@meager fog hiya, I've been in a PWM algorithm discussion with @tulip sleet and @slender iron, but I'll take any help I can get on the UART end
meager fog
ok whats the UART Q
btw the stm32's went into the shop
so expect a lot of users/bugs/feature requests π
ionic elk
I'm trying to determine what is going wrong, which is best seen from the python end
Specifically, when soft rebooted, it starts reporting that it's seeing 1 character available, but my debugging doesn't report that it even hits the read API
and generally, it seems much too slow
Just knowing what exactly is happening with that 1 character report would be tremendously helpful.
meager fog
ok give me a bin
ionic elk
up on github!
tulip sleet
@ionic elk for later: Python version of nRF PWMOut prescaler and max-count calculation, and output
ionic elk
@tulip sleet I think I have figured out how my algorithm differs. I'm still trying to reconcile it with my equation based approach mentally, which is closer to existing walkthroughs of the STM32, but it looks like I was approaching the incrementation backwards from you and Scott.
ionic elk
What I've whipped together for the moment is this:
for (int i=0; i<65535;i++) {
period = source_freq/(i*frequency);
if (period <= 32767 && period>=4) {
prescaler = i;
break;
}
}
if (prescaler == 0) {
mp_raise_ValueError(translate("Invalid frequency supplied"));
}
^ a python version of the nRF prescaler and count finder, run on variou PWM frequencies
yes, that looks like the nrf thing. the 4..32767 is nRF specific: can you use 0 to 65535?
your code is just trying all the divisors, as expected. i will not get very big π
ionic elk
well, 0 isn't really very useful because that's 0 pulses per interval. 2 is the point at which you'd presumably be able to actually have a duty cycle.
tulip sleet
right π
ionic elk
But I can go up to 65535 actually, I mixed up the prescaler and the period limits now that I double check the datasheet. Divisor should only count to 15 bit
tulip sleet
so you are able to do finer divisions instead of just power of two
ionic elk
I'd really like to bring together how I was thinking about the math + how micropython does it in my head, but it might take a day or two
sleep on it etc
tulip sleet
since the input frequency is an integer (can't get below 1 Hz), then i won't get above72, I guess
sure
@ionic elk btw, did you order some STM32F405 feathers?
ionic elk
I've got 2 right now, I don't have the store ones if they're different
@tulip sleet should I get more?
tulip sleet
@ionic elk no, they should be fine. I got two store ones; I never had protos. I'm not sure if there's any significant difference. Limor would have told you
slender iron
@ionic elk @tulip sleet I updated Dan's python example for the stm constraints: https://gist.github.com/tannewt/b17bb946789625ca8d4d805a0ca1e61d
sample output at the bottom
includes target frequency vs actual too
ionic elk
@slender iron did you put in my updated algorithm to test, or is that just the expected value set?
slender iron
I didn't see any updated algorithm. I just based it on Dan's py file
ionic elk
Ah, I see, it's just the math
slender iron
and swapped the divisor to 16 bit
ionic elk
Testing now, we'll see what it outputs
tulip sleet
@slender iron I made a pass through all the unlabeled or 5.x issues and PR's (as you can see). The only thing that probably should really be in an alpha.5 is the two I2C's for CPB, as we discussed. Lots of other bugs but no showstoppers.
everything (both issues and PR's) has a milestone now, and I added a bunch of labels as well
slender iron
@tulip sleet how about this? ```python
import time
import adafruit_ble
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServiceAdvertisement
from adafruit_ble.services.nordic import UARTService
ble = BLERadio()
advertisement = ProvideServiceAdvertisement(UARTService)
while True:
while ble.connected:
for connection in ble.connections:
if UARTService not in connection:
continue
print("echo")
uart = connection[UARTService]
uart.write(b"echo")
# Returns b'' if nothing was read.
one_byte = uart.read(4)
if one_byte:
print(one_byte)
print()
time.sleep(1)
print("disconnected, scanning")
for entry in ble.start_scan(advertisement, timeout=1):
connection = adapter.connect(entry)
adapter.stop_scan()
print("connected")
it won't scan if no connection has a uart
while True:
has_uart = True
while ble.connected and has_uart:
has_uart = False
for connection in ble.connections:
if UARTService not in connection:
continue
has_uart = True
print("echo")
(untested, just playing with the API)
removing the service recognition makes the advertisement printing a little less nice but that's ok
ionic elk
Ok, new PWM algorithm is in and tested.
tulip sleet
@slender iron I think that looks really nice. "Radio" is a great term: really describes the actual hardware well.
slender iron
π I'm on the right track then
tulip sleet
@slender iron
while ble.connected and any(UARTService in connection for connection in ble.connections):
is that too obscure π
slender iron
fancy π
tulip sleet
I think that works
slender iron
looks cleaner to me
ivory yew
If that's going to be common usage I'd suggest wrapping it in a helper method. Like ble.connections.find_service(UARTService)
tulip sleet
connections is just a sequence (prob tuple)
slender iron
the radio class could do it though
tulip sleet
should it be first or all? find_service(UART_SERVICE) with_service(UART_SERVICE). Latter might imply all such services
slender iron
I won't worry now. we can add it later
ivory yew
unless plural
yeah
one we figure out the building blocks we can optimize common cases with helpers like that.
slender iron
totes
tough flax
Ugh! Last minute CP issues on Halloween
Missing audioio on a CPX BLE Alpha?
Not trying to do audio but the CPX code requires it?
tulip sleet
I just taped the Monster M4SK to the window π
tough flax
Traceback (most recent call last):
File "code.py", line 2, in <module>
File "adafruit_circuitplayground/express.py", line 53, in <module>
ImportError: no module named 'audioio'
tulip sleet
you can remove that part from the CPX library.
audioio has been replaced by audiocore and other more specific modules
tulip sleet
just get the source, the CPB should be able to load the .py
tough flax
Link?
tulip sleet
do you need BLE for this Halloween project?
raven canopy
hmm. it should still map fine with audioio though...
wrong ref, i think...
oh wait. nvm. nrf doesn't use AUDIOIO_COMPAT. argh. sorry.
manic glacierBOT
tulip sleet
tnx!
manic glacierBOT
meager fog
@ionic elk hiya sorry i could not test uart yeterday, i was croutoned to deth
manic glacierBOT
main meteor
Croutons for Halloween? I would think that's more of a Thanksgiving thing.
ionic elk
@meager fog you died of salad?
meager fog
yeah basically π
ionic elk
that sounds horrible
meager fog
its when you cant do anyting because you have a small interrupt action required every few minutes
ionic elk
I am saleaeing the heck out of UART today but I will appreciate any insight you can bring!
meager fog
so you end up context switching and then you're like "all i did is eat little croutons"
ionic elk
yeah I remember that from when I was doing more managementy stuff
it's the worst. I had to put up an open/closed sign at my desk
which everyone promptly ignored
meager fog
@ionic elk ok firs tup why are you salaeing uart
ionic elk
I'm examining what happens at startup on an atmel control vs the feather f405 with an extra line for IRQs. I'm seeing differences in how TX and RX data is spaced, and it seems related to where the IRQs unexpectedly halt. I think there might not be adequate IRQ protection around TX writes, and that's disrupting buffer variables.
meager fog
ok so when you transmit data, if an IRQ comes in during that time for something else, you have an issue?
at this time you dont have DMA for TX, you have to submit each character to the TX HAL, then wait for it to return?
or do you have an IRQ when the TX buffer is empty?
ionic elk
The problem only seems to occur at startup which was why I didn't encounter it before. It seems like if I get an RX during the first TX write of the library, it disables IRQs and can't restart them.
meager fog
ok checking a GPS against UART, its def able to get larger qty of bytes at a time now
so that is solved yay
ionic elk
Yeah I added a LOT more protections. It shouldn't brick itself all the time anymore either
meager fog
the input buffer is 64 bytes
ionic elk
But evidently I still missed something
ionic elk
Just copied that from NRF
But I can make it bigger, I wouldn't guess that's a very big deal
meager fog
yeah... i think bump it to 256 bytes
ionic elk
k
ionic elk
chonks not dinks
meager fog
yumm chonk
ok i will try the GPS parsing demo next
did you have anything that wasnt working
that i can replicate for ya
ionic elk
If you soft reboot, it borks the heck out
interrupts are halted, but it constantly returns a value for the size of the buffer
But I don't see it actually entering the function that sets that value
So I don't know what's going on in the python there, any insight would be helpful
meager fog
@ionic elk whats the exact code you're running
you can give me a zip or the code.py
so we are looking at the same thing
softrebooting with just RX works ok - https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/CircuitPython_Essentials/CircuitPython_UART.py
meager fog
oh yeah thats weird
works every other time
or at least, sporadically
do you need something to constantly send data so you can repro consistantly?
when it wedges UART, it never seems to start with an empty buffer
code.py output:
2
2```Hmm I thought it borked every time, unless I swap it out with another program
ionic elk
Does the python lib just keep reporting that value if the read halts?
Because my debugger doesn't show it even ever getting to the read function
meager fog
it never 'halts'
runs forever, reporting only 2 bytes read
it never reads more data, so the GPS parsing code does not run
im running the binary you posted in the UART PR
with a GPS module wired up to send data to TX
on the feather stm32
manic glacierBOT
meager fog
@ionic elk i think we should verify we have the same output
perhaps you are debugging something different?
ionic elk
@meager fog sorry I got distracted assisting somebody in the help channel
I also don't see it ever stop reporting the buffer size
but I have a GPIO trigger for when it enters the c-level read function and it actually never even hits tat
so I was wondering if the python might be getting stuck somehow
meager fog
ok lets remove the GPS library
what is your os.uname?
Adafruit CircuitPython 5.0.0-alpha.4-285-ga8070a418-dirty
ionic elk
Adafruit CircuitPython 5.0.0-alpha.4-286-gc78d79938-dirty on 2019-11-01
meager fog
ok tahts a different build
how about you try the firmware bin you posted
so you can see what i see
you can stash your commits
then you can run this standalone example
import busio
import digitalio
import time
led = digitalio.DigitalInOut(board.D13)
led.direction = digitalio.Direction.OUTPUT
uart = busio.UART(board.TX, board.RX, baudrate=9600)
uart.write(b'$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n')
uart.write(b'$PMTK220,1000*1F\r\n')
while True:
print(uart.in_waiting)
time.sleep(0.01)
if uart.in_waiting < 32:
continue
data = uart.read(32) # read up to 32 bytes
if data is not None:
led.value = True
print(''.join([chr(b) for b in data]), end="")
led.value = False
Ok
ionic elk
Dang, that built just crashes on me super hard
meager fog
hi back from commuting
ionic elk
At least on mac something is horribly wrong
meager fog
ok you cant even get USB to run?
ionic elk
It works ok when plugged in but whenever you restart it crashes
crashes USB that is, not just a circuitpython crash
OH wait durr wrong bin dang it sorry
meager fog
bbiab i have a review for 30 min
ionic elk
No worries I think I can take it from here, thanks for the superior testing sketch
much simpler
meager fog
@ionic elk hihi ok so did you load the test sketch
slender iron
@tulip sleet @ivory yew back at you on the BLE library PR
tulip sleet
@slender iron gotcha
ionic elk
yes I got it up and running. While this build doesn't have my interrupt signifier, so it's not easy to tell when they halt, it's still showing what could be problematic TX/RX overlap at startup.
I'll dig into it and check in again later.
meager fog
@ionic elk ok if you make a new build with the irq signifier
please post here and i will test it
@ionic elk next up i can check out the PWM as well
ivory yew
@slender iron will try to poke at it tonight
slender iron
π
ionic elk
fixed uart
manic glacierBOT
meager fog
@ionic elk lol
ionic elk
@meager fog new bin up for UART, should work with GPS lib
meager fog
@ionic elk you fixed one thing
but then i put it to the ULTIMATE TEST and it did not pass
ltimate test is while you have TX going to the feather, have RX on GPS also connected to TX
ionic elk
ah.
meager fog
lemme make sure data is coming out
meager fog
lol ill scope first
ionic elk
No, I need to get in there and implement full IRQ writes. I was going to raise an issue for that and wrap it up after displayio but if that's a core feature I'll get it in this weekend
meager fog
oh wait it does
i think
it is not happy...
but it is getting data
lol
some data is corrupted
ionic elk
Writes block reads right now, that's how I was getting the HAL to cooperate
meager fog
probably due to the buffer size tho
meager fog
hmm want to try bumping buffer size up
well i dunno
i mean it isnt writing data in this example
so why would that make any difference
give me a build with a larger RX buffer
ionic elk
ok we can give it a shot
wait you specify the receiver buffer size, it's exposed in the API
meager fog
where?
ionic elk
busio.UART(tx, rx, *, baudrate=9600, bits=8, parity=None, stop=1, timeout=1000, receiver_buffer_size=64)
meager fog
oh neat, and you respect that?
ionic elk
yeah all variables are supported
meager fog
as good as it can
i think document that writes are blocking
and thats fine
it isnt that unusual to have uart writes block - maybe one day we will have DMA or IRQ-based
ionic elk
It won't be too much work to put in the non-blocking ones, it's just I only found that issue today, but I can definitely try a prototype pretty quickly.
But if it's working well enough I can just start a long term issue and push it behind displayio etc
slender iron
yup
onyx hinge
good friday afternoon everyone!
meager fog
@slender iron ok please review the UART PR at your convenience
functionally its good but needs a stylistic review
onyx hinge
I am looking at the CPB / nRF "speaker noise when touching AUDIO pad" . Making this change will cause problems for e.g., simpleio.tone, because it does NOT set the SPEAKER_ENABLE pin. So without changing the code, your CPB is silenced.
slender iron
kk, should be able to do a pass today
meager fog
PWM needs a little more testing, what is next after that?
i was thinking displayio but...other stuff could be good too
onyx hinge
should I go ahead and PR this and file issues against (presumably) simpleio and circuitplayground modules?
slender iron
looks at stm issues
meager fog
@onyx hinge we tell people to manually enable speaker - check the CPX guides
manic glacierBOT
meager fog
@slender iron @ionic elk tawk amongst yerselves. i have weekly meeting. bbiab
onyx hinge
@meager fog ok my first test code was one that Kattni sent me for testing simpleio.tone and my change silenced it.
but if the guides would already cover that, then no worries
needs to learn to read guides and use the code in them for testing by default
ionic elk
@meager fog PWM should be ready for whatever you want to put it through, it matches NRF and atmel more closely now.
slender iron
this should be easy to knock out and critical for some libraries and examples that use board.I2C
ionic elk
Ah yeah I can get that out quickly
slender iron
@ionic elk please assign to yourself when you are actively working on an issue. leaving it unassigned means someone else can help us out and do it
https://github.com/adafruit/circuitpython/issues/2194 should be fixed for delay
ionic elk
Ok, I'll get on those next. I'll be working on stuff this weekend, so feel free to add anything else you'd like to the cleanup list and I'll get on it.
gotta go to a thing, be back tomorrow.
river quest
@ionic elk (talkin for limor, she is in a meeting) limor will be around this weekend to test anything ya need as well as give you more issues to work on if ya get through'em
granite crow
Hi, on stm32 based feathers, the A0 input is the ADCs channel 0? Or it doesn't really matter the adc channel it goes to?
manic glacierBOT
slender iron
@tulip sleet ping me if you have time to chat BLE some time today. I'm on a plane tomorrow and would love to wrap up the PRs today.
tulip sleet
@slender iron Sure! We're going out momentarily but will be back in a couple of hours or less. Will ping you not too long after that (have a phone call to make too).
slender iron
No worries. I'm around all day. Just wanted to make sure we checked in
idle owl
<@&356864093652516868> Here is the notes document for Mondayβs CircuitPython Weekly meeting. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and Iβll read them off during the meeting. Hope to see you there! https://docs.google.com/document/d/1dUDIH1vMwaufMwKyfNdI6StwcEDinveuXFtQSlLnVCk/edit
tulip sleet
5.0.0-alpha.5 in process... stay tuned
idle owl
stays tuned
tulip sleet
πΊ π»
orchid basinBOT
onyx hinge
thanks @tulip sleet !
tulip sleet
@slender iron The alpha.5 release is finished and will be in the blog in a few minutes. I will hold off merging the BLE PR's until sometime tomorrow after there is some smoke testing of alpha.5 (just in case we need an alpha.6).
slender iron
@tulip sleet sounds perfect! thanks!
indigo wedge
Congrats everyone on the new Alpha π
ionic elk
@slender iron sorry didn't mean to hit review request on PWM, still working on it.
solar whale
Congratulations on alpha5. Will be home tomorrow- looking forward to testing it and the new bleio....
slender iron
@ionic elk I'm about to head to the airport so Dan can finish the review
tulip sleet
@ionic elk are you ready for re-review or should I wait?
ionic elk
@tulip sleet still working on style improvements. I should have everything together by early afternoon, or we could just touch base tomorrow since I'll likely have some cleanup PRs in the works then too.
tulip sleet
sounds fine; please ping if you have any discussion points, etc.
ionic elk
@tulip sleet just wrapped up PWM, you can take a look now if you like or we can focus on it later
tulip sleet
i have to do some pre-meeting stuff, so may not finish review until later today
ionic elk
totally fine. You could also weigh in on the UART HAL vs register point Scott brought up in the UART PR when you have a minute.
ionic elk
@tulip sleet @meager fog going to run into a little bit of a problem with this:
../../shared-module/displayio/Display.c:116:13: error: too few arguments to function 'never_reset_pin_number'
never_reset_pin_number(backlight_pin->number);
Should I make microcontroller.c an official part of common-hal? Normally I count on any function not using the prefix as being port level.
onyx hinge
Today should be the last time that "my job" makes me miss the weekly discord meeting. π
idle owl
@onyx hinge π
<@&356864093652516868> Meeting in a little over an hour. Please add your Hug Reports and Status Updates to the notes doc even if you'll be attending - it's super helpful! https://docs.google.com/document/d/1dUDIH1vMwaufMwKyfNdI6StwcEDinveuXFtQSlLnVCk/edit#
Sorry for partial message send, that was unintentional.
fierce girder
It is at 11am Pacific?
idle owl
@fierce girder Yep!
fierce girder
Just got to Seattle. No longer in CET π
idle owl
Nice!
manic glacierBOT
errant grail
I'll be lurking today.
ivory yew
That goes for me as well. I'll be lurking until 11:30, then offline.
trim elm
Iβll be unavailable for this weeks meeting
gilded cradle
ok @trim elm
idle owl
<@&356864093652516868> Meeting starts in a few minutes
river quest
since we have 30 boosts the sound quality should even be better (384 Kbps)
sterile bronze
lurking
tidal kiln
** lurking ** (until in the weeds)
neat folio
just listening/lurking today
old smelt
I am having mic troubles of my own.. Going to drop and rejoin.
turbid radish
Hey Drew, say Hi to Helen for us
old smelt
Sorry! :0
wraith tiger
Just lurking
river quest
Yay! 30 boosts, we now have: +100 emojis for a total of 250, 384 Kbps audio, vanity URL, 100 mb uploads for all members.
CircuitPython 5.0.0 Alpha 5 released!
Lead story is more STM support!
https://blog.adafruit.com/2019/11/03/circuitpython-5-0-0-alpha-5-released/
Take Flight with Feather - Hackaday and Digi-Key:
https://hackaday.io/contest/168107-take-flight-with-feather
All 35 posts from Open hardware month in one spot (MicroPython and more included):
https://blog.adafruit.com/2019/10/31/all-35-posts-from-open-hardware-month-in-one-spot-ohm2019-oshwa-ohsummit-opensource-opensourcehardware-opensourceorg-adafruit/
"maintainable code is more important than clever code":
Python creator Guido van Rossum is retiring from DropBox, this is a great quote
https://blog.dropbox.com/topics/company/thank-you--guido
Snekboard - A Python Microcontroller for Lego:
https://www.crowdsupply.com/keith-packard/snekboard
Crowd funding and crowd sourcing trackers with PyPortals:
https://blog.adafruit.com/2019/10/31/tree-count-donation-display-with-pyportal-teamtrees-pyportal-dashblock-teamtreesofficl-dashblockhq-adafruit/
New boards! Now up to 86 boards!
https://circuitpython.org/downloads
SparkFun Qwiic Micro
ItsyBitsy NRF52840 Express
DRAFT, issues/PRs all welcome, ships out on Tues 11am ET:
https://github.com/adafruit/circuitpython-weekly-newsletter/blob/gh-pages/_drafts/2019-11-05-draft.md
Python for Microcontrollers
https://www.adafruitdaily.com/
ionic elk
@meager fog got a bin for u
onyx hinge
sed is a unix program for making changes to text files, like search & replace
ionic elk
@tulip sleet is there something else I have to link to get the board defaults to register? I'm having trouble getting it to recognize them as part of the module, seeing AttributeError: 'module' object has no attribute 'I2C'
old smelt
SedFu!
wraith tiger
sed = Stream EDitor
pastel panther
yeeees
tulip sleet
@ionic elk you mean board.I2C doesn't work? Did you add the last three lines to pins.c that you see in other board files?
tidal kiln
why use sed when you can use butterflies?
ionic elk
@tulip sleet that was it thanks for the heads up
I thought it was just mpboardconfig.h
turbid radish
Can a bird have 3 wings?
fierce girder
typed this in the wrong window:
hug report to @gilded cradle @timber mango @meager fog for feedback on https://github.com/adafruit/Adafruit_Blinka/pull/168
old smelt
An Old Timer I worked with years ago gave me this book as he transitioned into retirement. It's been a while since I pulled this from my bookshelf. π
onyx hinge
π€£
pastel panther
Here's a reasonable sed command to append "100" to the names of all the resistors so that you can shuffle the numbers around:
sed -i \.uncut -E "s/((name=|part=)\"R)([0-9]+\")/\1100\3/" FILENAME(S) HERE
A lot of sed-fu is actually regex-fu but useful in any case.
fierce girder
@idle owl for in the weeds, I'd like to ask about ithe generic linux PWMOut implementation:
https://github.com/adafruit/Adafruit_Blinka/blob/master/src/adafruit_blinka/microcontroller/generic_linux/sysfs_pwmout.py
@timber mango proposed abstract self._pin_path.format(self._pwmpin) as function - this way one could override it for boards where the /sys/class/pwm channel path is different like PocketBeagle/BeagleBone.
for example, generic needs:
pin_path = os.path.join(channel_path, self._pin_path.format(self._pwmpin))
but beagle needs:
pin_path = os.path.join(channel_path, self._pin_path.format(self._channel,self._pwmpin))
Making that a method that I could override seems like a good solution.
Does this sound like a good approach?
Details in this PR as to why the path is different on beagle:
https://github.com/adafruit/Adafruit_Blinka/pull/168#issue-332797708
pastel panther
and a much more unreasonably long "one liner" to change the names of the auto-broken-out nets for the caps and resistors to something more reasonable like R23_A and R23_B
gsed -i\.uncut -zE 's/(<signal name=")N\$[0-9]+(">\n<contactref element="([RC][0-9]+)" pad="1"\/>)/\1\3_A\2/g;s/(<signal name=")N\$[0-9]+(">\n<contactref element="([RC][0-9]+)" pad="2"\/>)/\1\3_B\2/g;s/(<net name=")N\$[0-9]+(" class="0">\n<segment>\n<pinref part="([RC][0-9]+)" gate="G\$1" pin="1"\/>)/\1\3_A\2/g;s/(<net name=")N\$[0-9]+(" class="0">\n<segment>\n<pinref part="([RC][0-9]+)" gate="G\$1" pin="2"\/>)/\1\3_B\2/g'
He will be a truely TAN newt...
pastel panther
lol
wraith tiger
Hopefully not a burnt newt.
gilded cradle
@fierce girder I'll add that to the notes
main meteor
That's a handy one: generally when I get to that level of detail, I reach for XSLT or Python, but I cheerfully admit that's using a big hammer for a small problem: the sed approach seems more appropriate.
old smelt
gilded cradle
Looks awesome
raven canopy
BGA. yummy.
tidal kiln
BGA
turbid radish
When you want please send me basic info and links and I'll add the board to Awesome Feather
And Awesome CircuitPython
main meteor
Alorium? The Arduino-on-an-FPGA people?
onyx hinge
how many I/Os ? I see those tiny castellations, I think?
tidal kiln
interesting castellation usage
main meteor
Feather footprint plus 32 more I/Os on the castellations, apparently. Nice.
raven canopy
amazing, indeed!
pastel panther
@old smelt Awesome!
old smelt
@pastel panther - Thanks! I'm very excited about it!
tidal kiln
** IN THE WEEDS **
is this a bug? or just the way it is?
Adafruit CircuitPython 4.1.0 on 2019-08-02; Adafruit Trinket M0 with samd21e18
>>> import os
>>> os.stat("/font5x8.bin")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: small int overflow
>>>
@tidal kiln that seems like a bug to me
tidal kiln
note it's a M0
onyx hinge
@tidal kiln in some places, the "zero time" was supposed to be 2000 instead of the standard unix 1970...
tulip sleet
onyx hinge
maybe that's not applied everywhere or it broke or something
[I had put an item in In The Weeds, but work just lept up and bit me and I have to go. It can surely wait.]
old smelt
Have to drop and head to a 2:00pm meeting. Have a great week, all!
fierce girder
for in the weeds, I'd like to ask about ithe generic linux PWMOut implementation:
https://github.com/adafruit/Adafruit_Blinka/blob/master/src/adafruit_blinka/microcontroller/generic_linux/sysfs_pwmout.py
@timber mango proposed abstract self._pin_path.format(self._pwmpin) as function - this way one could override it for boards where the /sys/class/pwm channel path is different like PocketBeagle/BeagleBone.
for example, generic needs:
pin_path = os.path.join(channel_path, self._pin_path.format(self._pwmpin))
but beagle needs:
pin_path = os.path.join(channel_path, self._pin_path.format(self._channel,self._pwmpin))
Making that a method that I could override seems like a good solution.
Does this sound like a good approach?
Details in this PR as to why the path is different on beagle:
https://github.com/adafruit/Adafruit_Blinka/pull/168#issue-332797708
tidal kiln
os.stat_result(st_mode=33188, st_ino=7876932, st_dev=234881026,
st_nlink=1, st_uid=501, st_gid=501, st_size=264, st_atime=1297230295,
st_mtime=1297230027, st_ctime=1297230027)
>>> os.stat('boot_out.txt')
(32768, 0, 0, 0, 0, 0, 126, 1480810702, 1480810702, 1480810702)
>>> hex(1480810702,)
access, modify and create iirc
tidal kiln
manic glacierBOT
old smelt
@main meteor - there are 34 castellated I/O, not 32. I misspoke.
ionic elk
@tulip sleet all my PRs are ready for review now, if you'd like to take a look
manic glacierBOT
tulip sleet
@ionic elk I had yet another meeting and now have to cook but I'll get back to this tonight
ionic elk
np! whenever you're free no rush. There's always other stuff for me to work on
manic glacierBOT
ionic elk
@meager fog do you know how fast a controller would need to be to run the SPI eyeballs? Or who might know that?
meager fog
which exact code are you refering to
ionic elk
https://www.adafruit.com/product/4343 "CircuitPython isn't quite fast enough to do the 3D animation techniques we use to draw the eyeballs" just curious how fast it'd need to be, and whether I could maybe hit that with a 168MHz F405
Just curious. Doing eyeball stuff on my own, wondering if that's something that could come up later on for the faster CPy mcus
meager fog
no you will not
perhaps a 500mhz cpu could do it in python
or with C math helpers
right now it maxes out the SAMD51 and we overclock it to 180mhz
ionic elk
Woof ok got it.
ivory yew
Hmmm just flashed new firmware to my board but can't get the CircuitPython drive to show up
Boot drive shows up fine and I can connect to the REPL
any ideas?
I thought I might have the wrong flash chip
old firmware works. Hrmp. I'm pretty sure I used the same flash config.
ivory yew
got it working
considering I just had to make a new flash device definition I'm curious how it ever worked lol
plucky flint
Hey hey... I was ill (head cold) yesterday so missed the weekly meeting. As a result I want to highlight what would've been my hug report -- it's for @gilded cradle for reporting a bug in CircUp and giving me a kick at the right moment when I'd made the wrong decision. Details here: https://github.com/adafruit/circup/issues/20
marble hornet
@slender iron did you see the new Positional-only parameters in 3.8? they seem right up displayio's alley (https://docs.python.org/3/whatsnew/3.8.html#positional-only-parameters)
simple pulsar
There was an issue with a change in behaviour for blocking with serial output on the new Circuit Playground Bluefruit. I thought this was Circuit Python at first but on probing it turned out to be Arduino-land: https://forums.adafruit.com/viewtopic.php?f=58&t=158213 - where should that issue be filed? Is this a known phenomena?
tulip sleet
@simple pulsar thanks! I replied in that thread
simple pulsar
np, would that potentially affect CircuitPython too?
tulip sleet
it could... but it depends on a lot of choices made in the code. Easiest just to test and see.
simple pulsar
I do have some bluefruits now so I may have a go later...
tulip sleet
thank you if you do end up testing it
onyx hinge
oops I gave away all my CPXes to interested coworkers
tulip sleet
@onyx hinge i order small batches regularly
ionic elk
@tulip sleet if you have a minute today could you take a look at the common hal changes I proposed in the DisplayIO PR? It's not ready for merge yet, since Ladyada is reporting some TFT issues, but I'm hoping to get input on the API layer edits I made
onyx hinge
π
tulip sleet
@ionic elk I just did a little reviewing but would prefer to wait for Scott's opinion on some of that. Could you merge that PR from upstream, because it will remove the PWMOut changes I see, I think.
manic glacierBOT
ionic elk
@tulip sleet what exactly is mphalport.c? Seems like leftover micropython API?
is there anything that actually uses it?
tulip sleet
the timing delay functions are defined in it, and they are definitely used. In MicroPython, there's some more functionality, like some clock stuff and misc functions.
ionic elk
@tulip sleet gotcha. It seems like it overlaps strongly with microcontroller __init__.c. Do you have a preference for where things are implemented? The atmel version seems a little mixed up on that point - us delay is implemented in mphalport.c and called by microcontroller, but the interrupt enable/disable functions are the other way around.
tulip sleet
it probably doesn't matter that much. I think the idea was that basic functions relevant to the microcontroller were in mphalport.c. They might be callable from Python or they might not. Stuff that is clearly callable from Python would be in in common-hal/microcontroller, but internal-only stuff would be in mphalport.c. But MicroPython doesn't even have common-hal, so it mixes these things up.
ionic elk
could/should that be cleaned up so that all of these internal functions are in common-hal/microcontroller? It'd get rid of one more file in the port root clutter zone
tulip sleet
you could see if there's code that we haven't written that calls things in mphalport.c, e.g. in py/...
ionic elk
Sure I'll look around
tulip sleet
that would be a reason to keep mphalport.{c,h} and not get rid of it
ionic elk
mp_hal_delay_us is used in drivers/ extmod/, shared-bindings/ and shared-module/. Mostly for i2c stuff. I'm not sure if those kinds of locations could be edited to use common-hal versions instead
Anyway not too important, it just seems like this mp themed stuff in the port root level could stand to be tidied up a bit or worked into the common-hal system somehow
tulip sleet
we have been trying to move stuff out of extmod into shared-*. However, we want to track fixes from upstream, so just deleting stuff from extmod/ makes it hard to track what changed. So when we merge from upstream, which doesn't happen very often, we can examine the merge and manually update our copied versions in shared-module (or whatever)
tulip sleet
@idle owl did we decide what to do with the cpx library wrt using it on cpb, specifically, the audio stuff? I think that would prevent it from being used directly.
idle owl
No we never decided. I want a separate library for CPB. Yes it can't be used directly at the moment.
tulip sleet
ok, I am just making up a hack demo and needed the Photocell code, so I just took it, and then i wondered what would eventually happen. tnx, that prevents further mind wandering
idle owl
Yw.
ivory yew
@tulip sleet close to getting a partial merge of just the native bits to compile. Gonna see if it runs.
So I might have been wrong. π
I really don't love their strategy here for this stuff.
They have h files that they use as "templates" in the c files and use a bunch of defines to turn on and off sections.
so the h files don't really behave like you expect.
I mean this isn't a totally unusual pattern but other projects I've encountered make it obvious. Like thing.template.c
ivory yew
compiled! Fingers crossed
well all seems okay, except I didn't actually enable the decorator.
oooooof nevermind.
I think I'm pretty close but there's some changes in compile.c that are pretty tricky
ivory yew
the bugs I've found do not inspire confidence in this code. π¦
tulip sleet
@ivory yew the code you're not confident in is the native code emitter stuff? π
ivory yew
yeah
mpy seems to build with much less strict warnings so a lot of easily spotted bugs get through.
tulip sleet
Scott set a policy early on of making all warnings errors so we would catch the maximum amount of stuff. I don't know eactly why Mpy didn't do that. MPy has tried to support varied toolchains so that may be one small reason, but in general it seems like a bad idea to not care about warnings.
we spend little to no time in this core code
lone sandalBOT
old smelt
@idle owl - working through your Git/GitHub guide. This is excellent. Thank you!
idle owl
@old smelt You're welcome! Thank you for letting me know π
old smelt
You're welcome. Step 1 of adding our new board to CP
old smelt
Will do. Thanks!
ionic elk
@tulip sleet @meager fog is there anything urgent you'd like done at the moment? I'm currently working on Β΅s delay and get core temp and then had meowbit/pyb_nano/blackpill support after that. Anything I should push up to the forefront?
tulip sleet
@ionic elk #2268 says it has merge conflicts now
you need us delay for neopixel_write, I think. I would say do neopixel before adding the other boards
ionic elk
@tulip sleet I'm trying to figure out why either of those merge conflicts came up
tulip sleet
i think you can bring in the arduino version with its tricky timing stuff mostly whoelsale, but see how things work in the atmel port to see how we don't freeze anything out. The nrf port is completely different: it uses SPI (which is eexpensive in terms of RAM) because no-interrupt tight timing code doesn't work with bluetooth running in the background
ionic elk
should I break temperature reading away from the us write?
tulip sleet
temp reading can be in microcontroller
ionic elk
I'm not sure what you mean with the arduino stuff. Are you referring to neopixel write or us delay?
Right now us delay and temp reading are a joint issue. I'm wondering if I should just submit my code for the us delay (very simple blocking loop) and then return to it for the temp readings after the neopixel module
tulip sleet
neopixel write. The atmel m4 code uses a NOP delay loop
what does temp reading have to do with delay? I'm confused
ionic elk
both are implemented in the microcontroller module
so I put them together
The issue is just "fill out microcontroller module" with all the stuff it's missing
tulip sleet
well, do the prerequisites for neopixel_write and then do that itself, because more customers will want that write away. So break up the to-do's if necessary
ionic elk
Cool, that's why I was asking. I'll submit a short PR for the us delay loop and then move on to neopixel
also, can you take a look at those merge conflicts? I'm trying to understand why they're conflicts at all
tulip sleet
i think the merge conflicts may be from the PR I just merged?
try merging from upstream again
ionic elk
When it's just outright updating stuff, why is it a merge conflict?
It's just adding text, there's no difference
tulip sleet
are you using separate branches for each PR?
ionic elk
yes
is that... not how you're supposed to do it
I'm sorry my git flow fu is not optimal
tulip sleet
no, that's right. if you change the same file in two diff PR's and merge one, then it can be confused because it's not sure which takes precedence
ionic elk
right my confusion is that the older files do not appear to be changed
<<<<<<< stm32-dac-deinit
#define BOARD_FLASH_SIZE (FLASH_SIZE - 0x4000)
=======
#define BOARD_FLASH_SIZE (FLASH_SIZE - 0x4000)
#define DEFAULT_I2C_BUS_SCL (&pin_PB06)
#define DEFAULT_I2C_BUS_SDA (&pin_PB07)
>>>>>>> master
like, what?
shouldn't that just be a cut and dry fast forward?
Anyway that's just me being puzzled obviously it's an easy fix but yea
tulip sleet
i agree and don't understand why it's confused
manic glacierBOT
ionic elk
the DAC auto shutoff? merging upstream reverted the defaults PR
I need to read up on Pro Git again
tulip sleet
ok, do git reset --hard HEAD~1 and git push -f, and tell me the branch name and I'll look at it
yeah, 2268 is DAC shutoff
ionic elk
it's fine I fixed it
it didn't revert that much
Should be ready to merge if you approve
tulip sleet
Sure, i will wait for the previous PR merge (#2266) to finish so I won't break the builds
old smelt
For the Express boards, does the UF2 bootloader itself require the 2MB SPI flash to be present?
tulip sleet
@old smelt no, it has no idea whether itβs there or not
old smelt
Ok.
That helps. Thanks @tulip sleet
We're bringing up the new board, and it's not enumerating as a USB device. UF2 bootloader loading process seems to be working without errors, but it doesn't enumerate. Just wanted to rule this out as a possible factor. Board doesn't have flash module on it yet.
manic glacierBOT
solar whale
@tulip sleet @slender iron Just a FYI and thank you! Started playing with new bleio and BLE examples -- so far so good!! the new central/periph demo and the color proximity demo are very nice! Using two CPBs at this time.
simple pulsar
I just got a bluefruit and my "trusty" Windows 8.1 desktop is spending a long time looking for drivers, i.e. device setup window saying Installing Adafruit Circuit Playground Blue (not a typo, perhaps there's a length limit here?) has been sitting there for several minutes. Is that to be expected?
Windows 10 worked in seconds with bluefruit and COM11 appeared for the board.
tulip sleet
@simple pulsar is it looking in Windows Update? The latest drivers package has it: https://github.com/adafruit/Adafruit_Windows_Drivers/releases/tag/2.4.0.0
@solar whale great! I have some fixes for use cases that aren't covered in the demos. It's a lot easier to define your own genuine BLE services now instead of using the UART Service and its packet protocol, and we're trying to move in that direction.
tulip sleet
@ionic elk I was waiting for the build to complete, but it was really slow yesterday. Thanks for merging
simple pulsar
@tulip sleet I'm not sure what it's up to. Good point, I'll install latest driver and see what it does. I actually have a Kitronik ARCADE doing the "same thing" but perhaps that's something to do with blockage from the former.
Adafruit CircuitPython 5.0.0-alpha.5 on 2019-11-04; Adafruit Circuit Playground Bluefruit with nRF52840 !
ionic elk
@tulip sleet we're just waiting on Scott for UART and DisplayIO right?
tulip sleet
def DisplayIO, not sure about UART, but if you were having a back and forth with him, it could wait. But I thought you were talking to Limor about UART interrupt handlers.
ionic elk
No UART's just waiting on what Scott's issue which I think he wanted input on, which was whether it'd be more readable to have the whole thing be register based instead of using the HAL. Limor tested the current system and it worked for her tests, it just probably needs non-blocking writes at some point for completeness.
My preference on the Scott issue was to keep it HAL based since that's what stm32duino uses and it'd be more consistent with the other work I've done in the port overall. But switching to register-level wouldn't be tough, I know how the guts work. It's really a style question.
tulip sleet
i'd leave it as HAL for now if it works, and move on to other stuff.
ionic elk
Ok. Do you want to chime in on the PR? I think Scott was looking for that kind of input
I think he was concerned about the read approach - it's based off Arduino and is much closer to NRF than the atmel version.
tulip sleet
i think he was concerned initially that getting the HAL version to work was very difficult, and that it might be easier with the register version, since you could manage your own interrupt routine that way. But you've worked around that, is my impression.
ionic elk
yeah it was kind of a pain in the butt I'd definitely start from the registers next time I do an interrupt system
Since Arduino did it this way and it seems to be working pretty well now, I'd rather keep it consistent for the moment. That's just me, you and Scott are the style/approach leaders here.
But I'd like to get UART merged asap, which is why I'm asking. Want to know if I should devote some time to switching over to registers and debugging that and stuff
tulip sleet
if it's satisfactory from limor's point view, let's just leave it for now. I'll finish reviewing for style.
ionic elk
Also, while I've got your attention, how close do we want delay_us to actually be? I'm looking at my SAMD51 control with a saleae and it's not exactly super precise. I'm looking at a 5us request (SPI bitbang delay) coming out to 21us between pin changes, and even a 1000us delay is 1769us in practice. For the really short ones I'd expect the actual pin write code is an additive but that 1ms delay seems weirdly off to me?
tulip sleet
the basic routine should be pretty accurate: if it's not, then it's a bug. it could be tested by using low level bit flipping to output something, or just remember the Systick or CYCCNT register before and afterthe delay call and see if the values make sense
the 1000us delay might have had a deferred interrupt handler run in between
btw, does the STM32F4 have an instruction/data cache for program execution, and is it turned on? we didnt' realize it wasn't turned on during SAMD51 development. When we did turn it on, we doubled CPy's speed
ionic elk
Hmmm I will look into that
I could also probably take some time here to do that bootloader thing
ionic elk
@tulip sleet I tried disabling interrupts for the 1000us count, and it just added 10us of execution time. It's 1778us total, almost twice what's expected
I'm going to switch over to my implementation now and see what that gives me.
tulip sleet
how are you testing this, from bitbangio.SPI?