Aug 20, 2013
03:38 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 20, 2013
03:38 PM
- The WICED
Labels
- Labels:
-
SPI
- Tags:
- abstraction
- abstracts
- communications
- cortex-a
- guidance
- https
- linux
- networking
- peter
- processor
- rtos
- running
- seperate
- wiced
2 Replies
Anonymous
Not applicable
Sep 04, 2013
06:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 04, 2013
06:17 PM
The goal of WICED is to solve the problem of connectivity with all the related complications for embedded devices, that is, devices that cannot support Linux.Linux already offers all the functionality provided WICED.What do you hope to gain by porting WICED to Linux?
Anonymous
Not applicable
Dec 30, 2013
06:04 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 30, 2013
06:04 PM
Good point about what is to gain by using WICED versus Linux. I was about to try and port the WICED SDK to Raspbian Linux (custom linux distribution for Raspberry Pi EVB which is based on the BCM2835). But, you got me thinking. Here are some thoughts on what may be to gained:1) O/S independence for your application code (by using the WWD (WICED WiFi Driver) layer). Then, later on, it would be easier to migrate from Linux to an RTOS of your choosing (FreeRTOS and ThreadX are available by default).2) Looking at "..Wiced-SDK-2.4.0WICED-SDKDocWICED-SDK-Software-Stack.pdf": a) Is OTA ("Over The Air" upgrade) suppored with the standard open source Broadcom Linux driver (which the open source community turned into a "brcmfmac" driver for SDIO and USB interfaces)? b) Do the following WICED APIs (not sure yet if they work through WWD calls) have equivalent Linux APIs/calls?: Note: I know Linux does have APIs and drivers for all of the following. But, you may have to do extra work to use APIs different than those defined in the WICED SDK? 1. MCU powersave 2. Wi-Fi Powersave (I have heard that the Linux driver has issues with low power stuff, maybe it has been fixed already?) The WLAN chip requires an external 32kHz sleep clock input during powersave. Platforms that do not support Wi-Fi powersave (per the table above) are not capable of driving the WLAN sleep clock. An external 32kHz clock is required for these platforms. 3. I2C API 4. ADC/PWM API