Not an electrical engineer, but I was 2 sentences in when I declared to myself "its the external clock source" and then a physical shudder as I remembered how many times a contract manufacturer has used some aging crystal or third party component src and not updated the matching capacitors, causing very similar issues on projects I've worked on in the past. The very very worst is the aging xtals - a warm wind can make them work for an undetermined amount of time, which is bad if the factory is running warm around 26C or so and you end up shipping the batch to Europe where its early winter...
250k is not a bad investment for a company doing "reverse engineering as a service" - say 1k a pop to extract the firmware. Naturally, a good business idea for somewhere in the world with less regulations...
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 wonder if it would be worthwhile for them to produce both. Well, it will be hard to compare because the design cost doesn’t show up in the BOM, haha.
But it seems like it would be useful nowadays, since some laptop have mostly USB-C connectors, and USB-C to USB-C is pretty common. I’ve never seen a C to Micro. Do they even exist?
I have an unfair bias because I design PCBs as a significant part of my job, and switching out to USB on this board appears to be a non-issue.
I have a Pico in front of me, and there's plenty of room there for a USB-C footprint and the two 5.1k resistors. Given that, I cannot reasonably agree that the "design" stage is significant.
In other words, it's a change that I would make to my own board in 2-5 minutes because the stakes are low. My ballpark guess is that such a change at RPi would have to go through a proposal stage, a PCB change review, and then there would be dozens of places to update documentation.
Since backwards compatibility is non-optional, this would result in a separate SKU, which means that the whole distribution chain needs to be updated with a new product.
So, I acknowledge that when you're working at their scale any change like this is the definition of non-trivial. What I don't agree with is the conclusion that it's not still clearly the right thing to do.
Comparing an RP2350 to the ESP32 family (which is broad) is very much apples to oranges; they each have feature sets which make them ideal for completely different use cases.
I just got ESP32 C6 on a custom board, with micro python it pretty much made all RPi's obsolete for a quarter of price for I2C, GPIO, UART, SPI communication while having WiFi 6 and BLE.
There is no more use case for RPi if I can have ESP32 C6 for $10 - maybe I have to do some soldering on my own.
Then if I need a minicomputer I'd rather go with MinisForum PC that is in price range of RPi and if I need I2C or GPIO I can pair it with ESP32 like as many as I want ESP32 instead of single one like RPi. Then communicate over wireless as much as I want with BLE or WiFi.
Also, could you confirm that the RP2350 consumes 2-3x less power when idling?
If you have the contact details for any certification labs that don't charge extra for radio modules even if you're not using them in your product, that'd be super helpful as well.
It's not a question of "unnecessary". You just don't like it when someone points out that you're making shallow statements and you don't even realize it.
When you frame two MCUs intended for different purposes as competition, you're completely missing why there are so many different useful MCU families in the first place.
If you need a programmable IO state machine (or twelve) then you need the RP2350, period. It's a feature that enables entire domains of functionality that wouldn't otherwise be possible. For example, I'm using it to perform a real-time 12 output MIDI THRU that doesn't tax the CPU cores. Nothing like that exists on the ESP32 family.
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.
The idea of the wait-to-quantum register is that it gets you out of cycle-counting hell at the expense of sacrificing a few cycles as rounding errors. But yes, for maximum performance you would be back to cycle counting.
That being said - one nice thing about the BIO being open source is you can run the verilog design in Verilator. The simulation shows exactly how many cycles are being used, and for what. So for very tight situations, the open source RTL nature of the design opens up a new set of tools that were previously unavailable to coders. You can see an example of what it looks like here: https://baochip.github.io/baochip-1x/ch00-00-rtl-overview.ht...
Of course, there's a learning curve to all new tools, and Verilator has a pretty steep curve in particular. But, I hope people give the Verilator simulations a try. It's kind of neat just to be able to poke around inside a CPU and see what it's thinking!
Correct, actually most programs I've written for the BIO are in assembly.
The C compiler support is a relatively recent addition, mostly to showcase the possibilities of doing high-level protocol offloading into the BIO, and the tooling benefits of sticking with a "standard" instruction set.
(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 :)
I don't know about anyone else, but when transitioning back to a shell, I HAVE to hit a bunch of enters on any prompt to clear the last output away a few lines before I can summon up the powers to enter a new command - blow away the cobwebs and all that. I love the empty enter command line :)
