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

161–170 of 191 posts

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

#161

Post by RetroTechie »

sam_bristow wrote: post #4

It might be a myth, but I seem to remember the ASICs used to flicker older LED designs were often repurposed from audio greeting cards. The light was actually just Happy Birthday playing through an LED or bulb rather than a speaker.

Iirc, at least one design used a counter + ROM table with brightness values. And ROM table of bigger size (1k+ entries or so?) than one might expect. All this because a pseudo-random generator wouldn't produce nice enough effect. And b) counter + ROM asic still cheaper to manufacture in volume than a uC (probably not true anymore?).

But I'd be interested what OTP tech uC from the article uses. Mask programmed? Fuse-based? Flash? (and if so: erasable?). Something else?

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

#162

Post by dekhn »

jacquesm wrote: post #119
dist-epoch wrote: post #50

Earlier quoted context omitted.

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.

You left out the preprocesser (RNA transcriptase) which takes the config file and transcribes it, possible modifying some bits in-place, before it gets to the ribosome.

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

#163

Post by dekhn »

makerdiety wrote: post #94
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…

> I have noted this article for my talk about how CPUs are free. If teeny computers are free, and if I want to re-program them for my own use cases and personal applications, then why do I have to still spend nearly a thousand dollars or two on embedded systems development equipment like microcontroller development boards, JTAGs, ICEs, ROM flashers, UART-based bootloading solutions, and other delicate programming int…

The future of everything is basically "the upfront and ongoing costs of the tooling are infinite, while the physical deployment is free".

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

#164

Post by NavinF »

makerdiety wrote: post #94
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…

> I have noted this article for my talk about how CPUs are free. If teeny computers are free, and if I want to re-program them for my own use cases and personal applications, then why do I have to still spend nearly a thousand dollars or two on embedded systems development equipment like microcontroller development boards, JTAGs, ICEs, ROM flashers, UART-based bootloading solutions, and other delicate programming int…

> I have to still spend nearly a thousand dollars or two on embedded systems development equipment

wat

> JTAGs, ICEs, ROM flashers, UART-based bootloading solutions

Dude, all the popular chips these days are ARM MCUs with SWD. They can be programmed with a $3 ST-Link V2. The most you'd spend on the stuff you listed is $75 for a Black Magic Probe, but of course you can build your own for 1/10th the price.

$0.03 MCUs are the exception to the rule since they use proprietary protocols and OTP memory, but their programmers are still in the $100 range

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

#165

Post by 93po »

declan_roberts wrote: post #93
DenisM wrote: post #68

Earlier quoted context omitted.

Still rather odd not to have a video on the page of a product where animation is the key selling point. Maybe a video wouldn’t convey all the benefits of the design, but lack of video does not inspire confidence either.

I came here to ask for a video!!

https://www.facebook.com/glassybaby/videos/2723369747740357/

i'd prefer a side-by-side with real candle but oh well

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

#166

Post by ddingus »

To whomever:

I really, really, REALLY, did I say, "Really" miss the twinkle of old school incandescent blinking Christmas lights.

Each light has a metal spring that heats as the light glows. Eventually, the spring warms enough to move and break the circuit, thus turning the lamp off.

As the spring cools, eventually the circuit is made again, turning the lamp back on, and the cycle continues.

And there is more!

At first, the whole tree is illuminated. Then, one by one, the lights begin to blink.

Soon many are blinking.

Then all of them do it.

Because those springs are coarse and made as quickly as possible, there is considerable range in the cycle times of all the lamps.

Finally, the sustained, faster cycle time happens 5 to 10 minutes in. The lamp reaches a steady state, on, off, on, off, that is very regular.

Please, someone model this, drop it in a little MCU and sell us lights that twinkle, not just blink in some pattern.

If I were to guess, there is about 10 bits of variation needed to really capture what the old bulbs do. 8 bits may be enough, if one ignore outliers, those bulbs with either very short or very long cycle times. Those are rare, but do add to the magic of it all.

Thanks, I am waiting.

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

#167

Post by buescher »

floating-io wrote: post #126
buescher wrote: post #121

Earlier quoted context omitted.

You can tell the age of an embedded programmer by whether they consider sampling an input to be "polling" (which to me implies blocking, but that's another discussion) and then look for silver bullets for interrupt storms.

Polling has never implied blocking. It’s actually a way to avoid blocking. I think you’re thinking of “busy-wait loops”. The difference between “polling” and “busy wait” is whether or not the CPU is doing other unrelated things between samples. The difference between polling and interrupts is that with interrupts the CPU can halt entirely while waiting rather than having to take those samples in the first place.

You're not entirely wrong, and thanks for pointing this out, but polling is also frequently used to mean "busy-wait loops" - you can look for it if you doubt me. I didn't really want to get into that conversation.

The other thing that polling implies is that there will not always be data present when you poll (think of a UART driver), and you might block as long as there is, and you may or may not be polling at a deterministic rate. Sampling unambiguously implies that a sample is always present and handled. It does not preclude any use of interrupts - you can sample with a timer interrupt or handle a sample with an A/D interrupt.

Many embedded programmers of a certain age have a nearly fixed mental model of a microcontroller as a sort of headless VIC-20 and a certain horror at sampling techniques that derives from enduring crummy polling peripheral drivers/handlers from the early days of personal computing.

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

#168

Post by cushychicken »

crote wrote: post #88
cushychicken wrote: post #25

Is the actual make and model of the MCU just a guess? Doesn’t seem to be anything to corroborate the PIC12 besides a pinout the author has seen before. Just mention because there are likely a zillion eight pin MCUs with this pinout/ballout pattern.

The post makes no mention of the actual MCU being used, they just note that it's interesting that the pinout matches the often-cloned PIC12. It's one additional piece of evidence hinting that it's probably an MCU die in there, rather than some kind of ASIC.

Matches in shape, yes.

Is there any evidence it matches in function?

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

#170

Post by jacquesm »

dekhn wrote: post #162
jacquesm wrote: post #119

Earlier quoted context omitted.

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.

You left out the preprocesser (RNA transcriptase) which takes the config file and transcribes it, possible modifying some bits in-place, before it gets to the ribosome.

#defines all over the place as well as decidedly unhygienic macros. Serves them right for still using 'C'. The list of CVEs is endless for that stuff, entire encyclopedias full of them.
Post reply on HN