Do you own a LightBlue Bean or Bean+ from Punch Through? If you don’t have one now, you probably never will, as the company has recently announced they’re no longer selling or supporting the Bluetooth Low Energy microcontrollers. The company says that after selling more than 100,000 Bean devices, the challenge of keeping up with a constantly evolving software ecosystem became too difficult, and they are instead going to focus their efforts on advising other companies on how to best develop Bluetooth products.
Frankly, that sounds a bit like getting advice on how to build a fully armed and operational battle station from the Empire, but who are we to judge. While the Bean family of devices clearly wasn’t able to go the distance, Punch Through at least got them out the door and supported them for longer than many might have expected given the increased competition in the BLE market. It’s not hard to do the math: the LightBlue Bean retailed for around $35 USD, and today you can get a BLE-capable ESP32 for five bucks.
So what happens to all those Beans out in the wild? Normally, the parent company dropping support for a microcontroller wouldn’t be that big of a deal, but this time around we have the “Bean Loader” to contend with. This piece of software is used to push code to the device over Bluetooth, and it’s possible that the constant march of operating system upgrades (especially on mobile devices) will eventually break it. Long story short, there’s nothing to worry about in the short term. But down the road, these Beans might be baked.
Luckily, Punch Through did provide some pretty extensive documentation for the Beans. If there’s significant demand, we imagine the community will do their best to take over development of whatever ancillary software is required to keep the hardware usable for the foreseeable future. Speaking of which, the schematics and PCB layouts for both the Bean and Bean+ have been released under the Creative Commons Attribution 4.0 International license, so it’s not outside the realm of possibility that somebody else might put them back into production.
[Thanks to Chris for the tip.]
Of all the things which are annoying about the modern World Wide Web, the need to create and remember countless passwords is on the top of most people’s lists. From dozens of passwords for everything from social media sites to shopping, company, and productivity-related platforms like Github, a large part of our day is spent dealing with passwords.
While one can totally use a password manager to streamline the process, this does not absolve you from having to maintain this list and ensure you never lose access to it, while simultaneously making sure credentials for the password manager are never compromised. The promise of password-less methods of authentication is that of a world where one’s identity is proven without hassle, and cannot ever be stolen, because it relies on biometrics and hardware tokens instead of an easily copied password.
The FIDO2 project promises Web Authentication that means never entering a password into a website again. But like everything, it comes with some strings attached. In this article, we’ll take a look at how FIDO2 plans to work and how that contrasts with the state of security in general.
Continue reading “FIDO2: The Dream Of Password-Free Authentication On The WWW”
Writing image data to serially connected (SPI/I2C) displays from a microcontroller is easy enough these days, courtesy of standards defined by the MIPI Alliance, yet there are some gotchas in it which may catch someone using it unaware. [Larry Bank] wrote up a good summary of how one can get maximum performance out of such a display link.
At the core is the distinction between pixel data and command transmissions. The change from command to pixel data mode requires signaling, which takes precious clock cycles away from transferring pixel data between the MCU and display. The common MIPI DCS instruction set allows for a big reduction in needed data transfers by allowing parts of the display to be addressed instead of requiring a full refresh. Yet by not properly segmenting command and data transfers, one ends up unnecessarily slowing down the process.
The result is that one can run something like a Pac-Man emulator on an AVR MCU with a sluggish 320×480 SPI LCD at 60 FPS, as one can see in the video that is embedded after the break. Check the article for another demo video as well.
Continue reading “Speeding Up Drawing To MCU-Connected Serial Displays”
Back in the early dawn of the GUI age, cathode ray tubes were the dominant display technology for the personal computer. In order to avoid burn-in of static display elements, screensavers were devised to help prevent this problem. Out of love for the software of yesteryear, [Greg Kennedy] has put together a bot that posts Windows 3.1 screensavers on Twitter.
A Perl script runs the show in this case. Screensavers are packed into “units”, which are loaded by the script. A basic Windows 3.1 environment is then configured, and loaded into a specially patched DOSBOX that allows automated demo recording in a headless environment. Once up and running, video is recorded of the desktop and subsequent triggering of the screensaver. After a couple of minutes, the recording is stopped, and FFMPEG is used to transcode the video into a Twitter-suitable format. It’s then a simple job of Tweeting the video using the standard API.
It’s a fun project that makes sharing old screensavers easy. Be sure to check out the Twitter feed @dot_scr. If you’re addicted to the vintage aesthetic, try this Apple ][ screensaver hack on your Linux boxen. Video after the break.
Continue reading “Windows 3.1 Screensavers, Now On Twitter”