Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate environment specific bindings and make esptool-js usable from Node.js environment #117

Open
cubicap opened this issue Nov 4, 2023 · 2 comments · May be fixed by #122
Open

Separate environment specific bindings and make esptool-js usable from Node.js environment #117

cubicap opened this issue Nov 4, 2023 · 2 comments · May be fixed by #122
Assignees

Comments

@cubicap
Copy link

cubicap commented Nov 4, 2023

I want to use the tool from a Node.js application to flash firmware to an ESP32.

Even though the app is used from a desktop environment, I do not want to rely on the python esptool, because, it is an external dependency, which complicates distribution and limits the possibility of the application being ported to a web app in the future.

To make this possible, I propose two changes:

  1. split the webserial Transport into two classes implementing a simple abstraction layer around the serial port and new Transport implementing packet parsing etc.
  2. change the package configuration, so that it can be imported using node.js module resolution.

This will not require extensive changes and will make it easy to write bindings for other serial port implementations (such as node serialport. It will also make it easier to port the application to completely different connection types (such as RFC 2217).

Breaking changes to the API will be required.

I have hacked an ugly version, which works both in both node.js and as a web app. I've used it as a proof of concept in my app, however, I have not made any changes to the API yet (leading to code duplication in the Transport code). I also do not have much (mostly none) experience with JavaScript/TypeScript build systems and module resolution, for which reason the changes in package configuration are especially ugly (and change things, which probably can be fixed in some other way).

I also do not want to rely on modified/own implementation of the esptool, as it would mean giving up official support and more work in the future.

If the proposed changes are accepted, I will be happy to implement the first suggested change. On the other hand, I do not have the skills to implement the second change, so I would be happy if someone else could do it or guide me through the process.

@igrr
Copy link
Member

igrr commented Nov 15, 2023

@brianignacio5 Could you please take a look at this issue?

@brianignacio5
Copy link
Collaborator

Hi @cubicap Sorry for late reply.

I've made such refactoring in #122 for separating the Transport code into a transport class. Please take a look when you can.

For using this package with Node.js, you should already be able to do so. This package is published in NPM and you can do npm install esptool-js or yarn add esptool-js and there is a module reference in the package.json. I've tested this in our Theia based IDF Web IDE project and is basically doing it with Node.js (as far as I know).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants