It turns out that when the outcome is a myriad of chinese cheap clones, the authors realize actions are needed to actuall make any money from their work.
That's 84 requests blocked (54% of the page, 14 domains blocked out of 16)
To do this, in Advanced User mode, under 3rd Party Scripts and 3rd Party Frames, click the left-most cell pair to make them red. (right-most pair is settings for the current site only, left-most pair is for every single site, ie default settings)
lol, and fake animated popup alerts telling you what other customers are buying right now? Is this really a site for savvy electronics hobbyists? It feels like the crappiest web2.0 "seize them by the eyeballs and don't let go" garbage site possible.
Absolute horror! Auto-playing video with sound on by default, hundreds of requests to remote servers (Google Play, Youtube, AdSense, some unknown domain, ...).
I respect Arduino for what they have done for the maker and tinkerer scene, but landing pages like that will not keep me as a visitor.
It's neat that they've added a Qwiic-compatible connector. I've been impressed with how many Qwiic peripherals Sparkfun has released, so I'm glad to see it getting more traction.
On the other hand, it is a really convenient standard connector.
On the other hand, I2C means you can only have one of each kind of device due to address clashes, the lack of an interrupt pin is quite limiting, I2C is too slow for things like displays, and 3V3 isn't really enough to power LEDs like WS2812Bs.
I love the Qwiic idea, I'm glad we are finally getting some standardization (Although, as a complexity addict I probably would have preferred a fifth 5v to 28v unregulated bus pin or something).
What I don't like is that the connector is a nightmare to hand solder and isn't as strong as some. But then, I suppose that's what breakout boards are for.
There's a few other use cases that can't be done easily in a modular way unfortunately, mostly to do with power. SPI needs more pins, and there's no way to handle 12v, and only one module can be supplying power.
Stuff is not quite fully plug and play yet although it would be super cool.
I'm wondering what's appealing about this size board? I'm interested in portable devices so I prefer smaller. Arduino's boards seem awkwardly big and expensive compared to a Raspberry Pi Pico, Adafruit's Feather boards, or a Teensy for more processing power.
The UNO predates the Pi Pico by about 20 years. It was pretty small for everything it did back then. The headers are laid out in a standard format so that it can accept "shields", so now anything that wants to use those shields has to be this size.
The first Arduinos with that formfactor which supports shields are from around 2005[0]. The Uno wasn't the first[1], it was just a model line set up for that specific formfactor for consistency, since the name was changing frequently (e.g. "Arduino Diecimila", "Arduino Duemilanove", etc).
If you're not interested in shields, I don't think there's any reason to use any type of Arduino today. There are smaller Arduino boards that don't support the same shields for people that want something smaller. But, today, the ESP* boards are way, way better. And, as you mentioned, some of them have shields too (though not anywhere near as many as the UNO).
I like the feather format a lot as well and Arduino makes some in that shape (and smaller) but having taught a number of beginner's classes with Arduinos at my hackerspace, I think the Uno format is a bit friendlier for novices. Having a wifi/bluetooth enabled board in that shape is great.
It's easier to see what you're doing and plug a rats next of wires into the bigger board without it falling over, and everyone's got to start somewhere! Uno format Arduinos are a learning tool first and foremost and they do that job really well.
According to [1], the decision to keep the spacing for compatibility reasons was a conscious one. I can see how they might want to keep the whole ecosystem of Arduino-compatible accessories/kits/etc functioning.
Being physically bigger makes it easier to work with, as there's just more room for everything. The smaller Pro Micro/Pi Pico/Feather/Teensy form factor is just a bit too cramped for prototyping.
Backwards compatibility. Plus you can power it with anything between 6 and 24V, use a coaxial connector and the header is big enough to attach just about any prototyping board or extension. We yse the same header on our own ESP32 extension board, but replaced the coax connector with something more industrial friendly.
Now it also runs Micropython, so we don't have to bother compiling code, you just push it over UART and run it.
Another big shift is going to happen when these boards shall be able to run Node Red. Siemens PLCs now run Node Red. I don't like it, but many engineering professionals have a better experience using block programmingand get stuff done even if it's a waste of resources.
They have the maker devices if you want a smaller board, but it's rather expensive compared to the alternatives.
Feather seems like a great choice for boards of this class.
From the Arduino Uno R4 FAQ…
> “the Arduino UNO R4 WiFi was specifically designed to ensure compatibility with previous shields and compatible hardware developed for the Arduino UNO R3. The UNO R4 WiFi maintains the same mechanical and electrical compatibility, allowing you to seamlessly use your existing shields and hardware with the new board. This makes it easy to upgrade to the UNO R4 WiFi without the need for significant changes or adaptations to your projects.”
In addition to physical compatibility, maintaining the GPIO pin layout means software libraries created for earlier Arduinos should continue to work. For example, an interface library for a sensor or actuator that’s reused project to project.
I really like most of this. But why is there a monochrome LED matrix???
It's cool, but very much tied to one specific pixel art style and not visible in a lot of applications. I'd rather they just make an official I2C TFT you can mount wherever.
Although I suppose it's a cool novelty that will probably lead to a lot of fun stuff that wouldn't otherwise happen.
I would have preferred a tiny OLED though, those seem to be cheap.
I'm also disappointed that there's no USB-PD. It can take 20V of power, it should be able to request 20v of power from the port for powering motors and stuff with just the one convenient connection.
There's also a VBAT for the RTC on a little connector that also includes an off switch button. A nice feature but it needs a coin cell to use. I wonder if they could have done a rechargable battery instead.
They would have needed a nanopower regulator to get to a proper VBAT, and a charge IC, so it might have added a dollar though.
(You might get a free CGNATed IPv4 as well, but the point of v6 really is not to have to.)
Even with both one might decide only to use the v6 uplink. There's not really (ordinarily) a good reason not to - you can still use v4 locally if it's more familiar/easier to firewall or whatever, and unlike a v4 that you haven't paid extra for, the v6 is almost certainly static - which is either a huge benefit, or you don't care either way.
- x86 and x64 are too power-hungry for small systems.
- Power is still up and running, but also on the high end, too (see Power 8 and 9).
- MIPS32 cores are found in lower-end MCUs. AFIACT MIPS actively offers their cores for embedding in MCUs, like ARM.
- You can still buy MCUs with Atmel AVR and 8051 8-bit architectures on the lowest end.
What's lost? SPARC and Motorola 680x0, I presume. I frankly wonder what prevented 680x0 from getting into widespread MCUs. Apparently Phillips used it their custom controllers for some time.
> AFIACT MIPS actively offers their cores for embedding in MCUs, like ARM.
Not anymore that I'm aware of. They laid off most (possibly all?) of their architectural engineers around 2020 and sold off the remaining rights to a Chinese firm.
There's still a few MIPS-based MCUs out there, like PIC32, but they're a dying breed. ARM Cortex-M is much better suited to these applications.
> I frankly wonder what prevented 680x0 from getting into widespread MCUs.
Poor IPC, high interrupt latency. The weird mixed 16/32-bit nature of the 68000 made it easier to implement a microcomputer with (since you only needed 16-bit RAM/ROM), but would only get in the way in a microcontroller (where memory would mostly, if not entirely, be internal). It's a shame; I liked the ISA, but the performance just isn't there.
I almost did a prank post when Apple came out with/announced the M1. I had recently had tore down my broken PSVR which has the very nicely stamped ARM M1 in it. I wanted to post something like "Apple didn't invent it, Sony did!" Regretfully, I did not.
> I had recently had tore down my broken PSVR which has the very nicely stamped ARM M1 in it.
I don't think that's correct. The Cortex-M1 is an soft-core-only design; there's no hardware implementation. (And moreover, the ARM cores used aren't usually part of the external markings on a chip.)
8-bit PICs are still quite nice. All of them up to 40-pin variants are made in DIP package, so I can put a bare package into a breadboard and have a ton of features out of the box in the right pin number configuration for the job.
People should just select modern ones, and not the same old 16F84/877 or something legacy like that, that's been obsolete for like 25 years already. All of the modern ones have very uniform programming interface, nicely configurable I/O and a lot of analog features.
PIC used to have a terrible architecture, and was barely supported by open source tooling. Heck, GCC still doesn't have PIC support, and an experimental backend was dropped from LLVM! I'm not surprised AVR ate its lunch in the hobbyist space.
As an instruction set, yes, but I think this was inevitable with the demand for things like native USB, Wi-Fi, Bluetooth, and hobbyists wanting to use languages like Python. These boards do a lot more than the ATMegas I grew up with, and while almost every new design in this space might go with ARM thanks to generous specs and low cost and power requirements, I think there's still a good amount of competition in the 32bit microcontroller market (ST, TI, Microchip, NXP, etc. come to mind).
Is this hardware change going to make grokking the underlying hardware schematics and instruction set significantly harder compared to the older AVR version? Few years ago, when learning electronics, I was going through UNO3 schematics and AVR instruction manual and it did not take too much effort for them to make sense.
Or perhaps I am not a target audience of this hardware change.
AVR is still reasonably easy to understand and manually bit-twiddle, but virtually all ARM cores are way too complicated for that. It is essentially required to use a SDK to handle all the gory details for you.
Unless you plan to kill USB, 5V support is kind of baked into modern computing.
EDIT: And 8-bit can't seem to die no matter how much people try. TI's MSPM0 (Cortex M0+) chips at 39-cents this year (1k quantities) might give 8-bitters a run for their money finally though. But time-and-time again, 8-bit survives each challenge. I dunno why, it just keeps happening.
It's a bit different, and sure the Pico audience is slightly more advanced, but there are way more similarities than differences. They are absolutely in competition.
Arudino Uno has _always_ been primarily about being super simple for beginners. This is why the Arduino IDE exists (and why many more advanced hobbyists eschew it). This is also why the Arduino Uno can be used without breadboard. And why Arduino shields exist, so you can add on the Unos in plug-and-play kind of fashion, for beginners. I believe a secondary design goal is to still be useful past the beginner stage (which is where comparison with a Pico comes in), but that's not the _primary_ goal.
In contrast, Pico is far more complicated for beginners, since it's not designed for that purpose. You need a breadboard in order to use it with anything else. And the toolchain is _far_ more complex for beginners! Hell, I had some issues setting up the Pico toolchain on my Mac (and I'm not a beginner), whereas with the Arduino, it was just "get the Arduino IDE". Yes, you can use the Arduino IDE with a Pico now, but that wasn't that way from the beginning, and the fact that you can do so now is A) not because Raspberry Pi released any official method and B) because the Arduino IDE exists in the first place specifically to support Arduinos.
In short, as I said before, they are different products with different audiences, and therefore different design goals.
I could be wrong with this new Uno, but the biggest difference between a pico and uno (traditionally) was that the USB firmware in the uno could allow you to emulate mice/joysticks. That's huge if you're building simpits, or human interface prototypes.
The RP2040 used by the Pi Pico has native USB support, so using it for HID devices is fairly trivial.
The previous Uno was a bit of a pain because it had two MCUs, with one essentially just acting as a USB interface to the other. The new Uno has the USB pins muxed both directly the MCU and the onboard ESP32, so that should be easier to work with.
[1] https://files.littlebird.com.au/Shared-Image-2023-06-28-08-0...