-
Notifications
You must be signed in to change notification settings - Fork 918
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
It should be possible to provide the cyw43 firmware from the app #928
Comments
Yes, this has been in the back of my mind and also relates to the implementation of #909 - i.e. it should be possible to pass a block iterator to the driver. Also a cyw43_driver issue, but this is as good a place as any to track |
See also georgerobotics/cyw43-driver#4 |
@usedbytes , one idea which I think would work now is to make the WiFi BLOB its own region of flash and not part of the actual linked executables. Sort of a WiFi blob partition, if you will. You'd need to adjust the flash ending address (assuming you put it at the top of flash to make things nice and simple for you) and add |
Am I correct in assuming that for the Pico W the BT firmware and the WiFi firmware will be a single BLOB, given #1164? If not, would something similar be possible for the BT firmware BLOB too? |
Yes, currently, we have added the bt firmware onto the end of the "wifi" firmware. I guess it's possible things will change before the code is merged but I don't see much sense having it as a separate object. |
Well... for space considerations a wifi-only app or BT-only app could just drop the other one. Maybe by default you just include both, but separating them out at a low level will make it much easier for power-users to shave off a bit of code-storage-space. |
bt goes via wifi, so you need the wifi firmware to use bt. The bt overhead is rather small ~6000 bytes although we might not include this if you're not using bt. We haven't asked for a cut down wifi firmware that doesn't actually do any wifi stuff. |
@peterharperuk Actually, given how potentially useful a Pico BT would be, I vote for a WiFi firmware that does no WiFi, and is just a thin wrapper for the BT firmware. That said, are there any details of how this BT via WiFi interface will work programmatically? |
@samveen I briefly looked at the datasheet for the chip. The way I understand it, for compatibility with older separate wifi/bt chips the chip has separate interafaces to the MCU for BT and WIFI.. But the BT interface has not been hooked up on the pico-W, so bluetooth data needs to be transferred into the chip through the pins meant for WIFI. This means that at least some of the WIFI firmware needs to be present. That said: IMHO the developers should focus on:
and only THEN does optimization come into play. I'm pretty sure you won't run out of pico-code-space right away. |
Wise words.
This is unlikely to happen. |
Pardon for jumping in, as per Pi Pico W datasheet :
|
Right. The datasheet hints at the SPI being commonly used for the wifi connection and the serial connection (like on raspberry pi 3 and -4) for bluetooth. |
This is waiting on the firmware compression work... |
I've been thinking about this. Found a trick to keep things compatible with the current API and make this possible. Add a new api call that has an argument to the firmware blob. LTO will remove the normal firmware if you use the new call and provide the firmware in another way. People doing bootloader stuff can then share the blob between bootloader and app. (e.g. put it in the bootloader, have the app find it) |
I have the setup working where the firmware is in its own section, that is shared between the two builds. With some modifications to the linker scripts, it works fine. With the original linker scripts, it will still work (but each build will contain the firmware blob). The code remains virtually untouched so there is not much to break/test. Pushing this through first requires adding a section attribute to the firmware blob, then requires some customization of the linker script where ideally picowota linker scripts can be based on them. As things progress, I will post updates here. |
Hmmm. Just removing 20 KB (multiple of 512 B) somewhere at the end (sparing CLM) and Bluetooth works, no errors :D Test program uses Pico W LED, that works as well. Test setup: first Pico W as a Bluetooth dongle btattached to Ubuntu 20.04 LTS, Further shaving WiFi firmware might reduce weight even more. But requires testing to be sure, BT will work. And don't know it would be accepted as an official BT only WiFi firmware. I'm sure, not. |
Such blindly removing code might seem-to-work, but the developers will have to take it as a "hint there might be seemingly unnecessary code at the end. No matter how much testing you put this through there might be a weird case that you didn't test that requires that code. I once debugged a situation where Cisco released a "firewall firmware" that wouldn't handle the case packet-with-data comes in, reply ACK is sent, seen by the firewall, but lost on the return to the client. Under normal TCP the client would resend the data and the transfer would continue. But the firewall would block that as "Someone is trying a replay attach, this is a packet from the past I'm not letting that pass! ". Thus the connection would hang. (According to my client: "for some people, some times of the day on SOME providers, but not on others). This is apparently such a rare condition that Cisco missed that before releasing that firewall into the market. That code you dropped might activate for "unprotected WIFI networks" or WPA3-protected networks or .... whatever I can come up with you could easily test. It's the things that I cannot come up with that worry me. The guys with the source can look at their link map and ask themselves: Why did it work for @matsobdev without this code? And then possibly decide: WTF he's right this is "dead code" and can't be reached. Or say: Right, but the standard says we need to support xyz and this is the code to handle that! Yes, it's is not always used, but in some applications it is necessary. And it is logical that @matsobdev didn't hit this code with his simple test. |
I've implemented a bootloader for the Pico W allowing code upload via WiFi: picowota; unfortunately this means having a copy of the WiFi firmware in the bootloader code, and another copy in the app code.
It would be good if there were a way to pass a pointer to the firmware binary to the
cyw43
library(ies), so that one copy can be stored in the bootloader, and the app code can just refer to that.This would be less relevant with #909, but may still be worth considering.
The text was updated successfully, but these errors were encountered: