Pending v1.0 release and potential sub-moduling. about nimble-arduino HOT 14 CLOSED

Version 1.0.0 released!

from nimble-arduino.

You will also need to open an issue in arduino github: https://github.com/arduino/Arduino/issues pointing to this repo. But yes, that's about it.

from nimble-arduino.

I don't know if it fits here but is there a plan to publish this library to the Arduino library manager? I think this would tremendously expand user base and as a result - improve the library thanks to more testing.

from nimble-arduino.

Yes this is planned. If I’m not mistaken as soon as I slap a release tag on, the library manager should pick it up automatically.

from nimble-arduino.

Looks like arduino library manager doesn’t work with Submodules so I’ll test with subtrees and see if that works.

from nimble-arduino.

@h2zero a github action or a travis job can pull those submodules, perform some code quality checks and unit/compilation tests then create the release tarballs for you

on push/pull request = perform check + tests

on tag = perform check + tests + create tarball

from nimble-arduino.

@tobozo that’s a great idea, thanks! I’ll look into that. I’m not very familiar with Travis yet, good opportunity to learn more about it.

from nimble-arduino.

it's probably the worst implementation ever but here's a travis example I'm using to get arduino-ci to compile a few test sketches (see before_deploy and deploy) and create a tarball, a bit useless since this project doesn't have submodules, but still a valid example since travis automatically performs a submodule update.

if you plan to use a github action instead, the upload-releas-asset action is a good start

from nimble-arduino.

Thanks @tobozo, I'll give that a try when I get some time.

from nimble-arduino.

I just came here to express my deepest gratitude for making this library. BLE resource consumption is currently one of the biggest pain points IMHO.

One thing I'd consider an improvement still would be the switch from std::string to String throughout the API. Is this something worth discussing?

from nimble-arduino.

@everslick This would not be an improvement :-) I personally try to never use arduino Strings, ever. Here is an interesting article why that is the case: https://majenko.co.uk/blog/evils-arduino-strings

from nimble-arduino.

@lknop All that is said about String in this article, is also (and even more so) true for std::string. String has some optimizations for MCU platforms and I'd expect some improvements in memory consumption by replacing std::string with String. Besides it would improve Arduino compatibility, because one would not need to convert between types so often. String is great when used wisely - most important: preallocate enough mem with resize() before concatenation and pass String objects around via reference or const reference whenever possible. So avoiding String just because will very likely increase your codesize. Look at the implementation of String and you will see that it is a very well implemented class. Just my 2 cents. ;-)

from nimble-arduino.

@everslick point taken, I just thought that it's in the same ballpark so that would give little advantage. I never got to analysing the String implementation, that's a good idea for a long evening, maybe I'll find time for it this weekend, thanks.

Nevertheless I think I read that @h2zero 's main interest is the esp-idf implementation and the Arduino port is secondary, so I assume it would not be welcome to let those two drift apart, but I may be wrong. I wonder if you are right that it would really be less heap-hungry to use String rather than std::string.

from nimble-arduino.

Hi @everslick, I agree that using String would be better in Arduino. The problem with is it's not usable outside of Arduino.
This library is a mirror of the esp-idf library and changing this to use String here would break that relationship and would need to be maintained separately. That is something I'm not too keen to do. I think it's best to stick to the STL as much as possible.

from nimble-arduino.