Attiny84 16MHz internal option for Arduino IDE,
Need help for appropriate board Manager.
Now I am using
http://drazzy.com/package_drazzy.com_index.json
There is no option for Attiny84 16MHz internal in above mentioned board Manager
I am using Attiny84 20PU
That's awfully slow 
Sorry it was 16mhz ,edited
Actually I like to work with a irremote project with Attiny84,
With same sketch i used with Arduino uno earlier.
That's even slower.
Did you mean 16MHz?
Yes 16MHz same as arduino Uno I think
The maximum speed of the internal clock is 8MHz.
Is there any way to edit board.txt , like attiny85 I have seen some other online forum
The physical hardware of the internal oscillator on the ATTiny84 runs at 8MHz. Nothing you can do in the software on your computer will change that.
If you really, desperately need to run at 16MHz then you can either use an external oscillator/resonator, or use the ATTiny 861 which can run off the internal clock at 16MHz.
To make the attiny 84 run at 16 MHz, an external crystal is needed.
Only the t85 and t861 (and smaller-flash variants of these) support 16MHz off internal oscillator within the classic AVR product line. These are the parts with the internal PLL that generates a 64 MHz clock from the 8 MHz internal oscillator. That can be prescaled by 4 to run the system clock, and/or used as is to clock Timer1, which on those parts is a special high speed timer. The PLL is mainly present to support the high speed timer - these parts are designed for motor control and other applications where high speed PWM with advanced features (such as programmable deadtime) is required. The 861, for example, was designed specifically for control of a 3-phase brushless DC motor (that's why timer 1 is so wacky)
Note that the new megaavr tinies (the ones supported via megaTinyCore) do support 16/20 MHz operation from internal oscillator (and dont support external crystal at all). These are much better, cheaper, parts and are the future of the avr product line. Suggest using these if possible for your application, eg, a 1614.
Thank you for ur information, i am Going try attiny85 With my IR project, hope i can use the same Sketch i used with my UNO will work on attiny85 with 16 MHz PLL,
Becoz i need a smallest chip as possible with 5 I/O pins
nilfarkhan:
Thank you for ur information, i am Going try attiny85 With my IR project, hope i can use the same Sketch i used with my UNO will work on attiny85 with 16 MHz PLL,
Becoz i need a smallest chip as possible with 5 I/O pins
What IR library are you using? I think most of them use a 16-bit classic AVR timer (timer1 on almost all classic AVRs and also timer2 on the attiny841, and timer3/4/5 (if present) on the larger or higher spec ATmega parts that have more timers. The 85 and 861 don't have that timer (they have the high-speed timer in 8 and 10 bit respectively) - though the 85 is so popular that someone may have bullied timer1 into serving that purpose. The high speed timer is frankly far less suited to this application. It's meant for generating PWM at potentially very high frequencies, but it's not very good for general purpose timing like an IR remote control library would need to do (and I can think of a few ways that it is weird that would trip up someone trying to port such a library without a deep understanding of the timer).
Try compiling your sketch for the tiny85 and see if it gives compile errors (if it compiles for the 84, but not the 85, this is almost certainly the reason)!
Why are you dead-set on the 16MHz clock, anyway? I cant imagine it is needed for IR stuff, and I'd be disappointed in any library that wasn't smart enough to pick up on the F_CPU define and adjust itself appropriately - it ain't rocket science.
Why are you dead-set against a crystal? Get one of the 16MHz crystals in the garbage can shaped package and a pair of SMD caps, they're 3mm diameter 8.8mm long. I imagine if space is paramount, you're wiring deadbug style? Solder it direct to the crystal pins, and then for the loading caps, use SMD caps, the smallest ones your hands and eyesight will allow.
For that matter, how are you powering it? Are you, by any chance, hoping to use a LiPo battery? You can definitely get away with that for 16MHz with crystal parts, but I'm not sure you can get away with that on a tiny85 clocked from the PLL. I feel like I've seen multiple places casually refer to the tiny85 from PLL being more sensitive to low supply voltage.
Sketch below compile with attiny84, but LED not working properly by IR REMOTE ,
its working with UNO perfectly.
i am in a project to light up an 1:64 scale Hot wheels car with
Head lamp( High Beam, Low Beam)
Rear Lamp( High Beam, Low Beam when break)
left signal
right signal
Hazard
With Four I/O PINS, 3.7 VOLT LIPO BATTERY.
#include <boarddefs.h>
#include <IRremote.h>
#include <IRremoteInt.h>
#include <ir_Lego_PF_BitStreamEncoder.h>
// --------CONSTANTS (won't change)---------------
const int RECV_PIN = 6;
IRrecv irrecv(RECV_PIN);
decode_results results;
int HL = 5; //HEAD LIGHTS
int RL = 7; //REAR LIGHTS
int RI = 3; // RIGHT SIGNAL LIGHT
int LI = 4; // LEFT SIGNAL LIGHT
//constants for the SIGNAL LIGHTS
const int intervalMinor = 500; // number of millisecs that s LED is off between flasheshttp://drazzy.com/package_drazzy.com_index.json
const int intervalMajor = 500; // number of millisecs that LED is off between cycles
const int blinkDuration = 500; // number of millisecs that LED is on
const int flashesInCycle = 3; // number of flashes inside a cycle
const long interval = 500;
const int toggleDelay = 200; //one press will result in 3 burst of signal,
//so after the first signal is received,
//arduino need to ignore the other signals for a few milliseconds
const int code1 = 0x72FD; //BRAKE (OFF BTN)
const int code2 = 0x92C1; // HEAD LIGHT & REAR LIGHT LED ON/OFF(WHITE BTN)
const int code3 = 0xC861; // RIGHT SIGNAL (*vBTN)
const int code4 = 0x705D; // LEFT SIGNAL (*^BTN)
const int code5 = 0x52E1; // HAZARD SIGNAL
const int code6 = 0x5BE1; // HIGH BEAM
//------------ VARIABLESll change)---------------------
int toggleStatus1 = 0;
int toggleStatus2 = 0;
int toggleStatus3 = 0;
int RIStatus = 0;
int LIStatus = 0;
byte signalStatusRI = LOW;
byte signalStatusLI = LOW;
int flashCount = 0;
int flashCount1 = 0;
unsigned long currentMillis = 0;
unsigned long previousToggle = 0; // this is used both for normal toggling and BLINK toggling
unsigned long previousLedMillis = 0; //for controlling the BLINK
unsigned long previousLedMillis1 = 0;
//========== THE SETUP ==============================
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
irrecv.enableIRIn(); // Start the receiver
pinMode(RL, OUTPUT);
pinMode(HL, OUTPUT);
pinMode(RI, OUTPUT);
pinMode(LI, OUTPUT);
}
//========== THE LOOP ==============================
void loop() {
// put your main code here, to run repeatedly:
currentMillis = millis();
if (irrecv.decode(&results)) {
unsigned int receivedCode = results.value;
switch (receivedCode) {
case code1 :
toggleTheLed1();// BREAK LIGHT (RL )HIGH
break;
case code2:
toggleTheLed2();// HEAD LIGHT & REAR LIGHT LED ON/OFF
break;
case code3:
toggleTheSignal(); // RIGHT SIGNAL
break;
case code4:
toggleTheSignal1(); // LEFT SIGNAL
break;
case code5:
toggleTheSignal2(); // HAZARD SIGNAL
break;
case code6:
toggleTheLed3(); // HIGH BEAM
default:
break;
}
irrecv.resume(); // Receive the next value
}
switchTheLeds (); //the actual function that switch the LED ON or OFF based on the value of their state variable
}
// --------other functions---------------
void toggleTheLed1 () { // BREAK LIGHT (RL )HIGH
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (toggleStatus1 == 1) { // if LED is on then
toggleStatus1 = 0; // set its state as off
} else { // else if LED is off
toggleStatus1 = 1; // set its state as on
}
previousToggle = currentMillis;
}
}
void toggleTheLed2 () { // HEAD LIGHT & REAR LIGHT LED ON/OFF
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (toggleStatus2 == 1) { // if LED is on then
toggleStatus2 = 0; // set its state as off
} else { // else if LED is off
toggleStatus2 = 1; // set its state as on
}
previousToggle = currentMillis;
}
}
void toggleTheLed3 () { // HIGH BEAM
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (toggleStatus3 == 1) { // if LED is on then
toggleStatus3 = 0; // set its state as off
} else { // else if LED is off
toggleStatus3 = 1; // set its state as on
}
previousToggle = currentMillis;
}
}
void toggleTheSignal () { // RIGHT SIGNAL
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (RIStatus == 1) { // if signal is on then
RIStatus = 0;
// set its state as off
} else { // else if siren is off
RIStatus = 1;
LIStatus = 0; // set its state as on
}
previousToggle = currentMillis;
}
}
void toggleTheSignal1 () { // LEFT SIGNAL
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (LIStatus == 1) { // if signal is on then
LIStatus = 0;
// set its state as off
} else { // else if siren is off
LIStatus = 1;
RIStatus = 0; // set its state as on
}
previousToggle = currentMillis;
}
}
void toggleTheSignal2 () { // HAZARD SIGNAL
if ((unsigned long)currentMillis - previousToggle >= toggleDelay) {
if (LIStatus,RIStatus == 1) { // if signal is on then
LIStatus = 0; // set its state as off
RIStatus = 0;
} else { // else if siren is off
LIStatus = 1; // set its state as off
RIStatus = 1; // set its state as on
}
previousToggle = currentMillis;
}
}
void switchTheLeds () {
if (toggleStatus1 == 1)
{
digitalWrite(RL,HIGH);
}
else {
digitalWrite(RL,LOW);
if (toggleStatus2 == 1)
{
digitalWrite(HL,50);
digitalWrite(RL,50);
}
else {
digitalWrite(HL,LOW);
digitalWrite(RL,LOW);
}
if (toggleStatus3 == 1)
{
digitalWrite(HL,HIGH);
}
else {
digitalWrite(HL,LOW);
}
if (RIStatus == 1)
{
signalPattern();
}
else {
digitalWrite(RI, LOW);
}
if (LIStatus == 1)
{
signalPattern1();
}
else {
digitalWrite(LI, LOW);
}
}
}
void signalPattern() {
int offInterval ;
if (signalStatusRI == LOW) { //if the LED is OFF
offInterval = (flashCount < flashesInCycle) ? intervalMinor : intervalMajor; //choose interval value
if ((unsigned long)currentMillis - previousLedMillis >= offInterval) {
signalStatusRI = HIGH;
digitalWrite(RI, signalStatusRI);
previousLedMillis += offInterval;
flashCount = (flashCount < flashesInCycle) ? (flashCount += 1) : 0; //update the counter
}
}
else { // i.e. if onBoardLedState is HIGH (if the LED is ON)
if ((unsigned long)currentMillis - previousLedMillis >= blinkDuration) {
signalStatusRI = LOW;
digitalWrite(RI, signalStatusRI);
previousLedMillis += blinkDuration;
}
}
}
void signalPattern1() {
int offInterval ;
if (signalStatusLI == LOW) { //if the LED is OFF
offInterval = (flashCount < flashesInCycle) ? intervalMinor : intervalMajor; //choose interval value
if ((unsigned long)currentMillis - previousLedMillis1 >= offInterval) {
signalStatusLI = HIGH;
digitalWrite(LI, signalStatusLI);
previousLedMillis1 += offInterval;
flashCount = (flashCount1 < flashesInCycle) ? (flashCount1 += 1) : 0; //update the counter
}
}
else { // i.e. if onBoardLedState is HIGH (if the LED is ON)
if ((unsigned long)currentMillis - previousLedMillis1 >= blinkDuration) {
signalStatusLI = LOW;
digitalWrite(LI, signalStatusLI);
previousLedMillis1 += blinkDuration;
}
}
}
Why are you dead-set on the 16MHz clock, anyway? I cant imagine it is needed for IR stuff, and I'd be disappointed in any library that wasn't smart enough to pick up on the F_CPU define and adjust itself appropriately - it ain't rocket science.
Why are you dead-set against a crystal? Get one of the 16MHz crystals in the garbage can shaped package and a pair of SMD caps, they're 3mm diameter 8.8mm long. I imagine if space is paramount, you're wiring deadbug style? Solder it direct to the crystal pins, and then for the loading caps, use SMD caps, the smallest ones your hands and eyesight will allow.
Which core are you using for the ATtiny? (hopefully mine)
Which pin mapping do you have selected? (compare the pinout chart to the one you're using - there are two pin mappings used in various cores - don't blame me, both of them predated my core - my core supports both, there's a tools submenu to select which one you use (appears when the 84 is selected as your board). Make sure you select the one you did when you chose the pin numbers in the sketch (my guess is that 75% chance this is the problem)
Now - let's move on to the library...
This is the first time I actually read the code for that library; I am not impressed.....
Some time, once I've done one more MAJOR core release that I'm in the early stages of working on (y'all are gonna get drool on your keyboards when I release that bad boy), I'm going to play with IR remotes, do that library right (with input capture!) and also port it to the megaavr line. Those type B timers on the megaavr line are just MADE for this kind of shit (on the classic AVRs, I'll have to tie the receive to one of two pins to use input capture; on the megaavr's you'll be able to use any pin)... but that all is not relevant to you for now.
Looking at the code, though, it absolutely should work on the t84 at 8.
And the t85 too - however, on the t85, it will trash millis() when using my core (or any core except the one weird one that used timer1 for millis - which was incompatible with having a decent implementation of Tone()) - it takes over timer0 for the IRremote functionality (i'd wager because timer1 sucks for that kind of thing like I noted above - though it could totally be done if you study the datasheet really carefully, I live and breath tinyAVR, and i'd tried unsuccessfully to fix a bug in the optiboot LED flash for the 85/861 like 4 times before caused by what I think is the most obnoxious manifestation of this, only much more recently, I'd come back to it with more experience with asynchronous timers, and realized what was wrong)
Hai thank u for ur explanation,
i am a beginner here actually ,i am using DrAzzy core,
and Clockwise (like damellis core) for Attiny84 ?
is there any problem in my sketch,
IR receiver is working fine but leds not lighting up as per my code, it lighting up with some errors i mean its not switching of some times and signal lights not working.........
If you are using the NEC IR protocol, quite common with cheap IR remote devices, there is this alternative library:
https://forum.arduino.cc/index.php?topic=619622.0
It is simple and small and uses interrupts instead of a timer, is quite tolerant of timing errors and works down to 8MHz and probably less. It cannot send codes, however, so cannot act as an IR remote device. At the moment, it is fixed to use external interrupts so you are restricted on what pins you can use. If someone expresses an interest, I can add pin change interrupt handling so it is more flexible about which pins can be used.
So it works sometimes, but not others? Ugh!
Heh - do you know offhand what was wrong with that implementation that makes it so bad?
Why do you use INTn interrupts (or PCINTs) instead of input capture?
If you do a version that uses PCINTs, it should be a separate library file - if you include any file that defines PCINTs, it will grab all the interrupts you defined, even for pins on different ports (like SoftwareSerial does) than the one being used, so you can't use them in the sketch.
So, can u suggest me what should i write instead of int.
i tried #define but Sketch not compiling.
can u help me to correct my sketch please
That suggestion was directed at the guy who was making another version of the library, it does not apply to you; that library uses a different approach (though his library may work better - interrupts of either type are a more sound way to do it)
The question of whether it works sometimes was directed at you, however. That makes a huge difference, as it would rule out like... almost all the things I was about to suggest...
The general problems I have had with the standard IR library were, at least when I wrote that version, that support for 8 MHz devices was not mature. It is also quite clumsy, with a large footprint, and you have to hack around in library components to include/exclude features. Also, its use of resources was quite cavalier and not very clear to the end user what was left for his application. Having said all that, it covers a huge variety of devices and offers a IR transmit in addition to the normal receive function. I would never want to support such a large and varied end user base so I was very specific about the limitations of my own development.
Input capture would certainly be a viable method of achieving he same thing (for the receive part). The timings can range from 9 milliseconds down to 500 uS (at least for NEC protocol). I also did some experiments based on a Nick Gammon example using a prescaler of 1 and packing a timer value and overflow count into a 32 bit long. But the application is not that critical and micros() has an adequate resolution of 4 microseconds so I didn't spend too much time on it. Also, with the input capture, IIRC, there is no equivalent of "on change" as in the on change interrupt, so you have to constantly switch the flank (HIGH or LOW) you are looking for.
With pin change interrupts, you can mask out interrupts from unwanted pins so I don't see that as a huge disadvantage.
Well, his library might be worth a try if it improves performance at 8MHz
6v6gt:
With pin change interrupts, you can mask out interrupts from unwanted pins so I don't see that as a huge disadvantage.
Well the issue is that if you support all pins, that means your library will define an ISR for each port, even ones it doesn't use, thus you can't use any PCINTs for your own sketch, or you get a duplicate vector error...
And yes, with input capture for this you're switching which edge you're looking for every time. Is that a problem? I found it mildly - only mildly - annoying in AzzyRF.