ESP8266F support #400

Open
tvixen opened this Issue Jan 1, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@tvixen

tvixen commented Jan 1, 2017

Board: ARDUINO UNO
Library Version: 2.1.0
Protocol: RC5

Will it be possible to add the esp8266f to the list of hardware ?
This great little board with 4Mb flash will be great together with your IR library.

Thanks in advance.

@PaulStoffregen

This comment has been minimized.

Show comment
Hide comment
@PaulStoffregen

PaulStoffregen Jan 2, 2017

Collaborator

Is the question really whether this is possible, or rather who will actually do the work?

Collaborator

PaulStoffregen commented Jan 2, 2017

Is the question really whether this is possible, or rather who will actually do the work?

@tvixen

This comment has been minimized.

Show comment
Hide comment
@tvixen

tvixen Jan 2, 2017

Well first of all, is it possible ?
As I know the esp8266f is missing some of the IRremote used interrupts.

tvixen commented Jan 2, 2017

Well first of all, is it possible ?
As I know the esp8266f is missing some of the IRremote used interrupts.

@tvixen

This comment has been minimized.

Show comment
Hide comment
@tvixen

tvixen Jan 2, 2017

I've found another project https://github.com/markszabo/IRremoteESP8266
I'm not sure, but I will have a look at this, as it might have the requested IR library.

tvixen commented Jan 2, 2017

I've found another project https://github.com/markszabo/IRremoteESP8266
I'm not sure, but I will have a look at this, as it might have the requested IR library.

@nonflammable

This comment has been minimized.

Show comment
Hide comment

nonflammable commented Mar 5, 2017

@marcmerlin

This comment has been minimized.

Show comment
Hide comment
@marcmerlin

marcmerlin Apr 10, 2017

Contributor

@z3t0 @PaulStoffregen
It is possible, it works, I've used it, but the current authors are kind of worried about the merge being accepted (not counting the work involved) given that the comparatively simple ESP32 isn't going so well, and ESP8266 is much more invasive.
@z3t0 in this specific case, would you consider listing ESP8266 in your readme and pointing to the other lib, in case it never gets merged?
See also markszabo/IRremoteESP8266#148

Contributor

marcmerlin commented Apr 10, 2017

@z3t0 @PaulStoffregen
It is possible, it works, I've used it, but the current authors are kind of worried about the merge being accepted (not counting the work involved) given that the comparatively simple ESP32 isn't going so well, and ESP8266 is much more invasive.
@z3t0 in this specific case, would you consider listing ESP8266 in your readme and pointing to the other lib, in case it never gets merged?
See also markszabo/IRremoteESP8266#148

@z3t0

This comment has been minimized.

Show comment
Hide comment
@z3t0

z3t0 Apr 10, 2017

Owner

@markszabo @marcmerlin

It is possible, it works, I've used it, but the current authors are kind of worried about the merge being accepted (not counting the work involved) given that the comparatively simple ESP32 isn't going so well, and ESP8266 is much more invasive.

sorry about that! I'm trying to keep a nice clean structure since there are so many different platforms to support.

@z3t0 in this specific case, would you consider listing ESP8266 in your readme and pointing to the other lib, in case it never gets merged?

submit a PR with a section in the README and i will update it

But more generally I am perfectly happy to adapt implementations for other platforms to the mainstream following the strict (albeit necessary) restrictions we try to set. I am currently busy but I will create a new issue and add this to my todo list.

So essentially @markszabo doesn't need to worry about the "code style". For now just add a note in the README and around May 30 I will go ahead and adapt the code from the other repo into the mainstream. Then I'll release a beta for testing.

Thoughts?

Owner

z3t0 commented Apr 10, 2017

@markszabo @marcmerlin

It is possible, it works, I've used it, but the current authors are kind of worried about the merge being accepted (not counting the work involved) given that the comparatively simple ESP32 isn't going so well, and ESP8266 is much more invasive.

sorry about that! I'm trying to keep a nice clean structure since there are so many different platforms to support.

@z3t0 in this specific case, would you consider listing ESP8266 in your readme and pointing to the other lib, in case it never gets merged?

submit a PR with a section in the README and i will update it

But more generally I am perfectly happy to adapt implementations for other platforms to the mainstream following the strict (albeit necessary) restrictions we try to set. I am currently busy but I will create a new issue and add this to my todo list.

