@bigjosh, if one wanted to control the IR LEDs on their own, i.e. override the library so they could do things such as turn on and off a TV, where would they start? Does this require access to the BIOS, or can it simply be done at the “app” level?
There are a couple of ways to go “bare metal” on blinks.
First is most rewarding - you literally go bare metal and do all the hardware yourself without using blinklib at all. Here you can do anything, but the downside is that you have to do everything - for example you have do all the work of scanning the RGB LEDs and checking for button presses.
Second is easier - you take control from the bios and blinklib in your code by disabling interrupts and then just directly access the stuff you specifically want. This could be as easy as a few lines of code bracketed by cli() and sei().
LMK specifically what people are looking to do and maybe I can scaffold a bit with an example.
1 Like
Can I read the “input voltage/signal” of a face? (ie how much light it is receiving)? I want to see the amount of noise on them and determine if someone has a finger covering it or not. The goal is to the turn the edges/faces into 6 “touch” (aka: is the light blocked) sensors.
1 Like
Ok, here is a very fast demo of directly reading light levels from the IR LEDs…
Load it up on a blink and play!
I will update with some documentation and explanations shortly.
2 Likes
I downloaded the demo and ran it. Very cool! Thank you!
How can I turn on a color led when the BIOS is disabled?
Is there documentation of what is controlled by the BlinkBIOS? (ie what can I not do from the standard API when it’s disabled?) More specifically: Can I use Timers when the BIOS is disabled?
How can I turn on a color led when the BIOS is disabled?
This starts to get harder. You can not see it with your eyes, but the RGB pixels are actually multiplexed and refreshed dozens of times per second. To make things even harder, the blue pixel are driven by a voltage booster that also must be charged dozens of times per second. This BIOS does all this for you seamless in the background while interrupts are on, but once you turn them off then it is up to you!
So, my first prong would be to try shortening the time the interrupts are off as much as possible and weaving the pixel off time into the UX. Could that work?
If not then I can give you some code that can light a RED pixel (red is easier than blue!) while interrupts are off, but that will take some effort! LMK!
Is there documentation of what is controlled by the BlinkBIOS?
Pretty much everything - contract here…
Can I use Timers when the BIOS is disabled
While the interrupts are off, you own the hardware so you can do anything you want… just be sure you clean up after yourself and set everything back again before you re-enable interrupts! 
In fact the way I would implement the functionality mentioned above would be to use a timer to PWM the red led cathodes, and then manually enable the anode of the one pixel I wanted to be on.
Do note that you probably want to keep that duty cycle VERY low since normally each pixel LEDs are only on for at most 1/6 * 1/5 = 1/30th of the time (1/6 because the 6 pixels are multiplex, 1/5 because there are 5 “phases” per pixel - 3 for the colors and 2 for the charge pump).
-josh
Ah, I re-reading your comment, I now think you you probably meant the blinklib Timer class rather than the hardware timers in the chip?
If so, then no - you can not use software Timers while interrupts are off since they will not be updated. Onc work-around is to use the _delay_ms() function to insert a known delay. You can also use the hardware timers, but that is harder.
LMK what you want to do and we can figure out best way to get you there!
Thanks for this awesome reply!
The idea was to see if we could use the IR Transmitter/Receiver as a sort of “touch sensor.” The goal would be to make a game in which players touch a particular face (or use that as a type of UI/UX interaction; touching one of 6 faces is much easier/faster than clicking the button 6 times).
I had 2 goals with the questions:
- Determine if low level IR control would allow me to sense which faces are blocked/obscured by a user’s finger.
- See if we could easily integrate low level IR readings into the “standard” Blinks API.
For (1) it seems not possible. At least not with my fingers on consumer (and dev-kit) Blinks in a few different rooms/lighting conditions. I can definitely measure infrared “levels” but cannot clearly distinguish which face may have more/less infrared hitting it reliably. Since (1) doesnt seem feasible with my current approach, I wont need to use (2) but it’s useful information to have in case I think of another reason why I would want to manually read the IR Leds.