search

bouffalolab / bouffalo_sdk

BouffaloSDK is the IOT and MCU software development kit provided by the Bouffalo Lab Team, supports all the series of Bouffalo chips. Also it is the combination of bl_mcu_sdk and bl_iot_sdk
Apache License 2.0
371 stars 127 forks source link

WiFi flash and ram memory consumption way too high #212

Open harbaum opened 4 months ago

harbaum commented 4 months ago

WiFi eats a lot of flash and nearly all of the RAM. The resulting flash is unreliable and flashing hangs at flash erase. But more importantly there's not enough ram left for a useful application.

Memory region         Used Size  Region Size  %age Used
fw_header_memory:         256 B         4 KB      6.25%
      xip_memory:      876264 B         4 MB     20.89%
       ram_psram:          0 GB         4 MB      0.00%
     ram_nocache:       18500 B       319 KB      5.66%
      ram_memory:       75752 B       319 KB     23.19%
        ram_wifi:      144016 B       160 KB     87.90%

Also most of the WiFi seems to be closed source and the debug output is a new line/return mess. And finally WiFi and USB host don't seem to go nicely and the system often hangs during boot when enabling both.

Can WiFi be simplified with a few simple examples not depending on a shell and the like which wouldn't be used in real-life-scenarios?

WGR7 commented 4 months ago

It's a dead repo with a dead product. If at least, BouffaloLab could give a good documentation.

harbaum commented 4 months ago

A few days ago I have actually started to migrate my retro FPGA support MCU for the MiSTeryNano to the Pi Pico. I'll continue to support the BL616 but there will be the option to use the rp2040 and probably also the esp32-s2/3. All of these have inferior USB host capabilities and I really like the bl616 ... but the SDK definitely is a problem. Too bad ...

WGR7 commented 4 months ago

Yes, for sure. Seems that BLab has abandoned BL616/618 because they are missing on products BLab page. I'm waiting for esp32-p4 that will have great peripherals, I hope that price can be affordable.

gamelaster commented 4 months ago

@WGR7 BL618/BL616 is still maintained by Bouffalo, together with BL70X/BL70XL.

WGR7 commented 4 months ago

@gamelaster maybe it's true, but doesn't matter because there's no updates on SDK and support is dead.

gamelaster commented 4 months ago

@WGR7 about updates on SDK, yes, those are bit slow recently, but it should be updated in some near time. About support, yeah, that's unfortunate.

harbaum commented 4 months ago

The problem is not the low update frequency. The problem is the SDK itself. E.g. major parts of WiFi and Bluetooth are inside closed source libraries:

bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl808_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m10s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1sbredr1.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btprofile/lib/libbtprofile.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6_matter.a

These contain not only the basic RF functions but major parts of the protocol stacks and even parts of demo applications. According the the bl616 datasheet, it e.g. supports classic bluetooth. I was delighted and expected to be able to add bluetooth HID support to my retro FPGA project to use wireless bluetooth controllers with it. In reality there is one demo that implements audio parts for classic bluetooth. But that needs one specific version of the libraries which in turn lacks other aspects i needed. And since this is all closed source you cannot debug it or even dig through the source code to understand how to use it.

The device seems great and the highspeed USB host is a great thing. But it's nearly impossible to implement complex projects that are not directly covered by the examples.

gamelaster commented 4 months ago

@harbaum this is sadly true, BT/BLE and WiFi is indeed too much packed into blobs for some reason, unnecessary. Also, BL618 doesn't explain all the information about clock and power trees. Previous generation of chips (BL60X and BL70X) were better in this. To other side, BL61X and BL808 were kinda rushed...

O2C14 commented 4 months ago

The problem is not the low update frequency. The problem is the SDK itself. E.g. major parts of WiFi and Bluetooth are inside closed source libraries:

bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl808_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m10s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1sbredr1.a
bouffalo_sdk/components/wireless/bluetooth/btblecontroller/lib/libbtblecontroller_bl616_ble1m0s1bredr0.a
bouffalo_sdk/components/wireless/bluetooth/btprofile/lib/libbtprofile.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6.a
bouffalo_sdk/components/wireless/wifi6/lib/libwifi6_matter.a

These contain not only the basic RF functions but major parts of the protocol stacks and even parts of demo applications. According the the bl616 datasheet, it e.g. supports classic bluetooth. I was delighted and expected to be able to add bluetooth HID support to my retro FPGA project to use wireless bluetooth controllers with it. In reality there is one demo that implements audio parts for classic bluetooth. But that needs one specific version of the libraries which in turn lacks other aspects i needed. And since this is all closed source you cannot debug it or even dig through the source code to understand how to use it.

The device seems great and the highspeed USB host is a great thing. But it's nearly impossible to implement complex projects that are not directly covered by the examples.

