That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.
A very small point, but pulling from a feather form factor BOM to compare.
$0.12 for microUSB female connector (rated 1A)
$0.26 for a USB-C female (rated 3A). Needs 2 x resistors (< $0.01), 20% larger board area
I think the power capabilities are the biggest item. If you want to pull higher current from a laptop for development or supply from a wall, you have to switch to USB-C.
I don't think either of these prices are that aggressive - pretty sure the cost comes down at volume.
I did listen to this for over 2 mins as I task switched over and eventually got cross enough to go back and terminate - I then went to YouTube to play said song and wondered if this was in fact an advertising strategy of the AI and I was the rube...
I loved this article and had wanted to play with PIO for a long time (or at least, learn from it through playing!).
One thing jumped out here - I assumed CISC inside PIO had a mental model of "one instruction by cycle" and thus it was pretty easy to reason about the underlying machine (including any delay slots etc...).
For this RISC model using C, we are now reasoning about compiled code which has a somewhat variable instruction timing (1-3 cycles) and that introduces an uncertainty - the compiler and understanding its implementation.
I think this means that the PIO is timing-first, as timing == waveform where BIO is clarity-first with C as the expression and then explicit hardware synchronization.
I like both models! I am wondering about the quantum delays however that are being used to set the deadlines - here, human derived wait delays are utilized knowledge of the compiled instructions to set the timing.
Might there not be a model of 'preparing the next hardware transaction' and then 'waiting for an external synchronization' such as an external signal or internal clock, so we don't need to count the instruction cycles so precisely. On the external signal side, I guess the instruction is 'wait for GPIO change' or something, so the value is immediately ready (int i = GPIO_read_wait_high(23) or something) and the external one is doing the same, but synchronizing (GPIO_write_wait_clock( 24, CLOCK_DEF)) as an alternative to the explicit quantum delays.
This might be a shadow register / latch model in more generic terms - prep the work in shadow, latch/commit on trigger.
(caveat - not a lawyer... but I'll share my opinion)
That list in 1.1 isn’t an exhaustive definition which is IMO, one of the causes of the fire. Again, "IMO", the list is an illustrative set of examples as there is no limiting language like "solely" or "only" and the clause even mixes services and purposes, which again signals it’s descriptive rather than definitive.
Saying that, whilst the list inside the definition of "the Platform" is illustrative, the category it defines seems scoped to Arduino-hosted online properties which could be argued is the intent. But its an argument alas...
Either way, ambiguous policy is being communicated by these T+C updates and that is a real problem.
Poking around at this product, it looks from the rendering like (a) USB-C based power pass through (unclear if its 2.0 BC etc... or true PD with CC pins - doesn't matter that much however if the phone range is small enough) (b) USB 2.0 device IC (STM32 or similar?) that connects to the phone over D+/D- pins. (c) power is being taken from the USB internal or external depending on what is plugged in.
I was confused by how CarPlay was working, as this requires the vehicle to be a host and the phone a device, but I'll assume it means wireless CarPlay (vs USB 2.0 CarPlay).
For the display, I wonder if the device is mimicking the assistive touch inputs via external USB PID (per the note) and using a mouse/trackpad HID can take a screenshot via assistive framework - I guess the app could see this arriving, process it and then delete? Also figure out what is being shown? would explain why the video is sped up a little, but YIKES. Also good luck stopping the app being killed in the background.
All direct USB streams require MFI auth, which might work for exactly 100 devices and could be an alternative, but requires Apple cert for bulk quantities.
I think ReplayKit can only work within an app and can't see the general output stream.
Cool use of tech and curious to see how it actually works :)
That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.
I'll peek at the code out of interest :)