Doom Running on an IKEA Lamp [video]
youtube.com
youtube.com
This perspective makes scifi stuff like "smart dust" seem a lot more feasible. Ubiquitous computing, what will it bring us?
These are around 20 MIPS. The Apollo guidence computer had around 1 MIPS.
It seems likely they are using something similar. It's difficult to find a cheaper chip, broadly available chip these days.
You can find Z80 clones, but even they are generally upgraded and therefore more powerful than the Apollo computer.
Do people really think the Apollo computer is more powerful? And have any evidence? I'd be surprised if you can get a microcontroller with as little processing power these days.
Music cards use dedicated chips, they are not general purpose, and they don’t really do much computation aside from a few counters. AFAIK.
Now, in DIY tutorials they show microcontrollers, because they are easier to obtain, but it doesn’t mean that they are used in the commercial products.
The cheapest, smallest (15s storage) "chip corder" (which is what these cards use) has GPIO, SPI, the ability to trigger different messages etc. There's no way this is under 12,000 transistors![2]
[1] https://en.wikipedia.org/wiki/Transistor_count#Transistor_co...
[2] https://www.datasheets.com/en/part-details/isd2115ayyi-nuvot...
Ads, obviously.
Ads, propaganda and surveillance.
I believe it is creeping back in now. But it can be done.
The main adversary will be the cookie monster.
https://en.wikipedia.org/wiki/The_Game_(Star_Trek%3A_The_Nex...
I do enjoy Dark sci-fi also every now and then but I generally like my heroes to be scientists, explorers, to solve ethical questions.
(Yes, Discovery season 3 is a thing I know about.)
The only thing more disturbing and sad about this is how much consumer demand there is and will be for deception, misinformation, and manipulation.
Mine don't, and I first owned an AtariST with a 68000 CPU.
These are "smart bulbs". We are still in the .com bubble of IoT, so there are going to be a lot of silly things we can run Doom on for a while until it dies down. Lights don't need computers to operate, but that doesn't stop people trying to add "features" to lights with computers.
Empirically it seems that software simply doesn't scale as well as hardware does. I feel like this overhead would make "smart dust" impractical.
Or I guess I could put it that way: one hand hand you could be impressed that a modern light bulb can run Doom, on the other you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
So the RoI is just different.
The trick is that you probably don't need all, or even most, of that power to run the light. Sure the Zigbee protocol is _probably_ being done via software, and not a dedicated chip, but even then. The big thing is that this chip is most likely so cheap, especially in bulk, that it doesn't make sense to get the "cheaper" variant, even if that was still available. This is kind of supported by the "new" Trådfri having an updated chip, even though the Trådfri line never changed it's capabilities, it was probably cheaper to get the new more powerful chip and/or they could no longer get the old one with a five year supply guarantee.
If you're intentionally disabling functionality in order to sell at a lower cost, you're not actually saving any money because you still have to manufacture the thing. It also (I assume) opens up a risk to someone finding out how to "jailbreak" the extra cores and now you can buy an i7 for the price of an i3. Is the cost of having three different manufacturing processes so large that it's not worth switching? Is the extra revenue from having three different versions of the same physical chip enough to justify the jailbreak risk?
If you just have one price, you cut out people who can't afford it and people who can afford to pay more get away with more of the surplus.
If you have several prices and create just enough difference in the product that it doesn't change the expense much, you can suck dry every class of user.
Bit of an MBA trick.
We are talking about chips here so not the same bottle of soap with different labels, I'd call that a trick.
Instead of assuming, it's easy enough to confirm that CPU binning is real.
See here: http://isca09.cs.columbia.edu/pres/09.pdf
Also here: https://www.anandtech.com/show/2721
“When AMD produces a Phenom II die if part of the L3 is bad, it gets disabled and is sold as an 800 series chip. If one of the cores is bad, it gets disabled and is sold as a 700 series chip. If everything is in working order, then we've got a 900.”
Hmm, but what if 3 cores are defective? If that can happen(?), then it seems one extra functional core is disabled to get to an even core number.
Apple's M1 GPUs are the first where I've seen the choice between 7 and 8 cores (as opposed to 6/8 or 4/8).
It gets sold as a coaster
Perhaps there is fault tolerance hidden elsewhere, e.g. the neural engine might have 17 physical cores and one is always disabled. Although this seems unlikely as it would probably waste more silicon than it would save.
So the best chips which have the least errors in the manufacturing process are sold as top tier. The ones which have more mistakes in them get their defective parts disabled and then get sold as lower tier ones
Either they just accept the fluctuations in order to maximize output of high end chips, or they would have to cripple fully functional ones to maintain a predictable supply. Interesting business.
The primary purpose is market segmentation: extracting value from customers who would pay more while not giving up sales to more price sensitive clients who nevertheless pay more than the marginal cost of production.
I cannot say this for certain in CPUs but I know in other electronics with PCBs that this is how it is done. Sometimes lower-end SKUs are made by opening a higher-end one and cutting a wire or a trace.
The real reason IMHO, is to have a larger range of product prices so you can cater for specific audiences.
It seems people are confusing cost with price. Those two things are orthogonal.
At this point, yes they may lock down perfectly good high end CPUs to a midrange model spec to meet a production quota.
After manufacture, they test the individual components of their chips. These chips are designed in such a way that once they identify parts of a chip that are defective, they can disconnect that part of the chip and the others still work. (I believe they physically cut stuff with lasers but my knowledge is out of date). This process can also includes "burning in" information on the chip itself, like setting bits in on-die ROMs, so that if your OS asks your CPU for its model number it can respond appropriately.
Interesting side note: The same thing happens when manufacturing even basic electronic components like resistors. All the resistors that are within 1% of the target resistance get sold as "±1%" resistors, which means it's pretty likely that if you buy the cheaper "±5%" resistors and test them, you'll find two clusters around -5% and +5% and very few at the target value.
EEVblog did some tests[1][2] some time ago on ±1% resistors, and found that while his samples were fairly Gaussian and within the spec, the ones from his second batch were consistently low. That is, none were above the rated value.
So yeah, don't assume a perfect Gaussian distribution when using resistors.
And yes, I’m aware that there are also those with the chops, who are not permitted by their money masters (or alternately by their master, money) to write performant software.
If you want to know how the world would be like without video game programmers, just like at internal corporate software and how slow it is.
How many other advances are we tossing away because people don’t know how to optimize and code for speed and fun!
Of course, I'm over here with my poky 6 minute mile...
That's my prediction.
If the specifications are human-generated, then they're just a form of high-level source code, and your prediction boils down to future programming languages simultaneously improving programmer productivity and reducing resource usage. That's not a controversial prediction.
If I understand you correctly, I think you're correct that over time, we'll see an increase at the abstraction level at which most programming is done. I think the effort put into making compilers better at optimizing will largely follow market demand, which is a bit harder to predict.
One interesting direction is the Halide[0] domain-specific language for image/matrix/tensor transformations. The programs have 2 parts: a high-level description, and a set of program transformations that don't affect results, but make performance tradeoffs to tune the generated code for particular devices. The Halide site has links to some papers on applying machine learning to the tuning and optimization side of things.
I can imagine a more general purpose language along these lines, maybe in the form of a bunch of declarative rules that are semantically (though perhaps not syntactically) Prolog-like, plus a bunch of transformations that are effectively very high-level optimization passes before the compiler ever starts looking at traditional inlining, code motion, etc. optimizations.
At some point, maybe most programmers will just be writing machine learning objective functions, but at present, we don't have good engineering practice for writing safe and reliable objective functions. Given some of the degenerate examples of machine learning generating out-of-the-box solutions with objective functions (throwing pancakes to maximize the time before they hit the ground, tall robots that fall over to get their center of mass moving quickly, etc.), we're a long way from just handing a machine broad objectives and giving it broad leeway to write whatever code it deems best.
I suspect in the medium-term, we'll see a 3-way divergence in programming: (1) safety/security-critical programs generated from proofs (see Curry-Howard correspondence, and how the seL4 microkernel was developed) (2) performance-critical programs that are very intensive in terms of human expert time and (3) lots of cookie-cutter apps and websites being generated via machine learning from vague human-provided (under-)specifications.
No, Google's AI is floorplanning[0] (basically routing and layout) human-designed logic in 6 hours. That headline is misleading.
It's kind of like having a compiler will billions of optimization flags and using AI to select a pretty near-optimal set of flags for a particular human-generated source file. We wouldn't call the output an AI-designed program, even though such AI would be really helpful.
Google is using AI as a heuristic for decently fast approximate solutions to the floorplanning problem, where (IIRC) optimal solutions are NP-hard.
It's an important step forward, and presumably a big time saver, but they're nowhere near giving the AI an instruction set spec or examples of inputs and outputs ad having the AI generate the logic.
[0] https://en.wikipedia.org/wiki/Floorplan_(microelectronics)
There is no reason to optimize the language that programmers work in when such optimizations can better be done on the generated machine code.
Once we attain the limits of what we can do in 2 dimensions, we aren't that many exponential growth events from what we can achieve in 3. Or once we achieve the limits of silicon technology, we aren't that many exponential growth events from the limits of photonics or quantum or any other possible computing substrate. Unless we somehow unlock the secret of how to use things smaller than atoms to compute, and can keep shrinking those, we're not getting very much farther on a smooth exponential curve.
What we're seeing now is massive parallelism, which means if your task is embarrassingly parallel, then Moore's Law is very much alive and well. Otherwise, no.
One of my favorite dad jokes is that if Smart Water was so smart, why did it get trapped in a bottle?
More seriously, I see this argument all the time: that we are just squandering our advances in hardware by making comparably more inefficient software! Considering that efficiency used to be thought of on the level of minimizing drum rotations and such: the whole point is that we're now working at a much higher level of abstraction, and so we're able to build things that would not have been possible to build before. I for one am extremely grateful that I don't have to think about the speed of a drum rotating, or build web applications as spiders' nests of CGI scripts.
Are there modern websites and applications that are needlessly bloated, slow, and inefficient? Certainly - but even those would have been impossible to build a few decades ago, and I think we shouldn't lose sight of that.
> we are just squandering our advances in hardware by making comparably more inefficient software
> we're able to build things that would not have been possible to build before
We get that not only are we able to build things that weren't possible before, but we can build things that are more inefficient than was possible before.
We can expect in the future to see new levels of inefficiencies as hardware developments give us more to waste.
Without something to balance this out, we should expect to see our text editors get more and more bloated in cool and innovative ways in the future.
It makes me think of fuel efficiency standards in cars.
CPUs are getting faster, and yet paradoxically, performance is worse, especially in the world of web browsers.
The original DOOM ran at 30 fps in 320x200, which meant it rendered 1,920,000 pixels per second with only a 33 Mhz CPU. That's less than 18 clock cycles per pixel, and even that's assuming no CPU time spent on game logic. If DOOM were written today with a software renderer written in C#, Python, or JS, I'd be surprised if it could get anywhere near that level of clocks/pixel.
These days, the basic Windows Calculator consumes more RAM than Windows 98, and that's just inexcusable.
Also keep in mind that the smaller chips get, the more power-efficient they become; so it can actually cost less in terms of both wall-clock time and watt-hours consumed, to execute a billion instructions on a modern device, than it did to execute a thousand instructions on a 1990s device. No matter how inefficient the software, hardware is just that good.
> These days, the basic Windows Calculator consumes more RAM than Windows 98
The Windows Calculator loads a large framework (UWP) that gets shared by anything else that loads that same framework. That's 99% of its resident size. (One might liken this to DOS applications depending on DOS — you wouldn't consider this to be part of the app's working-set size, would you?)
Also, it supports things Windows 98 didn't (anywhere, not just in its calculator), like runtime-dynamically-switchable numeric-format i18n, theming (dark mode transition!) and DPI (dragging the window from your hi-DPI laptop to a low-DPI external monitor); and extensive accessibility + IME input.
I think the more amicable solution here is to just have higher standards. I might not have given up on Windows (and UWP) if it didn't have such a big overhead. My Windows PC would idle using 3 or 4 gigs of memory: my Linux box struggles to break 1.
On a machine that doesn't have as much memory, the frameworks don't "use" as much memory. (I would note that Windows IoT Core has a minimum spec of 256MB of RAM, and runs [headless] UWP apps just fine! Which in turn goes up to only 512MB RAM for GUI UWP apps.)
Really, it's better to not think of reclaimable memory as being "in use" at all. It's just like memory that the OS kernel is using for disk-page caching; it's different in kind to "reserved" memory, in that it can all be discarded at a moment's notice if another app actually tries to malloc(2) that memory for its stack/heap.
> No matter how inefficient the software, hardware is just that good.
Hardware is amazing. Yet, software keeps eating all the hardware placed in front of it.
And my point was that, by every measure, there's no point to worrying about this particular distinction: the more-powerful CPU + the more-bloated code has the same BOM cost, the same wattage, the same latency, etc. as the microcontroller + less-bloated code. (Plus, the platform SDK for the more-powerful CPU is likely a more modern/high-level one, and so has lower CapEx in developer-time required to build it.) So who cares?
Apps running on multitasking OSes should indeed be more optimized — if nothing else, for the sake of being able to run more apps at once. But keep in mind that "embedded software engineer" and "application software engineer" are different disciplines. Being cross that application software engineers should be doing something but aren't, shouldn't translate to a whole-industry condemnation of bloat, when other verticals don't have those same concerns/requirements. It's like demanding the same change of both civil and automotive engineers — there's almost nothing in common between their requirements.
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.
Subjective. Questionable to you. Nobody is bloating dd
There is definitely bloated software but it's not a huge issue. If it were, then the customer would care. If the customer cares the business would care.
What is the minimal computer you can both compile and run Doom on?
That would be WebGL and Javascript, I presume?
I tried running a Quake port in that vein, but sadly none of the computers I own were able to play it without stuttering.
DOOM ran in 320x200 at 30 fps on a 33 Mhz CPU, which gives it less than 18 clock cycles per pixel rendered. I doubt Python could get anywhere close to that.
It was certainly impressive, but it was aso a case of often design having to give way to such hacks, such as the fact that many older first person shooter games had to have their entire level design work around the idea that the engines could not support two walkable surfaces vertically above each other for performance reasons or the famous Duke Nukem 3D “mirror” hack.
An ESP8266 microcontroller can be bought in low quantity for less than a dollar. I means sure any cost reduction at scale is meaningful, but at that point I don't think the silicon is the expensive part at that point. It just doesn't make sense to give WIFI devices anything less than that performance, the gains in silicon space will be meaningless and you'll spend more managing that than anything.
That works both ways though. The highly qualified software devs did indeed squander some of it away.
But I'm a rather bad dev that writes really inefficient code (because it's not my primary concern, I'm not a programmer, I just need custom software that does the things I need done that can't be done by software other people write).
All this overpowered hardware allows my code to work very well.
I've been in situations where I could pick between "learn to program properly and optimize my code" or "throw more hardware at it" and throwing more hardware at it was definitely the faster and more efficient approach in my case.
"A few" is underselling it somewhat. I would posit that >95% of popular modern websites contain functionality that was not plausible in 1996.
The person operating the console only has to click an option or fill in some text field, same as 20 years ago. But today, with added slowness.
Knowing the amazing advances in hardware in the meantime, this hurts me.
Very much to their credit, though, the Trådfri hub doesn't depend on a cloud service just to operate. If that ever happens, thus endeth my foray into smart lighting. I've put my foot down: if it needs Somebody Else's Computer to function, I don't want it.
Ads.
Oh, and spying/tracking.
The future sucks.
Such a machine would be nowhere near as efficient as a CISC computer in terms of work per clock cycle, but what if our "silicon" in the future can run an almost arbitrary frequency? We would be able to emulate any instruction set natively in real time. The perfect FPGA.
"If you replace all the parts of a ship is it still the same ship?".
This project is equivalent to "Doom running on 40-MHz Cortex M4 found in Ikea lamps".
Good work nevertheless!
Still, we say "I'm playing Doom on my playstation".
In any case, the argument is that the mini console they built is no longer a lamp, not that you can't play games on a console.
Edit: It's still a fun and cool project. But more like running Doom on hardware salvaged from an IKEA lamp.
So the OP is not entirely wrong: they ported a game played on a 16.8Mhz system with 256kb of RAM to a 80Mhz with 108Kb of RAM.
The writeup explicitly says «we could trade off some computing power of the 80Mhz Cortex M33 to save memory»
It also doesn't have quite all the features. No music, and no screen wipe effect (I worked on a memory constrained Doom port myself, and that silly little effect is incredibly memory intensive since you need two full copies of the frame buffer)
If someone said "I'm playing Doom on my PC" in 1993, they would also have been using an external keyboard, monitor, and speakers. And the game would have shipped on external storage (floppy disks).
Historically a lamp would consist of the wick, oil and holder.
What's left in the world for "DOOM running on ____"?
Here's my idea:
Could we do this with a drone swarm? And have players still control DOOM guy somehow? I'm imagining sitting on the beach at night and someone is playing a level while everyone looks up at the sky at a massive "screen".
https://www.airlineratings.com/news/art-sky-check-spectacula...
Now, to figure out how to pump in the soundtrack ...
[0] https://datatracker.ietf.org/doc/html/rfc1149
DOOM in Game of Life.
DOOM as a Boltzmann brain (might take a while before that's implemented, but I bet it'll happen eventually)
Game of Life is totally Turing Complete though, so it's already proven that you can indeed run Doom on it.
See project Blinkenlights from the early 2000 (not Doom, but still video games). https://en.wikipedia.org/wiki/Project_Blinkenlights
Supposedly the guy (Palmer) who created the commercial gba version had done a tech demo for gbc, but Carmack decided it was too stripped down and proposed a commander keen port for gbc at the time instead. Gba came out a couple of years later and was powerful enough.
Then they used it to play Tetris on passing clouds.
- It can't be about chip/logic, as that's a commodity these days (as this post celebretes).
- It can't be LEDs, because they are dirt cheap too, especially red ones.
- Building the plastic case doesn't seem to warrant such a high price.
- The battery needs very little capacity, magnitudes lower than e.g. that of a phone.
- Is it maybe the charging mechanism through USB? Are there some crazy patent fees?
Actually, I find funny that the traditional solution of light and dynamo is 6€+5€ shipping+taxes...
As for the BOM cost, you’re right that for the board, the highest costs are probably the charge circuit followed by the processor. Battery probably costs the most, but don’t discount the cost of the mould for the plastic, it’s a high up front cost that needs to be replaced more frequently than you’d guess.
In the end, that $20 bike lamp probably costs the shop $7-10 to aquire. And any shop that doesn’t charge at least 2x their average cost for small items will tend to find their profitability eroded by fielding returns and other hassle customers.
As for something like the Ikea bulb in the article, it includes an RF module that isn't that cheap. It costs about $7 per 1000 pieces. Maybe they get it for $5 or $6. Add in the slightly more expensive housing, it look like a halogen bulb but is LED, and then add in the cost of a quality RBG LED and the rest of the components and markup to get $15. Ikea does win out compared to other store for things like this because Ikea is buying the units from themself. The Ikea Sonos speaker is the only thing I've ever seen there that wasn't a pure Ikea product. They really have mastered horizontal and vertical integration.
You could probably find exactly the right chip that only has exactly just as many bits of RAM as you need for the lamp's functionality. But that would probably be more expensive to develop and chip than just using standard parts?
Even more radical: I suspect with a bit of cleverness you could probably do everything the lamp needs to do with some relays and transistors. But today, that would be more expensive.
Compare https://www.youtube.com/watch?v=NmGaXEmfTIo for the latter approach.
Interestingly, a friend rented a house in college once that had a system of low voltage light switches that ran back to a cabinet filled with relays that controlled light switches and outlets. No major benefit to the user other than a control panel in the master bedroom that lets you control the exterior and some interior lights. It was a neat system but definitely outdated. I'd imagine a retrofit would be to drop all of the relays for solid state and provide a networked controller to monitor status and provide remote control.
These IKEA smart bulbs cost about $9 so yes, it is cost effective.
https://hackaday.com/2019/04/26/making-a-three-cent-microcon...
Chips that can run Doom, though, are just about at the low end for internet-connected devices. You can't run an IoT stack on that $.03 thing. The chip in the bulb is exactly in the right ballpark for the application. You do need a fairly beefy chip to run multiple network protocols efficiently.
Plus how else will malware people run their stuff?
If you had to design an IoT bulb, this is the ideal setup.
In other words, it does connect to the internet, it also sits on the LAN to give attackers access to all your other devices, AND it sits on Zigbee to give attackers access to those as well.
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!
Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.
Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.
If that sounds stupid, congrats, this is why they call it the internet of shit.
EDIT: Perhaps the terminology got somewhat twisted around here: when I talked about the LAN gateway, I meant specifically the thing that does Zigbee-LAN "translation". Now, that same physical box might also have the capability to work as a Zigbee-Alexa or Zigbee-Google transaltor, which would require a vendor server as you said, but those options are, well, optional. You can certainly disable them and use something like HASS or openHAB as the bridge to whatever cloud service you wish. Same way that my home router has a built-in VPN feature, but I don't use it because I run a VPN server on my NAS instead.
For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.
My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.
When you’re away from home, iCloud will be used, and no IoT vendor systems come into play. This means that all IoT devices can be kept offline and limited to your LAN. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Hone Hub (Apple TV or iPad or HomePod) —> WAN —> iCloud —> WAN —> iPhone.
> Hone Hub (Apple TV or iPad or HomePod) —> WAN
This is how some IoT devices work. As far as I can tell. IKEA has no servers or infrastructure for their devices. And the Apple/Google hubs manage everything for them.
These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.
I know this because I run some local Raspberry PIs that pretend to be WeMo devices and I'm able to control them without any cloud connections from the PIs. The echo discovers the WeMo devices via upnp.
This has been a thing for quite a while[0].
I believe you are correct that Google Home has no local network device control.
[0]: https://hackaday.com/2015/07/16/how-to-make-amazon-echo-cont...
Big difference from what?
You do realize that the vast majority of remotely exploitable security vulnerabilities are in software which can be commanded from the Internet, right?
You could exploit the cloud service directly and gain control of the device, but that's like stealing the security guard's master keys - you can't call that a vulnerability in the door lock, can you?
If you buy the dumb remote, you get a useful smart light setup with no internet or even local network connectivity. Its useful because you can turn a room full of lamps on at once or adjust their color.
The software complexity of these protocols is greater than the complexity of a rudimentary 3D game like Doom, so it's expected that whatever chip can run these protocols can also run Doom.
Datasheet of MGM210L for the curious: https://www.silabs.com/documents/public/data-sheets/mgm210l-...
Also, higher clock speed = lower power consumption. It sounds counterintuitive, but getting the job done quickly so you can go back to low power mode sooner actually saves power, even if the instantaneous power draw while processing is higher.
The WiFi, or BT protocol stacks themselves are however almost always in software on MCUs simply because nobody would bother making a separate ASIC IP for that which will be outdated by the next standard errata.
The real reason is it reduces the cost (and duration) of iterating in the development phase.
The chip is SoC with Arm core, FP, Crypto Acceleration, DSP extensions and FPU unit plus radio parts.
And this also assured it being dead on arrival.
Tuya on other hand is just in every retail outlet, it's just people don't know that Tuya is under the bonnet.
They literally have more talkshops per months than devices released.
That's unfortunate. Protocols, particularly those used for security should be a simple as possible. I know it's a hard problem and people tend to use what is available rather than solving the hard problem.
* Cost effective solution for lightbulb would be not having it wireless connection at all instead of having less powerful MCU. So it being IoT already means that target audience doesn't care about the price that much. * It uses of the shelf FCC certfied wireless module with embedded antenna. For product designer it makes sense using a ready module because it avoids need to do RF design and the certification.It also simplifies the design if you run your user application inside the wireless module instead of having an additional MCU communicating with wireless module. Such modules tend to have medium to high end MCUs.
Why do wireless modules need such processing power?
* 2.4 Ghz Antenna has certain size requirements so the size constraints for rest of the system aren't too tight. * Wireless circuitry puts the module in certain price category, it makes sense to have the MCU in similar price category. Wireless certification is a pain, so there will be less product variants for wireless modules compared to something like 8bit micro controller which come in wide variety of memory, size and IO configurations. If you have single product variant better have slightly more powerful MCU part making it suitable for wider range of applications. * The wireless communication part itself has certain amount of memory and computing requirements. Might as well split the resource budget on the same order of magnitude for wireless part and user application. N kB of memory for wireless and N kB for user application instead of N and 0.001N especially if the first part can easily vary by 10% or more due to bugfixes and compiler changes. Similarly there are basic speed requirements for digital logic buffering the bits from the analog RF part and doing the checksums. * Modern silicon manufacturing technologies allow easily running at few tens of MHz so if the SOC has memory in the range of 30-500KB and isn't targeting ultra low power category it is probably capable of running at that speed.
The current issues are driven by the automotive industry having screwed up and shitcoin miners snatching up GPUs. Neither is going to be a long term issue.
Next level would be finding the cheapest modern mass produced device that can run Doom with no hardware modifications.
This means use whatever I/O the device comes with for controller and display.
Using external display sort of distracts from the coolness.
Second part - it has to be currently in production(like this Ikea lamp). I mean you can find a $10 device/computer from 10 years ago that will run Doom.
That quote reminded me of my first computer: The ZX81, which had 1kb of RAM! About 150 bytes of that was used by system variables, and depending on how you use the screen up to 768 bytes are used by the display buffer.
And yet I managed to write code on it as a kid. :) (Of course nothing like Doom)
The pregnacy-test-kit running Doom was fake? Somehow missed all the front-page retractions on that one.
He added external memory (an 8MB W25Q64).
Amazing clock speed for a lamp. I guess they need it to get the OS started quickly...
What now, you might ask. Well, RGB brain implants running Quake, of course.
Nice work!
It has more CPU perf than my first computer, and costs 1000 times less at the same time.
The progress of semiconductor industry is fantastical.
Who's down?
How do I type IDSPISPOPD on this thing?