I know this question has been asked here before but I have not seen many answers to it... maybe I get lucky now.
How hard is it to add WiFi functionality to the MCF52259 MCU?
You might want to be a bit more specific in your questions, the answer is "exactly as hard as any other processor".
We have wifi support with several vendors using MQX and one of the WiFi Tower cards.
Take a look at the MQX releases (latest is always recommended). The Redpine TWR card found here
The driver for this card and I believe some labs are in the MQX tree for the 52259.
We also have support for the GainSpan module and more coming soon.
As always two very important links to help you get going quickly with our MCU portfolio.
Tower Web Page for Rapid Hardware Prototype: www.freescale.com/Tower
MQX Web Page for Rapid Software Development: www.freescale.com/MQX
And if you are looking for people that might have tried to do this before... Of course this forum is a good site but check out:
Hope this helps
Since the M52259 also has USB Host it is worth noting that there are many USB WiFi modules available that could potentially be used rather than needing an on-board module.
mjbcswitzerland wrote: Since the M52259 also has USB Host it is worth noting that there are many USB WiFi modules available that could potentially be used rather than needing an on-board module.
Except that in most cases the necessary drivers are available only for Windows in binary form. Where drivers are available, porting them to MCF52259 would be extremely difficult if not impossible.
Who said anything about easy...?
However it shouldn't be so difficult.
1) PC host drivers have little to do with embedded host drivers. A host driver is needed but this is valid for any interface and protocol.
2) USB Ethernet is a standard USB class (EEM - Ethernet Emulation Model). USM WiFi modules built on the standard class should be fairly compatible - in comparison, the on-board modules tend to use proprietary protocols and so each module needs its own unique driver.
3) Using a USB analyser with class decoder allows quite easy and efficient development of such protocols, even when there are some manufacturer-specific extensions; when not documented, a comparison with the standard windows driver operation (for instance, what is sent when configuring the module) allows some reverse engineering where necessary.
4) The same principle is true for various USB sticks (Bluetooth, radio, etc.). Such devices are very small, available at very attractive prices and can then be interchanged at the USB plug without the need for board redesigns.
One other consideration is that all the wifi modules I looked at had a TCP/IP stack and some had DNS, Telnet and http built it. For simple applications this is ideal. On the other hand, they cost tmuch more than a USB dongle.
This is correct - there is no standard WiFi module.
- Some require a library to be installed in the SW (the Coldire would in this case also do the WiFi stack work - usually delieverd as a binary with some API interfaces which need to be polled and used to configure, transmit and receive. They then work with standard Ethernet II frames. This may then also occupy 100k..200k of Flash on the chip. Personally I would keep clear of these since the ones with integrated WiFi stack are more flexible and not any more expensive (eg. if you want to change processor and the manufacturer doesn't have a library for the new processor they request a development fee for it...or they may develop it for you in exchange for a big order of the modules...).
- Others have the WiFi stack on the module with SLIP protocol and AT commands (like using a serial modem). The CPU needs to do SLIP and the TCP/IP stack. This is probably the closest to a standardised solution.
Some have a proprietory interface solution.
- Others have the TCP/IP stack integrated so the interface is like an API interface - requires the least code space on the Coldfire and probably most efficient but royalties for the TCP/IP stack are in the WiFi module price and no chance of changing anything at the lower levels (if the TCP/IP stack is IPv4 only and you need to add IPv6 dual-stack you are potential in trouble). These can be compared with the quite popular WizNet modules used to simply add Ethernet TCP/IP capability to a simple processor.
The Tower Kits are presently available with the Redpine module:
- SPI or UART with serial SLIP interface - TCP/IP stack needs to be in the Coldfire. There are other Redpine modules with TCP/IP stack but the one chosen for the module is the best choice for developers since the internal TCP/IP stack would be far to restrictive - great for a few quick modules that need to be built but less for development projects. This module misses SDHC interface which would be better for the Kinetis, for example.
and with a GAINSPAN module:
- again SPI and UART (UART is however slower than the Redpine one). I think that the module includes a TCP/IP IPv4 stack that can be turned on or off. Again it is missing SDHC mode so can't be put into an SD card slot (there are others than can be plugged into an SD card slot which is also quite a nice solution).
Therefore one always has to chose a module and stick with it since the design is very module oriented.
P.S. I still like the idea of taking a development board (or existing product) with USB host - going to the local PC store and buying a Netgear 54MBit WiFi USB adapter for about $15. The risk is of course that the products change every couple of months and they don't care about interface compatibility, but the internal modules are also far from perfect since they lack and standardisation at the user's interface....
P.P.S See the following video showing a Cortex M3 with USB host using a standard minature Bluetooth module for a PC - as the developer says - they simply reverse engineered it...
I need to add WiFi to the MCF5225x and have been looking at Redpine, but I was also considering trying to connect a consumer wi-fi/USB adapter as suggested here. I'm not sure however if MQX supports EEM. As I understand it, this is a subclass of CDC which is supported. Does anyone know if EEM is supported? I would think that it would need to tie into the RTCS stack somehow, right?
Retrieving data ...