CT and AP firmware not allowed beaconing in adhoc mode

[Ben Greear]

On 06/26/2014 12:43 AM, Adrian Chadd wrote:
> On 26 June 2014 00:40, Yeoh Chun-Yeow <yeohchunyeow at gmail.com> wrote:
>> Not possible for all the modes to be supported in one single firmware?
>
> It (mostly) is; it's a question of time, effort and resources.
>
> There's a size limitation to how much code and data you can squeeze
> into the firmware. Is it possible to structure the firmware in a way
> that gives you one source tree for multiple firmware builds, with
> different features on and off? Quite so.
>
> That's just not how it happened inside of QCA. When I was working
> there on the ath10k chip bringup, there indeed was one branch to do
> station, adhoc and AP mode. That changed shortly after I left for
> reasons I don't quite know. I'm still trying to .. well, figure out
> how to try and repair that damage.

In my firmware, with 37 vdevs, I have maybe 2k of RAM left, but
55+k bytes of instruction ram (ie, where the program code can live left).

So, there is plenty of room for more code, and most people can get by with way
less than 37 vdevs, which saves both RAM and IRAM.

I am steadily improving RAM usage in CT firmware, mostly be naturally
packing structures, using bit shifting instead of uint32 for booleans, etc.

So, the code size is not the problem here....  Time and resources and the
fact we cannot share dev efforts with other developers due to NDA issues
is the main problem.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com