I'm writing a series of articles on designing a microcontroller board (with an ATmega328P) from scratch [1]. It's a totally different experience from just breadboarding.
Some people are making NFC business cards, USB Hubs, and even smartwatches!
Nice, have you thought about doing the same but with a RP2040? JLCPCB have it as an extended part now, so you can have it done with their pcb assembly service. The memory adds another $0.50-$1, so overall it might be ~$1 or $2 more, but I know 328Ps were(are?) hard to come by during the chip shortage.
One of the huge advantages is having the builtin bootloader and USB phy and being able to run with micropython vs having to do stuff in C.
IIRC most of the 328P based boards typically use a separate WCH chip for USB.
I don't quite get the appeal of chips without WiFi or Bluetooth these days. I can't think of anything I want to do that wouldn't be cooler with connectivity.
Mostly what I do now is just make a carrier board for a USB-C ESP32 module. Yeah, I could probably do it myself (If I copied the reference design exactly for the RF stuff, and wasn't hand soldering QFNs!), but it becomes kind of a chore after the first time.
Maybe it's different if you're really good at soldering, I've heard it described as meditative for some, but I'm usually ready for a nap after that much precision work!
I wouldn't want a USB-based Picoprobe debugger or logic analyzer to depend on (or even use?) wireless connectivity. And for a low-latency game controller adapter which translates between wired NES/SNES, N64/GC, and/or USB protocols, converting a regular controller to a Bluetooth controller is quite an invasive change which requires adding batteries to the device, and increases input latency/unreliability when you're using a wireless connection, so many adapters don't bother with networking.
In terms of whether WiFi or Bluetooth is a wise idea (as opposed to being cool or useful), I find that wireless/networked protocols are easier to get wrong than simpler configuration. I have a video scaler (GBS-Control) which exposes a network-based interface over the ESP8266's Wi-Fi adapter. The IP address it picks up in my LAN is random, and though you can visit gbscontrol.local to resolve the URL using mDNS, this is unsupported on older versions of Android. And in certain video modes, the video circuitry interferes with the wireless signal, causing network requests to stall indefinitely.
In my observation, networking is especially prone to race conditions. If I toggle my power strip and power on both the ESP8266 and my router at the same time, the ESP8266 boots before the router, fails to connect to the router (remembered by PersWiFiManager), and decides to expose its own access point and never reconnect to the existing router afterwards. Worst of all, the web server used runs networking code in the yield() callback, leading it to handle network requests in the middle of I2C communication call stacks and possibly overflow the stack. It's also known to corrupt heap memory when concurrent HTTP requests occur (https://github.com/me-no-dev/ESPAsyncWebServer/issues/324 was closed by a bot without a solution). I found an concurrency footgun where the server allows HTTP callbacks to ask the server to reply with a SPIFFS file handle, but you can reopen and write to the file in subsequent code after the HTTP callback finishes, but before the server finishes streaming data from the file handle. This results in corrupted data being sent to the HTTP client.
I also heard that the Pinecil V2 released with a Bluetooth Low Energy compatible microcontroller, but the wireless-enabled firmware apparently malfunctions on certain irons and causes them to fail to boot (https://github.com/Ralim/IronOS/issues/1661), though this may be fixed over time.
Pinecil is one of the few things I'm kind of Meh on the Bluetooth part, once they added USB-PD and safety auto shutoff, it seems like there's not much to add that wouldn't cost money or size.
I wouldn't mind a wireless logic analyzer, if it had good battery life. Being able to use it on a tablet easily while charging without dongles so you had a second screen could be cool.
For a game controller adapter, I'd definitely prefer Bluetooth, because the performance is good enough for a casual gamer and it's pretty convenient. It doesn't necessarily even have to involve batteries, BLE is still useful with wired power, if your device doesn't have a lot of ports and you've got more spare chargers than spare hubs.
Android should have supported mDNS like, 10 years ago, but slowly we are getting to a saner place.
Network programming definitely is 10x harder than non-network programming. It absolutely will screw up and ruin your day if you don't assume all packets can be lost, all connections can be dropped, IP addresses can change, MACs can change, there can be 500ms of latency for no reason, you can get requests from multiple devices, connections can be closed uncleanly, devices can show up in any order, other devices can mysteriously forget connection info, IP conflicts absolutely will happen if you have manual static IPs and aren't really careful, there will be random code in frameworks to hammer flash memory caching credentials on every boot in Arduino, etc. But hey, it's still easier than soldering and 0603!
A lot of problems for anything remotely hobby level can be solved with heavy handed locks though. Like, don't touch the filesystem except under a lock, and use the same lock for everything, and hold the lock for the whole HTTP request, and only try to get more clever in specific places that need it. It might really suck and be slow, but at least it might be correct.
Network is a lot of hassle but it's also a lot of potential. Especially for configuration and debugging where it's ok if it's not 100% reliable, and for things that inherently tolerate a bit of loss, like telemetry.
Depends on use case, for me at least, I have used RP2040s as secondary microcontrollers for something like a CM4, where I want something that is closer to real time, or if it is a control loop.
Yes absolutely! I love the RP2040 and have used dev boards for several projects.
My goal with this intro is to make something hand-solderable though, which is why I'm using QFP32, 0805, etc. In addition, this is Arduino Nano compatible to ease the transition. I'm using a CH340N for USB. An unfortunate consequence of this is that you need another MCU board to flash the bootloader first.
TBH ATmega328Ps are surprisingly expensive ($2.x) for their functionality.
Especially with the smartwatch, we are considering using an ESP32 WROOM/MINI module and will write about that too, eventually.
You should look at atiny10s too, they have a 6 pin and through hole version and you can use them without a crystal.
I have thought about making a design for one and doing a series where we make an assembler in python, where it's an exercise in writing a parser to output the binary assembly for use in a simple micro like the atiny. They have limited registers and instruction set, so would be a good way to help people understand what is happening.
Having WebPush style push notifications is a huge advantage of JMAP. Right now, 3rd party mobile email clients are stuck to polling every few minutes or keeping a connection open.
I'm looking forward to more JMAP adoption, especially on FOSS Android platforms.
The _Fastmail app_, which one might assume is the flagship client, doesn’t work at all offline. So I’m unimpressed. Every other non-Webmail client I’ve ever used, whether POP3, IMAP, Exchange, or proprietary, worked at least to a reasonable extent offline.
Which is also exactly what the colleges are saying themselves (on the surface). For example, MIT's rejection letter:
> Please understand that this is in no way a judgment of you as a student or as a person, since our decision has more to do with the applicant pool than anything else—many of our applicants are not offered admission simply because we don’t have enough space in our entering class.
Tangent:
My gas station replaced grade-selection buttons and rate/volume/price LCDs with one huge (20") touchscreen. Unfortunately because of the distance, it's brighter than the overhead lights at night. No one thought to add a little brightness sensor to the several thousand dollar machine.
Tangent off your tangent: Do you have one hose at each pump at your gas station and you just select which grade of fuel you want? I've never seen that before. In the UK they have multiple hoses, and you choose which one by picking up the right hose.
Not the commenter you asked, but in the United States pumps with one hose are common. All the grades of petrol are dispensed through the same hose, and you just select which one you want.
Some pumps do have two (or more) hoses, especially those that have multiple types of fuel (one for regular petrol, and one for diesel). Some pumps for also have separate hoses for each grade, although they seem less common to me.
> small CR2032 coin cells (which have ~10 to ~100 ohms of internal resistance). A ~100mA draw on the charge inductor isn't out of the question (at 10-ohms, that's a voltage drop of 1V, which probably browns-out the RP2040).
n=1, but I'm using a single CR2032 with a Badger 2040 (same as OP) and a DS3231 in parallel and it works just fine down to ~2.8 volts.
By the way, for the e-ink project I just linked in the other comment I ended up discovering the RV-3028-C7 RTC module. Idle power draw 45 nA at 3.3V instead of 110 μA for the DS3231 for similar functionality and ±1 ppm accuracy with an internally sealed oscillator. Awesome for battery-powered stuff and cheaper at low qty on Digikey.
I hope more of those little DIY/maker breakout boards adopt it. Pimoroni sells one. The one in my project is a free sample dev board that Micro Crystal sent me on request - which I guess is working out for them considering I just shared their product with you all.
It is kinda weird. However, at the end of the day, UnifiedPush is just a protocol that allows $heavyProtocolA to receive notifications through $lightProtocolB.
And XMPP is just $lightProtocolB, there is nothing stopping an XMPP-based UnifiedPush distributor w/o messaging from existing. If you don't use XMPP for messaging, there are many simpler distributors available.
Is it really about light vs. heavy though? I thought it was mostly about multiplexing notifications through a single app (usually through a single connection as well), so only one app has to consume resources constantly, and others might be activated as needed.
It's a little bit of both. You want to only keep one connection open as it minimizes the amount of network activity for e.g. keepalives. You also don't want the app holding that connection open to drain the battery in the process though.
/s I hate how they're scaremongering with the vague term "Forever Chemicals" instead of just using the more specific terms PFAS or Microplastics.