Many of us know the basic Blink Arduino sketch, or have coded similar routines on other microcontrollers. Flashing an LED on and off—it doesn’t get much simpler than that. But how big should a blink sketch be? Or more importantly, how small could you get it? [Artful Bytes] decided to find out.
The specific challenge? “Write a program that runs on a microcontroller and blinks an LED. The ON and OFF times should be as close to 1000 ms as possible.” The challenge was undertaken using a NUCLEO-L432KC Cortex-M4 with 256 K of flash and 64 K of RAM.
We won’t spoil the full challenge, but it starts out with an incredibly inefficient AI & cloud solution. [Artful Bytes] then simplifies by switching to an RTOS approach, before slimming down further with C, assembly, and then machine code. The challenge was to shrink the microcontroller code as much as possible. However, you might notice the title of the video is “I Shrunk Blinky to 0 Bytes.” As it turns out, if you eliminate the digital code-running hardware entirely… you can still blink an LED with analog hardware. So, yes. 0 bytes is possible.
We’ve featured the world’s smallest blinky before, too, but in a physical sense rather than with regards to code size.
It’s nice to see people admit that using a microcontroller really is overkill for some tasks.
On our sailing vessel we need a navigation light to blink every second. Somehow the old homebrew electronics (undobtly from the 1980’s) had broken en someone was asked to come up with a solution about 15 minutes before his train left. He said programming a microcontroller was easier than finding out the right resistor and capacitor values for a 555 or a relaxation osscilator. As a quick solution, it was better than having no light. For the next trip, it was reimplemented in resin-potted (because weatherproof) old-fashioned 555 cirquit.
You don’t have to find the right values – guess and use a trimmer pot.
I don’t think that’s approved by the NTSB
The regs specify the frequency, not the how. I don’t think Dude meant just guess.
Guess -> trim -> measure -> guess -> trim -> measure … until within tolerance.
I don’t think it has to be more accurate than “one Mississippi, two Mississippi…”
Also, you need a diode to get to a 555 to a 50% duty cycle, and it still isn’t perfect, otherwise you don’t get a 1000 msec blinky… (also 555s are notoriously imprecise)
…and the microcontroller is cheaper.
Good luck getting analog hardware to produce exactly 0.5Hz, 50% duty cycle.
You can get pretty close with 2 transistors actually. I forget exactly the circuit (could probably dig it up with Google) but 2 non transistors, 2 leds, I think 4 resistors, and 2 caps gives a nice oscillator. Match the 2 values and you have a nice roughly 50% duty cycle.
You could use a fixed LED and blink your eyes : no code needed, no 555, no 4093…
Or a blink LED https://www.ebay.co.uk/itm/221688842866
At grandma’s flat i have resistor-diode-cap-diak-led circuit blinking about 20 years
He did say flash the LED on and off, not your eyes :) . First thought I had a 555. Of course if you needed to blink at different rates depending on inputs, a micro-controller would come in handy, although in a lot of cases, hardware could do the job as well. 0 software is more than do-able. Just how much hardware design do you want to do when the complexity rises.
wow, explains a lot about “coders”. This could be done in a tight assembly loop, calculating the instructions timings.
Another option is to simply use a counter circuit in micro, and arm another timer, or just use the built in timer.
I propose another contest, where we have the most amount of code to blink an led remotely.
Use MQTT, and Druffle ,which interfaces with the puffle framework, based on the huffle architecture, communicating with the dripple api, using the piffle command set, with a dipple server.
The “best” solution should need 2-3 servers, 3 virtual machines, a server farm somewhere, etc.
That would be must IOST [internet-of-sh*tty-things] projects out there.
Don’t forget to include at least 20 security vulnerabilities, and need many open ports and third party frameworks.
“This could be done in a tight assembly loop, calculating the instructions timings.”
.. you mean, as is done in the video and mentioned in the article directly above this comment section?
Pointless snark comes before learning the context. Obviously. This is one of the typical comment types here on HaD.
There was a difference in executable code size between assembly and machine code? I suppose the assembler could have been doing something “helpful”. My gut says I should be able to match those sizes if I tried. But, it’s been a bit since I did any meaningful assembly, and probably have never done it using “professional” grade tools.
Self-blinking LEDs exist. Power one of those with a coin cell and the apparent component count is probably as close to zero as I could readily achieve. No word on 1000ms rate adherence though.
no, there was not. Both ended up being 48 bytes.
There was, however, a reduction in source code size (to zero).
This reminds me some guy comparing fliping time in blinky in arduino library and than in C. It was covered on HAD and people in comments started to give better solutions and reduce time. Nice exercise for students or curious people.
My memory is that it takes 30 instruction cycles (meaning 180 clock cycles) for digitalWrite() to operate, where it takes one instruction cycle for PORTB() to operate. The arduino library does lots of safety stuff so you don’t do anything dumb.
PORTB isn’t a function, it’s a register. It doesn’t ‘execute’ itself, it’s just the raw memory location you write to.
Otherwise yes, that’s the proper / fast way to do it. Outside arduino, embedded C code will usually do it this way. It just requires you to know how to bit shift, etc.
lake a 5mm led, drill out the back of the package, add a supercap and microcontroller (or a very tiny 555) and re seal it with more resin, then you can have a blinky that looks like a normal led. you can charge it plugging it into a powered breadboard. take it out and it continues to blink for a time on its own.
We invented blinking LEDs decades ago.
Write code however you like to write it, but above all, for heaven’s sake, never ever use the lame, vile, nefarious, brainless & ugly DELAY() instruction – or whatever it’s named – in the main program loop !
Coders who use it are heretics who should be burned in public.
Why?
It’s fine if all the firmware does is flash an LED, but once you start doing multiple tasks, it will cause you nothing but problems.
Not if delay is just wrapping another delay function when built on top of a rtos
Nothing wrong with it. And Arduino on ESP32, just wraps vTaskDelay
you could technically do it with zero code and an MCU with a carefully written binary file and a linker script that directly pokes bits into the right timer registers
Why do multiple people in this discussion seem to think “a carefully written binary file” is not “bytes of code”?
Common method on Christmas lights is a bimetallic strip. Precision is optional.
My goto solution for blinking LEDs or lamps of any power or voltage is a blinking LED driving a suitably rated transistor or FET. The only other component needed is a dropping resistor for the blinking LED.
Such LEDs are readily available in fast and slow blink and random flickering (simulates a flame)
Write to the timer registers with jtag to make the led blink and you have zero code with a microcontroller solution.
I love the absurd “better with Ai” approach!
On the low end – I would have expected that “less programm code” could be done with cheating by jtag initializing a clock divider, watchdog and dma somehow. This might lead to a smaller program flashed onto the chip, up to 0 bytes… But 48 is pretty impressive already! Great word and great video!
one neon bi-metal fluorescent lamp starter?
blinked new-years tree lights quite ok back in the USSR :)
(no xmas back then and there :)
I did a minimal PIC-based blinky several years back and submitted it to Hackaday, but they didn’t seem interested. Here, I used a 555 timer + a few resistors & caps as the programmer, toggling in the program using two tactile switches! The PIC code is as minimal as I could make it:
bsf Status,5
bcf trisc,4
bcf Status,5
movlw 53
movwf t1con
Loop:
btfss Pir1,0
Goto Loop
movlw 16
xorwf PortC,f ;invert the LED.
bcf Pir1,0
Goto Loop
https://www.youtube.com/watch?v=Rif9cserayI
Hopefully, this youtube video link doesn’t get blocked by Hackaday!
seems like a farcical route to follow
i make blinkies for a single reason…to orient myself to ‘bare metal development’ on a new embedded platform. i typically write them in asm and i use a delay loop. i always start with a blinkie because you can easily tell if it’s working. it lets me know if i can correctly interact with the bootloader / programming process, whether i can correctly initialize the clock / RAM / XIP / whatever, and whether i can correctly control the gpio. the speed of the blinkie lets me know if there’s any errors in my understanding of the clocks. these days, on spacious ARM MCUs, i might write it in C. and sometimes, i make a second blinky using interrupts if i have any doubts about my ability to control the timer/counter peripheral.
i start out with already just about the smallest blinkie. nothing to write home about, just a proof that i understand how to upload code and initialize the chip. i would think if you would even consider using an RTOS or a stock runtime library then the only possible purpose of a blinkie would be to find out if the vendor worked out the kinks for you. why would you even want to make a smaller one if you weren’t specifically aiming at bare metal programming?
my point is, a blinkie is a silly endpoint…it’s just a “is this thing on?” kind of test, to verify that there is a cause-and-effect relationship between programmer inttent and MCU execution. no point practicing an optimization on it if you don’t intend to do that same approach for your more complicated actual task
There was attempt, which has gone really in dept of what’s possible – 10 bytes.
You can read more detailed explanations here:
https://www.reddit.com/r/arduino/comments/zsbrck/tinyblink_the_smallest_blink_program_challange/?sort=old