ESP32 wiegand interrupts in IRAM? #34

jpadie · 2018-10-01T07:59:42Z

Does anyone successfully AND reliably have this lib working with ESP32? I notice that neither of the ISRs are in IRAM (which will normally cause kernel panics or stack smash issues) and there are no calls to suspend interrupts nor debounce them (other than the timer condition in DoWiegandConversion()).

In my test setup I am getting no wiegand data received by the sketch at all!

jpliew · 2018-10-01T10:34:52Z

Many reported that this lib working with ESP32.

jpadie · 2018-10-01T10:39:03Z

Thank you. I can't see how that can be accurate when the interrupt handlers are not in IRAM. I suspect that they are getting odd errors that they have been unable to attribute.

Is there a specific reason you don't use iram for your interrupt handlers? And why you don't stop interrupts whilst the interrupt handlers are accessed?

jpadie · 2018-10-01T19:01:38Z

I have it working relatively robustly using iram. Frequently, unfortunately, button presses are not recognised however. I can see the interrupt handler being triggered but no code being reported.

jpliew · 2018-10-01T23:57:36Z

Thank you. I can't see how that can be accurate when the interrupt handlers are not in IRAM. I suspect that they are getting odd errors that they have been unable to attribute.

I have tested with the original ESP32 Wrover kit and was able to get 100 out of 100 scans correct. If it was not working, there should be more issues lodged here. Moreover it is not mandatory to have interrupt vector in IRAM when there was no FLASH operation involved.

Please see official ESP32 documentation
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/intr_alloc.html

This is useful for interrupts which need a guaranteed minimum execution latency, as flash write and erase operations can be slow (erases can take tens or hundreds of milliseconds to complete).

Is there a specific reason you don't use iram for your interrupt handlers?

No specific reason. This library was written before there was ESP32, it was written for pure Arduino. Since the appearance of ESP32, more and more people reported that this library is working with ESP32. So I can't find any reason why we need to change it when it is working.

And why you don't stop interrupts whilst the interrupt handlers are accessed?

There are two types of interrupts handling method,

non-reentrant - used to process critical interrupt when no other interrupts should happen.

and

reentrant - used when other interrupts can happen, or the same interrupt can be processed over and over again, or when the the interrupt is also depending on other interrupt (example timer interrupt).

This library is also depending on the timer interrupt to take care of the timing, so it uses the reentrant method.

Hope this explains all your queries.

Netoperz · 2019-03-03T00:37:36Z

@jpliew

What if I use buffer ? for storing the code, it makes problems with interupts i have also noticed that.

This is my task for wiegand operations, here it is cutted out from main code and i have problems.
Not every input gets to me. COuld You test it ?

This was tested on atmega 32u4 (i started to think about using it as coprocessor for esp32 for handling wiegand) but there are the same problems.

I get some inputs than some not, and than again fine,
The code is below, I'm sorry for the code, i'm not a proffesional developer, , and really may say not a dev at all :D just started learning a year or two ago so there might be some errors.
Could someone throw me a bone what the hack i'm doing wrong ?

The code should do:

read wiegand and store input in buffer , i'm using 5 digit pin codes in my project
if the reader sends the long value it means that it is card, so it should be processed right away not waiting for whole 5 inputs. just send it to serial
if there are 5 inputs just send them to serial
if someone have pressed some keys but not full 5 digit code, after some time just clear the buffer to be ready for next use.
clear the buffer when # is pressed.
i do not use internal input confirmation, i want to blink a led or use sound buzzer to confirm that input was recieved by the MCU.

that's all.
And here is working code, but as i'm not an expert i think that interupts are fu%^*d , and not every input is recieved. The cabling is 15 cm cable from keypad to the atmega (or esp32) , powered by the 3A 5v powersource and active USB HUB, so no problems with power (esp32 does not like weak power like USB)

If someone can help improve that code i would be in heaven.

So here is the code:

``/======================================================================
Atmega32u4, Arduino/Genuino Pro Micro Leonardo
/======================================================================/

#include <Wiegand.h>

#define PIN_BUZZER 6
#define PIN_LED 5

#define BR_0 115200
#define BR_1 9600

unsigned int WiegandInputCouter = 0;
unsigned int WiegandInputCouterLimit = 300;

WIEGAND wg;

long codeBuffer[5];
unsigned int countCode = 0;

//======================================================================
// PIN TO STRING
//======================================================================
void processingPinCode()
{
char pinCodeInput[5];
sprintf(pinCodeInput, "%lu%lu%lu%lu%lu", codeBuffer[0], codeBuffer[1], codeBuffer[2],
codeBuffer[3], codeBuffer[4]);
String pinCode((char *)pinCodeInput);
Serial.print("PIN CODE : ");
Serial.println(pinCode);
Serial1.print(pinCode);
clearBuffer();
}

//======================================================================
// CARD TO STRING
//======================================================================
void processingCardCode(unsigned long codeToCheck)
{
char accessRequestCode[24];
sprintf(accessRequestCode, "%lu", codeToCheck);
String cardCode((char *)accessRequestCode);
Serial.print("CARD NUMBER: ");
Serial.print(accessRequestCode);
Serial1.print(accessRequestCode);
clearBuffer();
}

//======================================================================
// MANUAL MEM. CLEAR
//======================================================================
void clearBufferIfHash()
{
for (int i = 0; i < 5; i++)
{
if (codeBuffer[i] == 13)
{
WiegandInputCouter = 0;
countCode = 0;
memset(codeBuffer, -1, sizeof(codeBuffer));
Serial.println("CLEAR MEM BY #");
}
}
}
//======================================================================
// CLEARING MEM
//======================================================================
void clearBuffer()
{
WiegandInputCouter = 0;
countCode = 0;
memset(codeBuffer, -1, sizeof(codeBuffer));
}

//======================================================================
// LED KEYPRESS CONFIRM
//======================================================================
void runInputConfirmLed()
{
//digitalWrite(PIN_BUZZER, LOW);
// delay(15);
digitalWrite(PIN_LED, LOW);
delay(80);
//digitalWrite(PIN_BUZZER, HIGH);
// delay(15);
digitalWrite(PIN_LED, HIGH);
delay(10);
}

//======================================================================
// IS IT CARD CODE FROM KEYPAD OR NOT
//======================================================================
bool isCardCode(unsigned long currentCode)
{
if (currentCode > 99)
{
return true;
}
return false;
}

//======================================================================
//############################ SETUP ##################################
//======================================================================
void setup()
{
Serial.begin(BR_0);
Serial1.begin(BR_1);
wg.begin(2, 3);

pinMode(PIN_BUZZER, OUTPUT);
pinMode(PIN_LED, OUTPUT);
digitalWrite(PIN_BUZZER, HIGH);
digitalWrite(PIN_LED, HIGH);

memset(codeBuffer, -1, sizeof(codeBuffer));
}

//======================================================================
//############################ MAIN LOOP ##############################
//======================================================================
void loop() {

if (wg.available())
{
runInputConfirmLed(); //confirming input
WiegandInputCouter = 0; //resetting the timer for autoclearing the buffer
unsigned long currentCodeProcessing = wg.getCode();
if (isCardCode(currentCodeProcessing)) //checking if it is card number sent from keypad
{
processingCardCode(currentCodeProcessing); // coverting to string and printing the code and sending to second serial
clearBuffer();
}
else // clearing buffer if "#" is pressed, or printing the 5 digit buffer if there are 5 digits in buffer (i want to use 5 digit pincodes)
{
countCode++;
if (countCode < 6)
{
codeBuffer[countCode - 1] = wg.getCode();
for (int i = 0; i < 5; i++)
{
clearBufferIfHash();
Serial.println(codeBuffer[i]);
}
if (codeBuffer[4] > -1)
{
processingPinCode(); // coverting to string and printing the code and sending to second serial
delay(10);
}
}
}
}
else // auto clearing the buffer if no input for some time
{
if (codeBuffer[0] > -1)
{
WiegandInputCouter++;
if (WiegandInputCouter == WiegandInputCouterLimit) //clearing the buffer if there were left some inputs in buffer but no card and no full 5 digit code was given.
{
WiegandInputCouter = 0;
countCode = 0;
clearBuffer();
Serial.println("AUTO CLEAR MEM.");
}
}
}
delay(50);
}

//====== END

jpliew · 2019-03-03T01:13:32Z

@Netoperz I have not go through all you code, but a quick check, the delay() in the main loop and LED is the main suspect.

The generic frame to frame separation for wiegand is 25ms , your delays are many time over that. Meaning while flashing the LED or waiting in the main loop, you are loosing the other wiegand data that are coming in.

Also you should make use of getBitCounted() to identify if the data is a keypress or card scan.

Netoperz · 2019-03-03T01:40:38Z

@jpliew
When i was thinking about how to verify if the input is complete i thought that there is no freaking way to input negative value using keypad, so i'm using -1 as impossible input reference in buffer.
The delays were used as kind of timers for automatic buffer "clearing" if smeone would left some inputs for example 3 digits, not 5 as full pincode for access verification. to be sure that next user will get the free clean buffer. but it can be done with starting input with # so i'll comment out the delays, and the part of the code for that "timer counter" and i'll check again.

Netoperz · 2019-03-03T02:12:16Z

I've checked, with the code below, there is a bit better , but still first keypres is gone than 2-3 ok, next 2-5 gone. quite random. sometimes if i press keys slower it is better.
I have removed all delays, all unnecesary operations, the timer counter for clearing, whole led operations as you have sugested. The only thing i could remove more are Serial debug from serial0 but i think that this is not a surce of the problem. An whole tests were made on Atmega 32u4 Arduino Pro micro clone, ihave a few of them, keypad connected directly to the arduino board (both are 5v tll so no level converters or so.
I'm using keypad from local importer, with vidiline name on it but it is popular model from china sold with many names /stickers
I think it is made by SecuKey
https://fr.aliexpress.com/item/SK2-R-Free-Shipping-Keypad-Wiegand-Reader-Waterproof-Conforms-To-IP66-Wiegand-26-37-Bits-Output/32817116561.html

https://www.genway.pl/product/attachment/08564f3fe4e658a1d8ac86dabd2cc900/pl_PL/vidi-ac-2cs-ang.pdf

This keypad is not made of gold but is fine, and works well. i have got a few of them. also tested with other brands, the same behavior.
And when those keypads are connected to other hardware with wiegand interface there are no problems, 100% inputs fine, so i'm sure that this is related to my code or the lib. You may test my code if you find a free time. As esp32 may not work as expected when this code is a task with over 2600 lines of other code. It should work fine as standalone code on atmega 32u4 i think, but it has some glitches.

The code is below:

`//======================================================================
// Atmega32u4, Arduino/Genuino Pro Micro Leonardo works on esp32
//======================================================================

#include <Wiegand.h>

#define PIN_BUZZER 6
#define PIN_LED 5

#define BR_0 115200
#define BR_1 9600

WIEGAND wg;

long codeBuffer[5];
unsigned int countCode = 0;

//======================================================================
// PIN TO STRING
//======================================================================
void processingPinCode()
{
char pinCodeInput[5];
sprintf(pinCodeInput, "%lu%lu%lu%lu%lu", codeBuffer[0], codeBuffer[1], codeBuffer[2],
codeBuffer[3], codeBuffer[4]);
String pinCode((char *)pinCodeInput);
Serial.print("PIN CODE : ");
Serial.println(pinCode);
Serial1.print(pinCode);
}

//======================================================================
// CARD TO STRING
//======================================================================
void processingCardCode(unsigned long codeToCheck)
{
char accessRequestCode[24];
sprintf(accessRequestCode, "%lu", codeToCheck);
String cardCode((char *)accessRequestCode);
Serial.print("CARD NUMBER: ");
Serial.print(accessRequestCode);
Serial1.print(accessRequestCode);
}

//======================================================================
// MANUAL MEM. CLEAR
//======================================================================
void clearBufferIfHash()
{
for (int i = 0; i < 5; i++)
{
if (codeBuffer[i] == 13)
{
countCode = 0;
memset(codeBuffer, -1, sizeof(codeBuffer));
Serial.println("CLEAR MEM BY #");
}
}
}
//======================================================================
// CLEARING MEM
//======================================================================
void clearBuffer()
{
countCode = 0;
memset(codeBuffer, -1, sizeof(codeBuffer));
}

//======================================================================
// IS IT CARD CODE FROM KEYPAD OR NOT
//======================================================================
bool isCardCode(unsigned long currentCode)
{
if (currentCode > 99)
{
return true;
}
return false;
}

//======================================================================
//############################ SETUP ##################################
//======================================================================
void setup()
{
Serial.begin(BR_0);
Serial1.begin(BR_1);
wg.begin(2, 3);

pinMode(PIN_BUZZER, OUTPUT);
pinMode(PIN_LED, OUTPUT);
digitalWrite(PIN_BUZZER, HIGH);
digitalWrite(PIN_LED, HIGH);

memset(codeBuffer, -1, sizeof(codeBuffer));
}

//======================================================================
//############################ MAIN LOOP ##############################
//======================================================================
void loop() {

if (wg.available())
{
unsigned long currentCodeProcessing = wg.getCode();
if (isCardCode(currentCodeProcessing)) //checking if it is card number sent from keypad
{
processingCardCode(currentCodeProcessing); // converting to string and printing the code and sending to second serial
clearBuffer();
}
else // clearing buffer if "#" is pressed, or printing the 5 digit buffer if there are 5 digits in buffer (i want to use 5 digit pincodes)
{
countCode++;
if (countCode < 6)
{
codeBuffer[countCode - 1] = wg.getCode();
for (int i = 0; i < 5; i++)
{
clearBufferIfHash();
Serial.println(codeBuffer[i]);
}
if (codeBuffer[4] > -1)
{
processingPinCode(); // coverting to string and printing the code and sending to second serial
clearBuffer();
}
}
}
}
}

//====== END`

Netoperz · 2019-03-03T02:27:25Z

@jpliew
this is output from the same keypad on the same board with the Wiegand test example.

those are 5 times in a row 1,2,3,4,5,6,7,8,9,0, key presses. as You see there is lack of some inputs.
Every key press per second (about):

Wiegand HEX = 2, DECIMAL = 2, Type W4
Wiegand HEX = 3, DECIMAL = 3, Type W4
Wiegand HEX = 4, DECIMAL = 4, Type W4
Wiegand HEX = 5, DECIMAL = 5, Type W4
Wiegand HEX = 6, DECIMAL = 6, Type W4
Wiegand HEX = 1, DECIMAL = 1, Type W4
Wiegand HEX = 3, DECIMAL = 3, Type W4
Wiegand HEX = 5, DECIMAL = 5, Type W4
Wiegand HEX = 0, DECIMAL = 0, Type W4
Wiegand HEX = 1, DECIMAL = 1, Type W4
Wiegand HEX = 3, DECIMAL = 3, Type W4
Wiegand HEX = 4, DECIMAL = 4, Type W4
Wiegand HEX = 6, DECIMAL = 6, Type W4
Wiegand HEX = 7, DECIMAL = 7, Type W4
Wiegand HEX = 8, DECIMAL = 8, Type W4
Wiegand HEX = 9, DECIMAL = 9, Type W4
Wiegand HEX = 0, DECIMAL = 0, Type W4
Wiegand HEX = 1, DECIMAL = 1, Type W4
Wiegand HEX = 3, DECIMAL = 3, Type W4
Wiegand HEX = 4, DECIMAL = 4, Type W4
Wiegand HEX = 5, DECIMAL = 5, Type W4
Wiegand HEX = 6, DECIMAL = 6, Type W4
Wiegand HEX = 7, DECIMAL = 7, Type W4
Wiegand HEX = 8, DECIMAL = 8, Type W4
Wiegand HEX = 1, DECIMAL = 1, Type W4
Wiegand HEX = 2, DECIMAL = 2, Type W4
Wiegand HEX = 3, DECIMAL = 3, Type W4
Wiegand HEX = 5, DECIMAL = 5, Type W4
Wiegand HEX = 6, DECIMAL = 6, Type W4
Wiegand HEX = 8, DECIMAL = 8, Type W4
Wiegand HEX = 0, DECIMAL = 0, Type W4

jpliew · 2019-03-03T09:43:04Z

@Netoperz please use WiegandNG test example. This library will isolate invalid data. I believe you have hardware issue. WiegandNG will print out anything. The missing data are either shorter than 4 bit or longer than 4 bit.

I never have a miss using this library with keypad. No matter how fast or how slow I enter.

Netoperz · 2019-03-04T00:42:47Z

@jpliew
I have tested the multibit example. 100% read, very fast key pressing, so below the same test on the same hardware but with multibit lib. 5 times keys from 1 to 0. 100% captured by arduino.

5, 74407, 74391,74391
Bits=5
RAW Binary=00001
6, 74752, 74735,74735
Bits=6
RAW Binary=000010
4, 75100, 75084,75084
Bits=4
RAW Binary=0011
5, 75425, 75409,75409
Bits=5
RAW Binary=00100
4, 75744, 75728,75728
Bits=4
RAW Binary=0101
4, 76065, 76049,76049
Bits=4
RAW Binary=0110
4, 76383, 76367,76367
Bits=4
RAW Binary=0111
5, 76707, 76691,76691
Bits=5
RAW Binary=10000
4, 77066, 77050,77050
Bits=4
RAW Binary=1001
4, 77406, 77390,77390
Bits=4
RAW Binary=0000
5, 78934, 78917,78917
Bits=5
RAW Binary=00011
5, 79323, 79307,79307
Bits=5
RAW Binary=00010
4, 79723, 79707,79707
Bits=4
RAW Binary=0011
4, 80072, 80056,80056
Bits=4
RAW Binary=0100
4, 80421, 80405,80405
Bits=4
RAW Binary=0101
4, 80760, 80744,80744
Bits=4
RAW Binary=0110
4, 81110, 81094,81094
Bits=4
RAW Binary=0111
5, 81489, 81473,81473
Bits=5
RAW Binary=10000
4, 81848, 81832,81832
Bits=4
RAW Binary=1001
4, 82188, 82172,82172
Bits=4
RAW Binary=0000
4, 85292, 85276,85276
Bits=4
RAW Binary=0001
4, 85731, 85715,85715
Bits=4
RAW Binary=0010
5, 86191, 86175,86175
Bits=5
RAW Binary=00011
5, 86616, 86600,86600
Bits=5
RAW Binary=01000
5, 87009, 86993,86993
Bits=5
RAW Binary=01001
4, 87400, 87384,87384
Bits=4
RAW Binary=0110
4, 87749, 87733,87733
Bits=4
RAW Binary=0111
4, 88128, 88112,88112
Bits=4
RAW Binary=1000
4, 88497, 88481,88481
Bits=4
RAW Binary=1001
5, 88857, 88841,88841
Bits=5
RAW Binary=00000
4, 90863, 90847,90847
Bits=4
RAW Binary=0001
5, 91312, 91296,91296
Bits=5
RAW Binary=00010
4, 91722, 91706,91706
Bits=4
RAW Binary=0011
5, 92121, 92105,92105
Bits=5
RAW Binary=01000
5, 92521, 92505,92505
Bits=5
RAW Binary=01001
4, 92899, 92883,92883
Bits=4
RAW Binary=0110
4, 93279, 93263,93263
Bits=4
RAW Binary=0111
4, 93648, 93632,93632
Bits=4
RAW Binary=1000
4, 94078, 94062,94062
Bits=4
RAW Binary=1001
5, 94438, 94422,94422
Bits=5
RAW Binary=00000
4, 95625, 95609,95609
Bits=4
RAW Binary=0001
5, 96014, 95998,95998
Bits=5
RAW Binary=00010
4, 96384, 96368,96368
Bits=4
RAW Binary=0011
4, 96744, 96728,96728
Bits=4
RAW Binary=0100
4, 97143, 97127,97127
Bits=4
RAW Binary=0101
5, 97542, 97526,97526
Bits=5
RAW Binary=00110
4, 97951, 97935,97935
Bits=4
RAW Binary=0111
4, 98376, 98360,98360
Bits=4
RAW Binary=1000
5, 98779, 98763,98763
Bits=5
RAW Binary=10001
5, 99169, 99153,99153
Bits=5
RAW Binary=00000

Netoperz · 2019-03-04T00:48:37Z

@jpliew
and here 10 times the same key "1" on keypad fast. I see that it is 4 bits sometimes 5 sometimes 6.
So my "lost" input are those 5 and 6 bits transmissions. You were right. Thank You.

Still cannot explain why this keypad has got 100% good input when connected as external keypad to other "wiegand systems/devices" it looks like they can fix/ignore wrong data ?

But why is that happening ? I'm sure that there are no interferences and cabling is soldered well.
What do You suggest ?

Page 13 of the user manual:
https://www.genway.pl/product/attachment/08564f3fe4e658a1d8ac86dabd2cc900/pl_PL/vidi-ac-2cs-ang.pdf

4, 376796, 376780,376780
Bits=4
RAW Binary=0001
6, 377165, 377149,377149
Bits=6
RAW Binary=000001
4, 377554, 377538,377538
Bits=4
RAW Binary=0001
5, 377953, 377937,377937
Bits=5
RAW Binary=00001
4, 378344, 378328,378328
Bits=4
RAW Binary=0001
4, 378703, 378687,378687
Bits=4
RAW Binary=0001
4, 379082, 379066,379066
Bits=4
RAW Binary=0001
4, 379471, 379455,379455
Bits=4
RAW Binary=0001
4, 379851, 379835,379835
Bits=4
RAW Binary=0001
5, 380240, 380224,380224
Bits=5
RAW Binary=00001

jpliew · 2019-03-04T02:28:12Z

Your D0 captured extra noise. D1 is good. I am sure is noise or interference in your Arduino or wiring.

Netoperz · 2019-03-05T16:39:23Z

@jpliew
I have changed the coding to 8 bits, but still D0 gets extra bits, so i have contacted the company selling them , they will check it.

And now i Have other keypad, ROGER
https://www.roger.pl/pl/kontrola-dostepu/system-kontroli-dostepu-racs-4/czytniki-zblizeniowe-prt/czytniki-zblizeniowe-13-56-mhz-mifare/prt64mf-czytnik-zblizeniowy-mifare.html

I have tested this one on the same hardware, and it is much much better. But in 30 reads in a row still some extra bits. rare but from time to time they appear.

I have got five more same keypads and i'll check them too, and one from other manufacturer.

Here You got terminal output from the roger keypad.

30 times in a row key "1"

Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=9
RAW Binary=111000001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=9
RAW Binary=111000001
Bits=9
RAW Binary=111000001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001
Bits=8
RAW Binary=11100001

Netoperz · 2019-03-05T22:06:57Z

@jpliew
I have got a question. What should be going on when the wiegand input pins were left not connected on arduino ?
Exacly when the arduino runs, what the code should do if there is no keypad attached to pin 2 3 and gnd ? I assume it should be silent

But when I disconnect the keypad i getsome 0, that might be those extra bits... but why ?
Is it possibe to pull up/down the lines if they are floating ? or something ?

If i left the arduino without keypad connected from time to time i see:
0
0
0
0
0
PIN CODE : 00000
0
-1
-1
-1
-1
0
0
-1
-1
-1
0
0
0
-1
-1

So it gets zeros, its from static charges i think, because i'm sitting on my sofa.
Is there a way to better filter out those things ? for example if my keypads LED is trigered low, i pull up the pin to avoid accidental trigger, could something like that be done on arduino regarding the wiegand interface ?

jpliew · 2019-03-05T22:26:30Z

@Netoperz when you execute wg.begin() the code already attached the pins to get ready for interrupt input. It will be always ready. Even though there is no output from the wiegand reader, when you disconnect the wires, the movement of the wires causing sparks (the current is too low, you can see the fire but it is there), sparks cause noise that triggers the input pin of the Arduino. This is a normal behavior of electronics nothing to do with the library.

There is also a possibility that your wires are not connected securely causing the vibration that introduce the noise. But without seeing I can't confirm.

My suggestion before still valid, you need an oscilloscope to confirm. Connect the scope to D0 and D1, watch when and where the noise show up. Shake the reader and watch the scope, scan and watch the scope, do whatever and see what is causing the scope.

If you are doing a commercial project, a Rigol oscilloscope is only about $300+ and should be a justifiable investment. If not, find someone and borrow.

jpliew · 2019-03-05T22:28:44Z

Please start a new issue if you have question related to the library. This issue is about ESP32 running in IRAM.

Netoperz · 2019-03-05T22:39:30Z

@jpliew
Thank You, this is not commercial yet, it intends to become, but problems with input devces holds things in place.
I will buy rigol for sure, for now i had some more important things, you know family :D
This is not my issue, so we have explained everything, my opinion is that your library and code till now is awesome work, and I have learned a lot thanx to You, Hope i could do something for you in exchange.

There is also a possibility that your wires are not connected securely causing the vibration that introduce the noise. But without seeing I can't confirm.

This is my case, i never thought that this interface is so prone to inductive interference, How others are handling that problem ? I've seen a lot of installations with so poor cabling, and the devices work fine, when i'm using arduino/esp it's so fragile.

@jpadie
I'm using this library for some time, on ESP32 this library works fine for esp32.
As You may already know, the wiegand interface is not perfectly safe in term of interference resistance.
You must remember that for connecting ESP32 to wiegand hardware You need to use level shifters (3.3v to 5V) and if You do so, i'm sure that no input/output at all is caused by those level shifters. Or You have burned the GPIO already, another thing is that there are input only gpios, and they are problematic,
Also bootsrapping pins should be avoided.

Here You have some good info about ESP32 and how to choose the pinout and why, it helped me, so it might help You.
Remember that ESP32 works differently than arduino, The arduino code is a abstraction layer over native IDF. For example when You use delay() it does not stop the code, it just call vTaskdelay() that holds that particular task and the rest of task can run.....

https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

I had 5 or 6 of them , and only one type works fine.
If you need any help assistance please send me msg. I'll help you to solve the problems, as Jpliew is helping me and others.

So for now "Huston over and OUT"

ipqate · 2021-09-26T07:33:51Z

Hi, maybe it is late (maybe not....)

For those having problems losing button presses, try this: put some pull up resistors between the power and Data 0 and power and Data 1.

It does not solve the problem 100% but improves the overall stability.

Regards

jpliew added the question label Dec 10, 2018

jpliew changed the title ~~ESP32~~ ESP32 wiegand interrupts in IRAM? Mar 5, 2019

jpliew added the solved label Sep 26, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ESP32 wiegand interrupts in IRAM? #34

ESP32 wiegand interrupts in IRAM? #34

jpadie commented Oct 1, 2018

jpliew commented Oct 1, 2018

jpadie commented Oct 1, 2018

jpadie commented Oct 1, 2018

jpliew commented Oct 1, 2018

Netoperz commented Mar 3, 2019

jpliew commented Mar 3, 2019

Netoperz commented Mar 3, 2019

Netoperz commented Mar 3, 2019

Netoperz commented Mar 3, 2019

jpliew commented Mar 3, 2019

Netoperz commented Mar 4, 2019

Netoperz commented Mar 4, 2019 •

edited

Loading

jpliew commented Mar 4, 2019

Netoperz commented Mar 5, 2019

Netoperz commented Mar 5, 2019 •

edited

Loading

jpliew commented Mar 5, 2019

jpliew commented Mar 5, 2019

Netoperz commented Mar 5, 2019 •

edited

Loading

ipqate commented Sep 26, 2021

ESP32 wiegand interrupts in IRAM? #34

ESP32 wiegand interrupts in IRAM? #34

Comments

jpadie commented Oct 1, 2018

jpliew commented Oct 1, 2018

jpadie commented Oct 1, 2018

jpadie commented Oct 1, 2018

jpliew commented Oct 1, 2018

Netoperz commented Mar 3, 2019

jpliew commented Mar 3, 2019

Netoperz commented Mar 3, 2019

Netoperz commented Mar 3, 2019

Netoperz commented Mar 3, 2019

jpliew commented Mar 3, 2019

Netoperz commented Mar 4, 2019

Netoperz commented Mar 4, 2019 • edited Loading

jpliew commented Mar 4, 2019

Netoperz commented Mar 5, 2019

Netoperz commented Mar 5, 2019 • edited Loading

jpliew commented Mar 5, 2019

jpliew commented Mar 5, 2019

Netoperz commented Mar 5, 2019 • edited Loading

ipqate commented Sep 26, 2021

Netoperz commented Mar 4, 2019 •

edited

Loading

Netoperz commented Mar 5, 2019 •

edited

Loading

Netoperz commented Mar 5, 2019 •

edited

Loading