In fact, partial source code from Sophgo can be used (for example: https://github.com/sophgo/cvi_alios_open/blob/master/components/ble_host/bt_host/host/a2dp.c ）To replace libbtprofile.a, HID may be implemented. And through this method, I have already implemented LDAC decoding on AI think m61

harbaum commented 4 months ago

To me it seems more like these chips were made for a specific customer with a specific use case (in this case maybe some bluetooth audio application). This has then been implemented by combining all kinds of existing open source solutions. And it looks like this happened in a rush and rather than cleanly integrating different projects they were tightly mixed and modified until the use case was covered. The resulting SDK now consists of lots of components that rely on each other for no apparent reason. This also explains those different closed source bluetooth libs. They also cover specific use cases and are not really generic.

harbaum commented 4 months ago

In fact, partial source code from Sophgo can be used (for example: https://github.com/sophgo/cvi_alios_open/blob/master/components/ble_host/bt_host/host/a2dp.c ）To replace libbtprofile.a, HID may be implemented. And through this method, I have already implemented LDAC decoding on AI think m61

I was able to implement BT-LE HID support. Unfortunately only very few pure BT-LE HID devices exist and the majority is still classic BT. This includes e.g. the 8bit do ones and the Nintendo Joycons and I wasn't able to even isolate the classic BT stuff I'll n the SDK to compile a raw basic application that would allow me to e.g. scan for devices. So I gave up. A few weeks later I started using WiFi and ran into very similar issues. Trying to connect to an AP gave nul pointer assertions in the closed source part which were eventually resolved by randomly poking in the proj.conf. Once it was able to connect it ran out of memory and/or e.g. the USB started to become unreliable. When trying to initiate an AP scan the FreeRTOS tasks stopped working once the scan completed ... I don't even know if wifi and FreeRTOS are supposed to work together.

So while it may be possible to hack around some of these issues I expect to run in similar issues over and over again. That's not useful for an open source project like mine where others are supposed to continue on my work. I already started to distribute patched versions of the SDK and the CherryUSB stack with my project.

I am now porting everything over to the Pico and ESP32 and then people have the choice. I'll keep supporting the BL616 and whenever it looks like classic BT becomes usable or Wifi is stable enough to be integrated this can still be added. For now I use the BL616 as a USB host only and if you want Bluetooth or WiFi you need to use one of the other controllers.

O2C14 commented 4 months ago

I am trying to port BTstack to BL618, and it can now be detected by classic Bluetooth devices, but it cannot be connected. I think this is just a scheduling issue with BTstack.

harbaum commented 4 months ago

Cool. I was once considering giving tinyUSB a try as it had support for ehci controllers.

But for Bluetooth you still need the closed source RF Part inside one of those libraries, don't you? If scanning and active connecting work I might be tempted to give it a try. I already have the whole hid layer working for USB, so adding Bluetooth hid should not be too complex if l2cap is running.

Also WiFi won't work with that, would it?

O2C14 commented 4 months ago

I'm not really interested in WIFI, so I haven't worked on the bl618's WIFI module. I'm doing all this work to realize a complete A2DP application

harbaum commented 4 months ago

But you are still using the closed source library for the low level stuff, don't you?

O2C14 commented 4 months ago

It doesn't matter, only the Bluetooth controller is closed source. I just need to wrap the closed-source API into a usable interface for btstack.

O2C14 commented 4 months ago

image Screenshot_2024-06-19-15-51-40-418_com android se

Porting btstack was successful!, Now it can be connected and other btstack features are being verified.

gamelaster commented 4 months ago

@O2C14 amazing! Will you share your work later?

O2C14 commented 4 months ago

Of course, I am currently organizing the code. Unfortunately, I am preparing for the final exam and may analyze this later

gamelaster commented 4 months ago

No worries. Good luck with final exams!

O2C14 commented 4 months ago

All the code is here:https://github.com/O2C14/btstack_test Only tested under btstack v1.6.1

O2C14 commented 4 months ago

Screenshot_2024-06-22-19-14-02-575_com.android.settings.jpg

I implemented the ldac player with btstack

harbaum commented 4 months ago

That's really impressive. I definitely need to have a closer look at that.

amitv87 commented 4 months ago

MiSTeryNano

You can try the ai-thinker sdk. Only the software MAC layer is available as a static library, rest everything related to wi-fi is open (event the wpa supplicant).

amitv87 commented 3 months ago

New SDK https://github.com/bouffalolab/bouffalo_sdk/tree/0444691f1299ba846324effb347ac083e803eaee

O2C14 commented 3 months ago

New SDK https://github.com/bouffalolab/bouffalo_sdk/tree/0444691f1299ba846324effb347ac083e803eaee

The library of bluetooth controllers included in this SDK is much bigger, so I don't want to use this library

amitv87 commented 3 months ago

New SDK https://github.com/bouffalolab/bouffalo_sdk/tree/0444691f1299ba846324effb347ac083e803eaee

The library of bluetooth controllers included in this SDK is much bigger, so I don't want to use this library

The bigger size may be due to large debug info rather than the code.