The reason for this change is that I was informed by a community
member that the Pro Micro board does not have the default pin 13. This
causes many issues for beginners that are not familiar with the inner
workings of the library. However, I am concerned about this being a
breaking change. If there are serious issues I may just end up adding
a tutorial in the FAQ for beginners, informing them how they may
change the default pins.
- fixed indenting on existing code in a few places for consistency
- introduced IR_TIMER_USE_ESP32 for ifdefs within the code as per
request
- added comments explaining what's missing for irsend support on ESP32
- IRrecvDemo.ino gets a warning before and after interrupt is enabled in
case it causes a crash
TESTED=IoTuz ESP32 board and original 328p arduino to make sure current
code did not break.
- disable a lot of defines not relevant to ESP32, set them to 1 (no-op)
- change default IR pin to 35 from 11
- changed serial speed to 115200 (9600 is too slow to keep up with IR input)
- irSend disables code that will not compile on ESP32. It won't work,
but it won't break compilation either.
One of our users of AnalysIR, reported issues with sending DIsh signals. After some investigation we realised that this file was neglecting to send the trailing mark after the bits. Fix is included in this update & has been tested on a live Dish device by our own user.
AnalysIR - 26th March 2016
----------------------------------------
https://www.AnalysIR.com/
This is a small change, and definitely an improvement. I simply improved the debugging by stating whether a check passed or failed, for easier identification in debug mode.
- Cleaned up layout of output, removed trailing commas
- buffer sizes are now correct
- no need to add 0 for space at end, as sendRAW takes care of this
Fixed presentation & 2 bugs.
Presentation: No longer display leading space in timings, as is confusing to users & essentially irrelevant.
Bug Fix 1: rawData was starting with a space & would not work with sendRaw
Bug Fix 2: chaned x from unsigned int to nsigend long to avoid potential overflow on integer multiplication.
very similar to recent changes to IRrecDump #167#207
Have updated IRrecvDdump to fix bugs described in Issue: #167
In summary, removed bug where large space values were displayed incorrectly & confusing users. The output now always starts with a mark, instead of a space, which makes it easier to interpret and less confusing for users.
refer to #167 for more detials.
The update has been tested with several protocols (but not all) and verified as working.
As sendRaw is a very popular methos of sending unknown or AC signals, I though it would be very useful to include and example of same with the library.
The code in this new example is tested and verified as working with the latest Master.
As written this example will cause issues with some IR receivers. On the face of it it sends teh sony signal burst 3 times with a 40ms gap. However, it really continues to send the sony signal forever with a 40ms gap.
There needs to be a reasonable gap between signals sent & I have added in a 5 sec gap as a reasonable figure.
Without a gap, many IR receivers will treat this signal as noise as it send continuous sony bursts with a 40 ms gap.
looks like this multiplier was omitted and needs to be include to make the output meaningful/useful???
Would also explain some weird output I have seen posted.
parameters changed from int to unsigned int to allow longer mark/space durations and signal length.
hz changed to allow for potential future use of 455kHz carrier frequency. (Ther may be existing modes to the library, using this frequency)
parameters changed from int to unsigned int to allow longer mark/space durations and signal length.hz changed to allow for potential future use of 455kHz carrier frequency. (Ther may be existing modes to the library, using this frequency)
removed "asm" workaround for compiler, because it was not need ed on my system.
Original autor should verify this again. It could be alternatice compiler optimization settings?
Alternatively, place the volatile keyword before the variables in the function to avoid the "optimization out"
Use micros() to delay based on "real-time" instead of approximation with
delay() or delayMicroseconds()
Changed name to _usec to correspond to MicroSeconds.
_ms is MilliSeconds.
Improve output for recvDumpV2
Added my name to the contributors list (not 'cos I really care for the credit <whatever> but so people know who to "blame" [non-pejorative])
Moved the decode() function to the top of the source as it is likely to be edited the most
Utterly failed to reduce the MARK_?? functions back down to MACROs - every time I try, the decoders start failing ...However, I have found a considerable number of bugs in the toolchain, so I'm starting to wonder if the fault is not mine.
Previously, when enabling or disabling interrupts on the ATmega8, the
whole TIMSK register was overwritten. This disables all other timer
interrupts (for Timer0 and Timer2). The fix takes care of that by
selectively enabling/disabling the required OCIE1A flag.
Most work already done by zenwheel, but the sendPanasonic command
didn't work. Sending and decoding is confirmed to work with using both
the JVC and Panasonic protocol.
The library has also been updated to work with Arduino IDE 1.0.
Many problems happen with git due to some machines liking CRLF at the
end of lines, and others linking CR. To try to straighten this out,
I'm using Unix-style LF (\n) as the line endings. To make sure your
repository remains consistent, try:
$ git config --global core.autocrlf input
For details, see:
http://help.github.com/dealing-with-lineendings/
@@ -33,7 +33,6 @@ Whether you use the Adafruit Neopixel lib, or FastLED, interrupts get disabled o
- ATtiny 84 / 85
- ESP32 (receive only)
- ESP8266 is supported in a fork based on an old codebase that isn't as recent, but it works reasonably well given that perfectly timed sub millisecond interrupts are different on that chip. See https://github.com/markszabo/IRremoteESP8266
- Sparkfun Pro Micro
We are open to suggestions for adding support to new boards, however we highly recommend you contact your supplier first and ask them to provide support from their side.
@@ -44,7 +43,7 @@ We are open to suggestions for adding support to new boards, however we highly r
- Changed default send pin on ATmega32u4 from 13 to 9.
Note: this is a non-backwards compatible change as the behaviour of existing programs using this board for receiving WILL be affected. If you would like to use pin 13 as before then please search src/boarddefs.h for "32u4" and comment the line for pin 9 while uncommenting the line for pin 13
## 2.3.3 - 2017/03/31
- Added ESP32 IR receive support [PR #427](https://github.com/z3t0/Arduino-IRremote/pull/425)
Cette bibliothèque vous permet d'envoyer et de recevoir des signaux infrarouges sur un Arduino.
Des tutoriels et plus d'informations seront disponibles sur la page d'accueil officielle.
## Version - 2.2.3
## Installation
1. Allez à la [Releases](https://github.com/z3t0/Arduino-IRremote/releases) page.
2. Téléchargez la dernière version.
3. Extraire le fichier zip
4. Déplacez le dossier "IRremote" vers vos bibliothèques.
5. Assurez-vous de supprimer Arduino_Root / libraries / RobotIRremote. Où Arduino_Root fait référence au répertoire d'installation d'Arduino. La bibliothèque RobotIRremote a des définitions similaires à IRremote et provoque des erreurs.
## FAQ
Je ne travaille pas correctement en utilisant Neopixels (aka WS2811 / WS2812 / WS2812B)
Que vous utilisiez la librairie Adafruit Neopixel ou FastLED, les interruptions sont désactivées sur de nombreux processeurs bas de gamme comme les arduinos de base. À son tour, cela empêche le gestionnaire IR de s'exécuter quand il le faut. Il y a quelques solutions à ce processus, voir cette page de Marc MERLIN
[cette page de Marc MERLIN](http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html)
- ESP8266 est basé sur un ancien code qui n'est pas très récent, mais cela fonctionne raisonnablement bien. Voir https://github.com/markszabo/IRremoteESP8266
Sparkfun Pro Micro
Nous sommes ouverts aux suggestions d'ajout de support pour les nouveaux tableaux, cependant, nous vous recommandons fortement de contacter votre fournisseur et de fournir un soutien de leur côté.
Voici les correctifs strictement pris en charge qui n'ont pas encore été intégrés. Si vous avez des questions, n'hésitez pas à demander ici. Si cela fonctionne, faites le nous savoir!
Le tableau ci-dessus répertorie les temporisations actuellement supportées et les broches d'envoi correspondantes, beaucoup de ces broches supplémentaires sont ouvertes.
## Utilisation
- À faire TODO (Vérifier les exemples pour l'instant)
## Contribution
Si vous voulez contribuer à ce projet:
- Signaler les bogues et les erreurs
- Demander des améliorations
- Créer des problèmes et tirer des requêtes
- Parlez de cette bibliothèque à d'autres personnes
- Contribuer de nouveaux protocoles
Vérifiez ici [ici](Contributing.md) pour quelques guidelines
## Contact
Email: zetoslab@gmail.com
Please only email me if it is more appropriate than creating an Issue / PR. I **will** not respond to requests for adding support for particular boards, unless of course you are the creator of the board and would like to cooperate on the project. I will also **ignore** any emails asking me to tell you how to implement your ideas. However, if you have a private inquiry that you would only apply to you and you would prefer it to be via email, by all means.
## Contributeurs
Check [here](Contributors.md)
@Lsuperman735 French translation
## Copyright
Copyright 2009-2012 Ken Shirriff
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.