Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

General purpose MCUs built in to LEDs emulate candle flicker

cpldcpu.wordpress.com

Post reply on HN
Print view View original

111–120 of 191 posts

Re: General purpose MCUs built in to LEDs emulate candle flicker

#111

Post by tzs »

0xcde4c3db wrote: post #66
kragen wrote: post #11

Earlier quoted context omitted.

the 6502, 8080, z80, 8085, 8086, 65816, 68000, and 68010 were universally described as microprocessors, not microcontrollers, but did not have mmus built in (and of these only the 68010 could easily have one bolted on, as i understand it) i think typically the thing that distinguished these from microcontrollers like the 8031, 8051, 8748, 8751, pic1650, etc., is that the microcontrollers had program memory built into…

I believe 68000 could use an MMU, but the catch was that it couldn't do demand paging, just memory protection and virtual/physical translation. I can't find the specific explanation right now, but it's something along the lines of the bus error exception (needed to actually stop the memory cycle) being special in a way that sometimes causes an incorrect PC value to be pushed to the stack. So you could terminate a pro…

There was at least one company (Apollo, I think) that implemented demand paging on 68000 by using two 68000s. You had one, the leader, running as the "real" CPU, with the other, the follower, executing the same code on the same data but delayed by one instruction.

If the leader got a bus error they would generate an interrupt on the follower to stop it before it executed the bus erroring instruction.

The leader and follower would then switch roles, and the new leader could deal with the situation that had caused the bus error on the former leader.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#112

Post by KANahas »

ChuckMcM wrote: post #96
crote wrote: post #79

Earlier quoted context omitted.

> at some point I expect to finally see the "blending" of analog/digital chips that allow for a wide range of voltages The irony is that the developments which made dirt-cheap MCUs possible have at the same time basically ruled this out. Digital logic is almost trivial to scale down. With Moore's Law the compute core itself is indeed becoming basically free. However, IO does not scale down: modern chips have far fewe…

I don't disagree at all, this analysis is spot on. The size of discretes on silicon has not shrunk nearly as much as it has for transistors. However, where I am coming from is that because the transistors have shrunk so dramatically it becomes possible to put an entire CPU in the "left over" space after you've placed the discretes. There was a talk at either Hot Chips or ISSC in 2011? about a mixed mode chip where th…

The Cypress part family you are likely thinking of is the PSoC line, it’s a MCU mixed with very configurable analog front end.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#114

Post by MiguelX413 »

doubloon wrote: post #103
mschuster91 wrote: post #56

Earlier quoted context omitted.

> We're OK with disposable alkaline batteries, so what makes lithium worse? No we're not. Disposable batteries should not be a thing anywhere, especially not in products where they cannot easily be removed by design. Alkaline batteries may not combust when damaged, but their internal juice leaking out is damn corrosive. > A fully discharged battery shouldn't do much. Even that is enough to light trash compactor truck…

should Apple be forced to produce batteries for 2001 clamshell ibooks?

Probably not, but I don't really see what that has to do with anything.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#115

Post by jacquesm »

ChuckMcM wrote: post #63

I love it. I have noted this article for my talk about how CPUs are free. To appreciate that, you have to understand that when the first microcomputers came out engineers were still in "compute" mode[1], we were lectured that you wouldn't use a hard coded loop to check for a switch closure, you had to use interrupts because otherwise you were wasting all those CPU clocks . And computing at the time was often billed i…

We're almost at (or are already at) the stage where the packaging of the chip costs more than the computer inside it.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#116

Post by shagie »

One of the things that I've thought about back in the days of poorly looped animated gifs and Java applets was those annoying flame gifs that didn't loop right. A project that I tinkered with (never finished) was creating a cellular automata that creates a flame like structure.

For a Java applet, it would have just continued on forever with random fuel being added. However, a different application of the 'fuel' for the flame would have had it loop over some period.

The other part is that with animated gifs and a 256 color pallet, one could index the flame color. Roughly for RGB this is step 3 through 0,0,0 -> 255,0,0 -> 255,255,0 -> 255,255,255 (not perfect, but it kind of works for a proof of concept).

And then, the value of a cell is a function of the cells below it in the previous time iteration.

With the fuel rows at some point looping (if written that way), so too would the overall frame loop at some point... and you could have a perfectly looping flame gif.

While that's all well and good, flame gifs are kind of a 90s thing... but my interest in reviving that old code coincides with me occasionally wondering "what could I do if I made a volumetric display?"

Re: General purpose MCUs built in to LEDs emulate candle flicker

#117

Post by jacquesm »

tzs wrote: post #111
0xcde4c3db wrote: post #66

Earlier quoted context omitted.

I believe 68000 could use an MMU, but the catch was that it couldn't do demand paging, just memory protection and virtual/physical translation. I can't find the specific explanation right now, but it's something along the lines of the bus error exception (needed to actually stop the memory cycle) being special in a way that sometimes causes an incorrect PC value to be pushed to the stack. So you could terminate a pro…

There was at least one company (Apollo, I think) that implemented demand paging on 68000 by using two 68000s. You had one, the leader, running as the "real" CPU, with the other, the follower, executing the same code on the same data but delayed by one instruction. If the leader got a bus error they would generate an interrupt on the follower to stop it before it executed the bus erroring instruction. The leader and f…

That's so clever. What a hack. I'm imagining the slow smile on the face of the person that came up with it. "What if...".

Re: General purpose MCUs built in to LEDs emulate candle flicker

#118

Post by jacquesm »

pietervdvn wrote: post #71
082349872349872 wrote: post #2

Once upon a time, on USENET, someone had a .sig that predicted one day computers would be cheap enough they'd come in cereal boxes and we'd throw them away. That day appears to have arrived.

I got a server blade with a Xeon processor and 96 gigabytes of RAM for free last week... Granted, it is a ten year old device, but still. Another friend will give me a 180 gigabyte RAM device next week, cause it would go to the container otherwise...

It's the power consumption and the noise that gets you with those.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#119

Post by jacquesm »

dist-epoch wrote: post #50
ThisIsMyAltAcct wrote: post #20

Some people say software is eating the world but I prefer to say its infesting it.

DNA is software. The world is already full of software. We're just catching up.

Technically speaking it is a very large configuration file. The config reader runs Ribosome 0.8, which escaped from the lab a couple of billion years ago and infested a whole planet to the point that it became inhospitable to life.

Re: General purpose MCUs built in to LEDs emulate candle flicker

#120

Post by jacquesm »

marssaxman wrote: post #17

Seems like a small step up from the ubiquitous WS2812, an LED with an onboard controller handling PWM and one-wire communication. Years ago, before animated LED christmas lights were readily available, I hand-made such a string out of ATtiny85 controllers, soldered onto bicolor red/green LEDs, one controller per light. A little bit of C and an evolving animation algorithm recycled from a previous project yielded a pl…

$.032 in quantity...
Post reply on HN