- 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.
- 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.
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
