drazen
Isn't situation same as with Bluetooth with HCI mode where complete stack must be implemented in PIC? For Bluetooth this is quite a lot of code and WiFi is much more complicated.
I don't think Bluetooth it's as extreme as WiFi. The HCI layer already does quite a bit work. From my shallow research into the subject, it appears the most of the FCC compliance such as the FHSS was placed the module. It's mostly the higher level code that needs to be implemented on the PIC such as connection management and profile support(HID, SPP, etc). The Microchip starter kit uses the DotStack Bluetooth stack and it's fits quite well on a PIC32 with 256KB of flash even with optimizations turned off. (The DotStack is a precompiled lib, but the application specific part still needs to be written.)
drazen
I suppose that PC WiFi modules only have PHY and everything else is in PC driver.
That's what I initially though, but it doesn't appear that way otherwise their wouldn't be a need to upload a large firmware every time the device is powered on. It's possible that part of it is a programmable logic controller instead of a traditional MCU. I would see why a company would want to go that route so that they can update the hardware just by releasing a new device driver. Kind of like how Intel moved to programmable microcode after the infamous floating point division bug.
drazen
When wireless module has SPI than it means (mostly) that most of stack is placed into intenal MCU. For example Bluetooth modules have some ARM ticking on 200MHz doing job. With quite a lot of memory.
That's kind of the issue I saw with the Microchip solution. Why would you want to have a low end $5 MCU controlling a $30 Wifi module with it's internal MCU that blows away the main processor in terms of capabilities?