So essentially @markszabo doesn't need to worry about the "code style". For now just add a note in the README and around May 30 I will go ahead and adapt the code from the other repo into the mainstream. Then I'll release a beta for testing.

Thoughts?

marcmerlin added a commit to marcmerlin/Arduino-IRremote that referenced this issue Apr 10, 2017

@marcmerlin

This comment has been minimized.

Show comment
Hide comment
@marcmerlin

marcmerlin Apr 10, 2017

Contributor

@z3t0 I totally understand you want to keep the code as clean as possible. Sadly, it makes some ports harder. To be pragmatic, I see 2 options, and both are valid choices

  1. we get someone with enough clue to merge difficult architectures while keeping the codebase to your liking. If it's someone other than you, it may be hard but not impossible.
  2. if a port makes things too dirty, it is not accepted and stays as a fork, they can be referenced in your README

Obviously at the end of the day, we're all dealing with the free time of volunteers (including yourself), so if no one can do it sooner, thanks for offering to look at it later.
#436 opened at your request.

Contributor

marcmerlin commented Apr 10, 2017

@z3t0 I totally understand you want to keep the code as clean as possible. Sadly, it makes some ports harder. To be pragmatic, I see 2 options, and both are valid choices

  1. we get someone with enough clue to merge difficult architectures while keeping the codebase to your liking. If it's someone other than you, it may be hard but not impossible.
  2. if a port makes things too dirty, it is not accepted and stays as a fork, they can be referenced in your README

Obviously at the end of the day, we're all dealing with the free time of volunteers (including yourself), so if no one can do it sooner, thanks for offering to look at it later.
#436 opened at your request.

@z3t0

This comment has been minimized.

Show comment
Hide comment
@z3t0

z3t0 Apr 10, 2017

Owner

@marcmerlin I think your options are sensible and whichever ends up happening is okay with me.

Also in terms of ports being difficult I plan on writing a guide for writing additions to the library so that things are easier to understand! Unfortunately, again this won't be any time soon

Owner

z3t0 commented Apr 10, 2017

@marcmerlin I think your options are sensible and whichever ends up happening is okay with me.

Also in terms of ports being difficult I plan on writing a guide for writing additions to the library so that things are easier to understand! Unfortunately, again this won't be any time soon

bengtmartensson added a commit to bengtmartensson/Arduino-IRremote that referenced this issue Apr 17, 2017

@bengtmartensson

This comment has been minimized.

Show comment
Hide comment
@bengtmartensson

bengtmartensson Apr 17, 2017

Contributor

I have just committed a fix that I believe is solving the issue, see link above. It requires #437, which is not yet settled. For this reason, no PR yet. But, feel free to test it and to give feedback. Just check out https://github.com/bengtmartensson/Arduino-IRremote branch esp8266.

Technically, it it uses soft carrier so no interrupt is used, and any feasible pin can be used for sending, possibly at the expense of resource usage.

Note: If the project switches to MIT license, there are some issues to clarify here.

Contributor

bengtmartensson commented Apr 17, 2017

I have just committed a fix that I believe is solving the issue, see link above. It requires #437, which is not yet settled. For this reason, no PR yet. But, feel free to test it and to give feedback. Just check out https://github.com/bengtmartensson/Arduino-IRremote branch esp8266.

Technically, it it uses soft carrier so no interrupt is used, and any feasible pin can be used for sending, possibly at the expense of resource usage.

Note: If the project switches to MIT license, there are some issues to clarify here.

@bengtmartensson bengtmartensson referenced this issue in bengtmartensson/Infrared4Arduino Apr 17, 2017

Open

Support esp8266 #5

@marcmerlin marcmerlin referenced this issue in markszabo/IRremoteESP8266 Apr 17, 2017

Closed

Please merge in upstream IRRemote #148

@marcmerlin

This comment has been minimized.

Show comment
Hide comment
@marcmerlin

marcmerlin Apr 17, 2017

Contributor

Very cool @bengtmartensson , thank you.
I'm happy to give this a try in a little bit, and I also pointed your work to the folks maintaining the fork, who can probably better comment and test than me.

Contributor

marcmerlin commented Apr 17, 2017

Very cool @bengtmartensson , thank you.
I'm happy to give this a try in a little bit, and I also pointed your work to the folks maintaining the fork, who can probably better comment and test than me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment