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

Possibility of Releasing the Firmware as a Dynamic Library #5

Open
atabou opened this issue Oct 1, 2023 · 5 comments
Open

Possibility of Releasing the Firmware as a Dynamic Library #5

atabou opened this issue Oct 1, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@atabou
Copy link

atabou commented Oct 1, 2023

Hello,

I just found out that the firmware is closed-source.

Would it be possible to provide it as a dynamic library with a corresponding interface contained in a header file?

That way we would be able to interact with the firmware and develop on top of it. For example, you could provide us with a function to add a function pointer to the list of procedures that need to run when logging.

An example code could be:

string readVoltage() {...}

firmware.log(&readVoltage);
firmware.log(&addStuff);
firmware.start();

I really think this would improve the usability and extensability of the product while not divulging the information you want to keep closed-source.

Thank you!

@gigapod
Copy link
Member

gigapod commented Oct 27, 2023

HI @atabou,

We would love to get to the point to support this - its a goal to provide an SDK/external access to the firmware framework we've developed. But we're pretty far away from delivering this solution - or understanding all the technical requirements.

If you have any particular sensor, or other more definitive functional set needed, we can implement that fairly quickly.

For what it's worth - some extensibility uses we see near term include

  • Log values from a GPIO pin
  • Log value sent to the datalogger via an UART connection
  • Log values read from a BLE device

Not the immediate answer you're looking for (SDK), but if you have any other ideas please let us know.

Regards,
-Kirk

@gigapod gigapod added the enhancement New feature or request label Oct 27, 2023
@MarekJar
Copy link

MarekJar commented Nov 3, 2023

Greetings,

Would it be possible to add support for Atlas Scientific modules?

They use a common framework, which is fairly simple and uses common commands, with parameters depending on the sensor type.
https://atlas-scientific.com/embedded-solutions/
They also have a C library, which can be included.

The sensors can be configured to UART or I2C. We are mainly interested in the I2C solution, since this can be linked to the Qwiic bus, already present on the DataLogger board.

The communication protocol uses ASCII over I2C, which is very well documented.

Please let us know if this is possible.

Best regards,

Marek J.

@edubu
Copy link

edubu commented Dec 23, 2023

Hello All,

I also would like to add some change myself but the firmware is closed-source. The BME68x with Qwik connect is automatically identified by the datalogger and is super convienient to use. Although, it only returns the humidity, gas resistance, and pressure. It is commonly used along with Bosch Proprietary Software to measure the (IAQ)Indoor Air Quality. To do this, I would need access to the source code to add the https://github.com/boschsensortec/BSEC-Arduino-library to the code. Otherwise, there is no way to retrieve the IAQ using this board and sensor together which removes half the capabilities of the sensor.

Is there a way you can add this or give me instructions on how to implement this? I would be interested in contributing to add this functionality. Would probably be better as an optional add-on since bsec seems to consume RAM and ROM quite heartily.

Thanks,
Elliot

@gigapod
Copy link
Member

gigapod commented Jan 3, 2024

We'll take a look at this for a future release - the implementation / integration of this library into the framework looks straightforward enough. As noted, the ROM/RAM could be a concern, but we need to give it a try first to determine a path forward. But we'll take a look.

@daz10000
Copy link

I understand you wanting to keep it closed. It might be worth nothing that somewhere in the docs at top - I spent some time trying to help someone troubleshooting #32 and spent 30 mins looking for the source to see if I could understand why it was happening.

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

No branches or pull requests

5 participants