enum DATA_ISR_ATTR COMPARE_RESULT gives error when building

[TheDougMiester]

Ok, so first, let me just say I love your work. I love it so much that I tried to build it on an ESP32 using Platformio (VSCode).

I got a ton of errors in ProtocolTimingSpec.hpp. Basically, the same line of code in quite a few places.

error: section attribute not allowed for 'm'
DATA_ISR_ATTR RcSwitch::RxTimingSpec m = T::RX;

This type of coding is pretty new to me, or I'd have just fixed it and told you about how I fixed it. After quite a bit of googling, I understand why you are using DATA_ISR_ATTR, but I don't see a convenient fix for it. I'm hoping you do.

v/r

Doug

[TheDougMiester]

Let me be a little clearer. I tried to build the examples, using esp32 as the target. I've tried it using Platformio and the Arduino IDE (using the Arduino framework).

Hope this helps

[dac1e]

Thank you for the feedback. I concentrated on AVR and SAM Platform first. ESP is just prepared. This will be my next focus. --Gesendet mit der 1&1 Mail AppAm 30.11.24, 4:39 vorm. schrieb TheDougMiester ***@***.***>: Ok, so first, let me just say I love your work. I love it so much that I tried to build it on an ESP32 using Platformio (VSCode). I got a ton of errors in ProtocolTimingSpec.hpp. Basically, the same line of code in quite a few places. error: section attribute not allowed for 'm' DATA_ISR_ATTR RcSwitch::RxTimingSpec m = T::RX; This type of coding is pretty new to me, or I'd have just fixed it and told you about how I fixed it. After quite a bit of googling, I understand why you are using DATA_ISR_ATTR, but I don't see a convenient fix for it. I'm hoping you do. v/r Doug —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dac1e]

I guess I will be able to test and fix the library for ESP32 by end of December 24.

[TheDougMiester]

Fantastic!

[TheDougMiester]

I can report that I built PrintReceivedData.ino for the ESP32 (Arduino framework). The compiler only gave one warning - "PulseAnalyzer.cpp:137:17: warning: list-initializer for non-class type must not be parenthesized ,mInverse(false)"

The code correctly decoded the buttons on two of my protocol 1 transmitters; one with Tri-State and one without.

[dac1e]

Thank you for the feedback. However, I ordered an esp32 eval board, to be able to reproduce esp32 specific bugs in future. I am currently working on a pulse analyzer, that will make it easier to determine the protocol settings for an unknown remote control. I also thought about a translator option, that would translate the received value to a tri state format. Do you think that would be helpful?--Gesendet mit der 1&1 Mail AppAm 04.12.24, 1:08 vorm. schrieb TheDougMiester ***@***.***>: I can report that I built PrintReceivedData.ino for the ESP32 (Arduino framework). The compiler only gave one warning - "PulseAnalyzer.cpp:137:17: warning: list-initializer for non-class type must not be parenthesized ,mInverse(false)" The code correctly decoded the buttons on two of my protocol 1 transmitters; one with Tri-State and one without. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[TheDougMiester]

Yes. I do think that the tri-state information would be useful.

Also, the receiver I'm using is one of those really cheap ones..you may be using the same thing. What I learned about those is that if you're trying to do anything else on that chip, the receiver picks up a ton of noise; so, the interupt fires so often that either nothing else works right or the interrupt for rhe receiver doesn't fire when you push the button. For example, my talking halloween skull's jaw either didn't move or the button didn't work right.

Here's what my (crappy) solution was: I used a timer interrupt for the rf receiver, instead of a button push interrupt. Not a perfect solution, but with a consistent timer, I could also stick the jaw motion into the same loop. A real kludge, but it got me through halloween.

I hope you think of something smarter - using ISR_ATTR is definitely a brilliant way ahead. Being able to untangle the receiver interrupt from the rest of whatever the user is doing is a great advancement

[TheDougMiester]

I should have added that the work I did for the halloween skeleton, I did with an Arduino Nano. I'll be posting the code on Github soon - I need to clean up the comments.... as soon as it's posted, I'll send you the link in case you see anything in there you'd want to copy (doubtful though! Your work is a general solution and much, much cleaner)

[dac1e]

The interrupts are fired upon HF noise also with my receiver: https://www.ebay.de/itm/255283312833 . I read somewhere, that It is quite normal and doesn’t have anything to do with the quality of the receiver. Receivers would increase signal amplification when they don’t receive anything. So they would increase signal amplification until they receive some noise and will then fire interrupts. However, I have improved the TraceReceivedPulses.ino (in release 0.6.1 that I just created), so that CPU interrupt load will be displayed on the serial monitor. I have tested it so far on Arduino UNO and DUE, not ESP32 yet. Although my ESP32 devel board has arrived, I wasn’t able to spend time with it. On my UNO the noise interrupts cause a 4% CPU load. ON my DUE it shows 1%. I would be very suprised, if it would be more on the ESP32. You could try TraceReceivedPulses.ino on your ESP32 board. Follow the steps described at the top oft the ino sketch. If it doesn’t work, I can make it work soon with my ESP32 development board. Von: TheDougMiester ***@***.***> Gesendet: Freitag, 6. Dezember 2024 01:36 An: dac1e/RcSwitchReceiver ***@***.***> Cc: dac1e ***@***.***>; Comment ***@***.***> Betreff: Re: [dac1e/RcSwitchReceiver] enum DATA_ISR_ATTR COMPARE_RESULT gives error when building (Issue #1) Yes. I do think that the tri-state information would be useful. Also, the receiver I'm using is one of those really cheap ones..you may be using the same thing. What I learned about those is that if you're trying to do anything else on that chip, the receiver picks up a ton of noise; so, the interupt fires so often that either nothing else works right or the interrupt for rhe receiver doesn't fire when you push the button. For example, my talking halloween skull's jaw either didn't move or the button didn't work right. Here's what my (crappy) solution was: I used a timer interrupt for the rf receiver, instead of a button push interrupt. Not a perfect solution, but with a consistent timer, I could also stick the jaw motion into the same loop. A real kludge, but it got me through halloween. I hope you think of something smarter - using ISR_ATTR is definitely a brilliant way ahead. Being able to untangle the receiver interrupt from the rest of whatever the user is doing is a great advancement — Reply to this email directly, view it on GitHub <#1 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOE772B2PNEJ2CKGBN2EPRD2EDWOZAVCNFSM6AAAAABSYCJKZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRRHAZDEOJSGI> . You are receiving this because you commented. <https://github.com/notifications/beacon/AOE772A3XM3LO7VLRLIOC232EDWOZA5CNFSM6AAAAABSYCJKZGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUWJ73MU.gif> Message ID: ***@***.*** ***@***.***> >

[TheDougMiester]

Just downloaded and tested your code. It looks to me like you can close this issue. Well done and thank you

[dac1e]

Great. Thanks for the feedback.--Gesendet mit der 1&1 Mail AppAm 27.12.24, 4:02 vorm. schrieb TheDougMiester ***@***.***>: Just downloaded and tested your code. It looks to me like you can close this issue. Well done and thank you —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>