BT_LIB and issues

[rudi ;-)]

hi guys,

Is there any reason that we can not report any problems?

bt_lib.png (25.13 KiB) Viewed 8930 times

please open the LIBS to open source.


best wishes
rudi

[kolban]

Reading this post, http://www.prnewswire.com/news-releases ... 51127.html

One could be led to understand that Espressif may have licensed some portions of the Bluetooth software stack from a 3rd party provider. As such, under the terms of the contract, the intellectual property provided by that 3rd party may very well be object code only.

If that is the case, I for one am ok with that. I would rather have a bluetooth environment with an exposed API that I can program against than no-bluetooth at all.

If you wish to go with an Open Source bluetooth implementation, what you may wish to research is whether or not the raw radio interface supplied by Espressif is exposed for ultra low level programming and then undertake an open source project yourself to port an alternate bluetooth stack (if possible) that you have full access to.

[rudi ;-)]

Reading this post, http://www.prnewswire.com/news-releases ... 51127.html

One could be led to understand that Espressif may have licensed some portions of the Bluetooth software stack from a 3rd party provider. As such, under the terms of the contract, the intellectual property provided by that 3rd party may very well be object code only.

i know -
it was my self to post this in the news - at this time i was very happy about
https://esp32.com/viewtopic.php?f=10&t=378

If that is the case, I for one am ok with that. I would rather have a bluetooth environment with an exposed API that I can program against than no-bluetooth at all.

edit ( forget to include ) :

i confirm this too, but then please,
we need the full uncensored api code in the esp-idf
and not only parts or diminished or interna creation versions on it

i ask me, why we can not create "issues" but we can make PR
with which "source" knowledge we can do this if we have only the LIBS

If you wish to go with an Open Source bluetooth implementation, what you may wish to research is whether or not the raw radio interface supplied by Espressif is exposed for ultra low level programming and then undertake an open source project yourself to port an alternate bluetooth stack (if possible) that you have full access to.

yes - this will be my next way, ( edit : BT )
but then i use other product ( edit : BT ) from now
sry -
but there is no way to work productive
if there are still lib fixes sucks extremly long time!

the at example is not working - not compiling.
honest - i do not understand the long time for it.

and my emotions are cooking here not allone.

[madscientist_42]

Reading this post, http://www.prnewswire.com/news-releases ... 51127.html

One could be led to understand that Espressif may have licensed some portions of the Bluetooth software stack from a 3rd party provider. As such, under the terms of the contract, the intellectual property provided by that 3rd party may very well be object code only.

Bingo! If you look at the press releases for the ESP32, you'll note a mention of them using a RiveraWaves CEVA core for the BT functions. That equates very much to a closed blob there. IF you have access to CEVA's IP yourself, you can't release it, but you can build your own build of the stuff, without the virtual HCI interface stuff- or add your own virtual HCI. But you won't get to distribute that...most likely ever. CEVA is...unlikely...to allow that code out.

If that is the case, I for one am ok with that. I would rather have a bluetooth environment with an exposed API that I can program against than no-bluetooth at all.

Yep. That's my take there as well.

If you wish to go with an Open Source bluetooth implementation, what you may wish to research is whether or not the raw radio interface supplied by Espressif is exposed for ultra low level programming and then undertake an open source project yourself to port an alternate bluetooth stack (if possible) that you have full access to.

Any BT stack work from the HCI layer edge down to the silicon would entail you attaching a new BT RF unit off of the SPI, SDIO, or UART edges, if you're going to make it all FOSS. Now, the bigger question would be is it in the from-the-HCI edge down that the problem REALLY exists, or is it in the stuff from the HCI edge UP- which IS open source. It's BlueDroid. Which...heh...is a bit craptastic, really. It works for most values of that concept for Google- but it's still got some real issues all the same. IF you have a stack that's OSS (Say the Netgraph interface for *BSD, for example, re-worked slightly to use the virtualHCI interface...) then knock yourself out. If it's better than what we got, I'm fairly sure Espressif would incorporate it into the IDF.

[rudi ;-)]

Any BT stack work from the HCI layer edge down to the silicon would entail you attaching a new BT RF unit off of the SPI, SDIO, or UART edges, if you're going to make it all FOSS. Now, the bigger question would be is it in the from-the-HCI edge down that the problem REALLY exists, or is it in the stuff from the HCI edge UP- which IS open source. It's BlueDroid. Which...heh...is a bit craptastic, really. It works for most values of that concept for Google- but it's still got some real issues all the same. IF you have a stack that's OSS (Say the Netgraph interface for *BSD, for example, re-worked slightly to use the virtualHCI interface...) then knock yourself out. If it's better than what we got, I'm fairly sure Espressif would incorporate it into the IDF.

exact!

[madscientist_42]

As for why they don't let you report issues...the problem is...how many of their customers would GET the distinction I just outlined there? Better yet, unless you've got moderately deep understanding of how BT is "supposed to work", have CEVA IP in your possession, or both, how would you KNOW where to report the issue? Is it in the Link Manager or is the fail in the GAP or GATT layer or above? Would you know?

Probably not. So the issues would and should get reported against the IDF and let Espressif determine where the fault lies and correct accordingly. Now, if you've chased it down yourself and KNOW it's not in BlueDroid- you probably could highlight that in the issue report but it's still likely to be, if only for logistics reasons, better to report it in the IDF- since people will look there FIRST anyhow.

[rudi ;-)]

If it were thoroughly considered, it would be irrational to report a lib issues,
Who knows 100 percent where the error lies.

Ok convinced.

Better then to idf the error "show" and espressif can then take care.
The threads run better together.