I have been looking for a wireless chip for an (ultra) low power Wi-Fi interface for our embedded products.
I was surprised to find Broadcom actually offering a development environment so I joined up today.
The software structure seems well thought out, but there doesn't seem to be a roadmap as it were for integration of the BCM43362 chip and its successors.
If I want to have a Wi-Fi interface in my products it's got to be 5% of the total BOM, not 50% and and likewise in terms of space requirements. A quick glance it the SDK shows its not unfeasible to connect the BCM43362 to the uP of my choice but a search of the Broadcom site for BCM43362 comes up with three links (2 news, and one to Wiced), that's right, no data sheet, sample Gerbers etc. No roadmap for the device family. When I try to get a handle of pricing all I can find is a listing as an un-stocked part with a 5000 MOQ from one supplier.
The more questions I pose, that darker the picture gets. And I can see it all leading to me being told, you should have just used one of our "module partner" modules!! to which the answer is No, because they are too expensive, too big, too power hungry, don't do what I need them to do, are single sourced, and only save my 10% on the FCC tests I'll have to have done on my product anyway.
Someone please get back to me and tell me I've got it all wrong.
Can you please share why is the microprocessor you have chosen is unfeasible for connection to the 43362?
Is it the lack of resources or interfaces?
Can you describe the features that are missing from the 43362 that you wish to see filled in our roadmap?
I think you misunderstood me, "not unfeasible" means basically, is feasible.
> Can you describe the features that are missing from the 43362 that you wish to see filled in our road-map?
If I can get access to the road-map for the device family and the data sheets for the relevant parts EOL projections, costing, lead time info etc, maybe I can tell you what is missing. I guess I would want a flexible serial interface [1~4 wire] to enable "very" fast inter-chip transfers compared with processor speed trends, small uP IO is still in the stone age.
But most of all, what is lacking is the ability(for us, pion customers) to put the user app on the 43362. The chip we are currently using has this ability, but we have to pay 13K a year (every year) for the privilege.
In the internet of things, ultra low power is a real requirement. You won't achieve this if you have to use an extra processor as a glorified software wrapper.
Have you downloaded the SDK? I think the best way for you to figure out if it is what you need is to download the SDK and purchase the evaluation board so you could play around with the code snippets.
The SDK also comes with documentation including the schematics.
If you want to program right on a Broadcom Wi-Fi chip, I suggest you wait for WICED SDK 3.0 (coming real soon now) which will include support for the BCM4390. http://www.broadcom.com/press/release.php?id=s767775
Note the 43362 has a 4-bit 25MHz SDIO interface and a 48MHz SPI interface, so plenty of 1-4 wire serial interfaces to talk to your stone age micro. Unless you are willing to buy large volumes (>50-100k), the NRE required to build & test your own module is simply not economical. There are a number of suppliers that manufacture WICED modules (with and without an antenna) in sizes starting at 9x10mm. See the link here: WICED Wi-Fi Partners
first of all regarding modules. On the whole they add just another layer of abstraction, add yet one more microprocessor and PCB, don't talk in one the our in house standard ways which may require yet an extra $1 micro to translate the interface and finally are usually too big in some dimension to fit onto our standard RF interface riser.
>If you want to program right on a Broadcom Wi-Fi chip, I suggest you wait for WICED SDK 3.0
This sound like very good news!!
Any chance I can get hold of the data sheet?
What compiler will it use? (The chip we are currently considering it tied to Green Hills (a great company, but a hefty price))
Undoubtedly Broadcom would not release the register map for the part, but would supply a binary HAL module/API. How long would Broadcom support bug fixes for this HAL module/API? How long would the BCM4390 be on the market? and typically typically how long from EOL to last order?
We would typically be looking at 5~10K pcs a year.
Please think of MacOS and Linux users in preparing to release 3.0. Also, any chance to integrate more modules, from USI for instance, in the release?
I am looking forward to it. I think the WICED SDK is the best cross-development toolchain you can wish for.
Wi-Fi is a complex protocol and to provide secure data transfer from one endpoint to another across the Internet requires a large amount of software across multiple devices to work in unison. At the end of the day any Wi-Fi enabling solution will have a Wi-Fi radio connected to a well-resourced microprocessor that performs all the required networking activity which may then be connected to another smaller microprocessor that performs the application specific activity. Pushing the networking software from one microprocessor to another doesn't save power however multiplying the number of microprocessors you use can increase cost and, depending on the software, may increase power usage.
Some solutions have the microprocessor "hidden" in the package or module while others have the microprocessor explicitly external to the Wi-Fi radio. WICED supports both those options and, unlike other solutions, permits you to select the microprocessor, RTOS and network stack to provide a development environment that best suits your existing preferences or company resources. This flexibility has allowed our customers to create their own custom module to fit particular form factors and has enabled module vendors to produce Wi-Fi modules that are smaller than 10x10mm.
Being one of the largest, if not the largest, provider of Wi-Fi chips in the world contained in most smart phones in the world and 80% of all access points in the world you can allay your concerns about part availability or obsolescence.
Version 1 of the WICED SDK only had support for an older 4319 chip however we have updated that with the newer 43362 which is cheaper, more power efficient and offers more features. We still support our customers using the 4319 and we have helped them design their future products with the 43362 which was trivial because of the abstractions provided by the SDK. Not a single line of code needs to change in the application to move from using the 4319 to the 43362 or from the 43362 to the chip that will replace it.
You mentioned very fast inter-chip transfers, what transfer speeds are you looking for? A WICED solution using a Cortex-M3 running at 120MHz can transfer over 27Mb/sec of TCP throughput and 40Mb/sec of UDP throughput. The inter-chip transfer speed far outweighs the ability of the microprocessor to process the data being transferred.
Achieving the lowest power is a system problem and you cannot simply take the sleep/standy power for Wi-Fi solution X and compare it to Wi-Fi solution Y to determine which solution is best. As I mentioned earlier someone needs to deal with the software required to make Wi-Fi, TCP, TLS, etc work and to achieve the lowest possible power the Wi-Fi solution must be able to understand the requirements of all those protocols (and more) and, from a systems perspective, allow the Wi-Fi radio and supporting microprocessor to sleep as long as possible without losing state. If your device is mainly a data sampler with relaxed timing requirements you may achieve lower power by turning the Wi-Fi radio off completely and waking periodically to sample an input before sleeping again. Once per hour or day or week you can turn on the Wi-Fi radio and send the data to a remote server. If you need to upload data more frequently turning off and rebooting the Wi-Fi radio may actually use more power than putting it into a standy mode and retaining connectivity with the AP.
If you provide more details about the requirements of your device we will be happy to assist you design WICED as your Wi-Fi solution.
Thanks for the long answer Nicholas,
Crux1: before we pursue any other issues, is Broadcom really in a position to commit to low end customers. I have in the past worked in a company where one of our business units (~50 people) disappeared overnight (literally) when Broadcom axed a multi-core VOIP chip product line. I have personally been had a bad experience with CSR (another giant like yourselves) with their External Flash based Bluetooth products.
Crux2: Our products are deployed in some major food/transport industries who rely on our products working for longer than a fixed servicing period (were talking battery life here). Until recently we have developed our own wireless interfaces in order to guarantee this. We have introduced a Wi-Fi product using a module (SIP) with an AT-command interface. To get two months usage we have to restrict the interface ON time to once every 10 minutes, basically rebooting everytime. That same AT interface offers save-config, sleep, wake restore-config functionality, but we have experienced long delays (up to 200ms) due to "house keeping" from the save-config, sleep commands until the device goes to sleep. On the same device with the app inside the module the entire process can be forced to take about 20ms max, thus ensuring 6months life with a 10 second polling interval. The tool cost for us to put our code inside the module is 13K per year (every year) and that reoccurring cost is making us rethink.
Now. I do completely comprehend the nature of the API abstraction over the high serial interface which WICED incorporates, but having the option force a fast clean shutdown by means (in essence) of directly accessing the radio is basically a must in our book.
P.S. If what Jason Crawford has said
>If you want to program right on a Broadcom Wi-Fi chip, I suggest you wait for WICED SDK 3.0
is accurate, yes I want to know all the details.
WICED is a major Broadcom initiative to provide solutions for the rapidly growing market often referred to as the Internet of Things. The nature of this emerging market necessitates a solution that can scale to a large number of small customers, each one building a small part of the new era of connectivity where the number of devices connected to the Internet will grow by many orders of magnitude and the next big thing can come from anywhere. Broadcom recognizes this and is committed to enabling all customers with a connectivity solution that is simple to use and requires a minimum amount of direct support. The very best thing a customer can do to receive the greatest amount of support is to use as much of the pre-built functionality found in the SDK as is possible and to avoid deviating from the build system. If you find a problem that can be readily reproduced on our standard hardware by uploading a simple application we can drop into our SDK then the support team can find the solution faster than if you had your own custom hardware with a heavily modified WICED code-base that has been ported to another RTOS or network stack.
To put it simply, WICED is not going to disappear anytime soon and if you stick to using the WICED API your product will be more readily supported and will also be best prepared for new SDKs and new Wi-Fi chips.
Our goal for this new website is to grow a community where we can all work together to help create the next era of connectivity.
Not being completely aware of your current design but rather than rely on an external microprocessor to communicate with a Wi-Fi SIP with an AT command set it may be possible for you to run the tasks of the external microprocessor on the internal WICED microprocessor. We currently support STM32F1, STM32F2, STM32F4, and SAM4S microprocessor families and are actively working on expanding that lineup with microprocessors from other vendors as well. The software design in the WICED-SDK allows you develop your application on one microprocessor and by changing your build string deploy on an alternate microprocessor. I am unaware of any other freely available development environment that offers that flexibility.
That raises another point you mentioned which is that of cost. The WICED-SDK is, and always will be, free of charge and includes everything you need to compile, download and debug a WICED application. It also includes a licence to use ThreadX and NetX/NetX_Duo in your product which are a commercial RTOS and network stack widely used and respected in the embedded community.
I would recommend getting a development kit and start experimenting to see what's on offer and test the sample applications. This may help you decide whether you should continue exploring WICED as a solution for your product and may even give you ideas for other products.
One thing to note is that some of the API will change when moving from 2.4.0 to the upcoming major 3.0 release. Between major releases the API is frozen.
Nicholas, Jason, Dean,
thank you for your input.
Please advise me as to which distributor in Japan would be the best to contact to obtain information on the
BCM43362, BCM4390 etc product line.
Also, regarding the 3.0 SDK.
This will also see the release of new hardware utilizing the BCM4390 chip, yes?
If so is it possible to an advanced order in?
When is your best estimate for the release date of the 3.0 SDK?