Smallest Way to Get 802.11 on an Embedded Board

[TheAdmiralty]

Evening, everyone!

Now, I'm sure this has been asked a million times, but I'd just like to at least take a moment to explain what I'm working on and maybe it will be a bit more interesting.

I'm working on building up the control unit for what's basically a GPS-controlled Mars rover.  Four wheels, each with an independent drive motor, GPS and compass for navigation, most likely a PIC32MX or PSoC 5LP (since I'm familiar with the two) to manage hardware control.

The part I'm torn on right now is getting I/O to a remote client in order to do rerouting and manual control.  Our original thought was to make use of some small SBC to host a Linux environment which would A) handle software storage of GPS routes and whatnot, and B) serve an HTML page using NginX to allow anything with a web browser and the password to access controls.  This would interface with the MCU via RS232.  Simple enough.  (Let it be noted that this setup was decided upon for various design constraints from both us and the end user, so the foundation likely won't change.)

My question is this.  We can't put a RasPi on something that might go into production, mainly because of sourcing, longevity, licensing, and all that.  I don't have the time to kludge together an entire single-board computer; if this is the only option, I'll need to do it now because while we have a PCB prototyping mill, it isn't going to be doing BGA or QFN work any time soon, and so it would need to be sent out, etched, and assembled.  Basically, what is the most low-profile, barebones way of getting something running Linux that can interface with RS232, and operate a wireless connection?  Or if there are any other thoughts, anything is welcome!     We'd looked into Intel's little Edison boards, but $70 is an awful lot for all it's doing, and a lot of the same problems still apply.  Google isn't much help for this other than turning up hundreds of kickstarter projects that probably will never even reach production let alone be available for the next fifteen years.

Any thoughts are appreciated!
- M

[langwadt]

Evening, everyone!

Now, I'm sure this has been asked a million times, but I'd just like to at least take a moment to explain what I'm working on and maybe it will be a bit more interesting.

I'm working on building up the control unit for what's basically a GPS-controlled Mars rover.  Four wheels, each with an independent drive motor, GPS and compass for navigation, most likely a PIC32MX or PSoC 5LP (since I'm familiar with the two) to manage hardware control.

The part I'm torn on right now is getting I/O to a remote client in order to do rerouting and manual control.  Our original thought was to make use of some small SBC to host a Linux environment which would A) handle software storage of GPS routes and whatnot, and B) serve an HTML page using NginX to allow anything with a web browser and the password to access controls.  This would interface with the MCU via RS232.  Simple enough.  (Let it be noted that this setup was decided upon for various design constraints from both us and the end user, so the foundation likely won't change.)

My question is this.  We can't put a RasPi on something that might go into production, mainly because of sourcing, longevity, licensing, and all that.  I don't have the time to kludge together an entire single-board computer; if this is the only option, I'll need to do it now because while we have a PCB prototyping mill, it isn't going to be doing BGA or QFN work any time soon, and so it would need to be sent out, etched, and assembled.  Basically, what is the most low-profile, barebones way of getting something running Linux that can interface with RS232, and operate a wireless connection?  Or if there are any other thoughts, anything is welcome!     We'd looked into Intel's little Edison boards, but $70 is an awful lot for all it's doing, and a lot of the same problems still apply.  Google isn't much help for this other than turning up hundreds of kickstarter projects that probably will never even reach production let alone be available for the next fifteen years.

Any thoughts are appreciated!
- M

unless you are going to build hundreds if not thousands I doubt the $70 for an Edison will end up begin a lot

and building you own just moves the longevity problem from the board to the components and the longevity of SoCs
targeting cellphones and tablets is probably not something to rely on

[nctnico]

You can buy a system on a module which are available in many formats and can have guaranteed availability. From >150 units it is economically viable to make a custom design with a SoC from TI or NXP (formerly Freescale). Still you have to count on spending quite some time to iron the bugs from the BSP (Linux kernel + bootloader).

[Harvs]

Given you know PIC32, have you ruled out one of the various Microchip WiFi modules? 

It doesn't sound from your description like it's a very demanding application that couldn't be handled by a PIC32 with a WiFi module that has on-board stack all the way to TCP/IP.  Put your web page on SD or the like.

If you want dirt cheap (with some of the ensuing problems) the ESP8266 is a real contender these days.

[TheAdmiralty]

Yup, something like those ESP8266 modules is what I'm in the market for it seems.  I'll have to find one that can handle an external high-gain antenna.  I'm afraid I just don't have the time to implement an entire network stack from scratch on the MCU itself, or troubleshoot a bootloader setup right now, meaning I'm pretty much stuck with some similar module for the time being.

We're basically taking a project that was already in the design stage, but that's using nothing but off-the-shelf components, some of which are grossly overspec'ed.  My job is basically to take the pile of Arduinos and motor controllers and turn it into something vaguely commercialized, or at least the first iteration of it.  Am working on the electrical job of replacing the $150 motor drive with more reasonable H-bridges at the moment, so I figured I'd outsource this one to the forum for opinions.  Might end up moving hosting duty to a mobile device application after all it seems.

[rstofer]

Microchip provides source for an entire TCP/IP stack that, for certain, works over wire but I'm pretty sure it also supports WiFi.  Their Ethernet Starter Kit is one place to look

I use wired ethernet with the mbed board (LPC1768) and the library provided at mbed.org.  There is a WiFi library

https://developer.mbed.org/components/cat/wifi/

There's nothing particularly special about the (original) mbed board.  I just connected the appropriate pins to an offboard MagJack and the rest was handled by the library (LwIP stack).

None of these will be as robust as running Linux.  You can do that on the Analog Devices Blackfin (uClinux).  That's a very fast chip (600 MHz) and, of course, since uClinux is derived from Linux (leaving out memory management), the entire network stack is available.

[Mr.B]

...I'll have to find one that can handle an external high-gain antenna...

The ESP8266 modules sold as ESP-07 and ESP-07s have a U.FL connector for an external antenna.
I have used them very successfully with reasonably high gain antenna. (12dBi Omni-Directional)
They will support your serial comms requirements and have enough I/O for SPI or I2C.

[westfw]

We can't put a RasPi on something that might go into production, mainly because of sourcing, longevity, licensing, and all that.

The ESP8266, and even most x86 motherboards have the same longevity problems.  An RPi might be as good as anything else...
The various US-vendor 802.11 modules (TI, Atmel, Microchip) might be slightly better.  And harder to use.

[krho]

Why would ESP8266 had a longevity problem. The company is promising a 12years for both https://espressif.com/en/products/longevity-commitment and the new ESP32 brother that also has BT.

[Scrts]

ESP8266 and CC3100.

Is CC3200 that horrible and not worth mentioning?

[TheAdmiralty]

Yep, at this point we've settled on using an ESP07 module as an access point that will communicate with a PIC32 via RS232, w/ a pair of jumpers to allow an external serial connection to the ESP for configuration.  Thanks for all the thoughts - will keep an eye on this, still open to anything else up until the point this thing is actually soldered down and running.  Debating between a PIC32 and a Cypress PSoC-5LP, but that's another matter entirely.

Is there any information available on the pinout of these things?  I've ran into the original in Chinese which is no use to me, and a handful of tutorials on various websites.

[Mr.B]

http://www.esp8266.com/ is a community effort that has a world of information.
There are translated datasheets for the modules that contain the actual ESP8266 chip.
Some of them are a bit lacking, however the community knowledge makes up for it.
A particular warning about the ESP-07 module itself: Some modules have the two I/O round the wrong way for the GPIO that handle I2C.
It is not common, but does seem to happen in some batches/suppliers.

Edit: I am not sure why you require a PIC32...
The ESP8266 is a very powerful MCU for the money.
If you need extra GPIO, a GPIO expander is easy to implement.

[TheAdmiralty]

@Mr. B - Long story short, the project manager that's handling this is a software engineer who originally specified a netduino to control this entire system through a bluetooth low-energy module (both of which were handed to us with a 'take this and make it work' sort of thing), and is going to be generally unreceptive to alternatives to his own design.  We've since explained that there would be no supply chain and BLE isn't the right solution, but I'm putting whatever wireless system we'll be using on a mezzanine connector in the event of him turning around and trying to specify something else... I'd rather not have most of the central processing on the wireless module for that reason.  Once it approaches actual production we can look into it.

[mac.6]

"Production"and "wifi" in the same sentence is a call for FCC certification.
So better buy an of the shelf module that is already certified. This will save you a lot of time and hassle...

[nctnico]

Also have all the electronics on one board. Cobbling a solution together with multiple boards is an interference nightmare waiting to happen.

[Howardlong]

ESP8266 and CC3100.

Is CC3200 that horrible and not worth mentioning?

cc3200=cc3100+arm mcu
They are essentially the same thing.
cc3100 has an internal core not exposed to user program, while cc3200 has one rom core and one fully programmable flash arm core and peripherals.

When I last used the CC3200 about 2 years ago, I found it a nightmare to get working on my own board, even before turning on the radio. The problem I had was getting the main and secondary oscillators to even start up, even with the exact parts spec'd on their BoM. I could get everything to work on their own Tiva Launchpad boards, but I gave up in the end with my attempts after no luck and three re-spins. I suspected it might be to do with the SMPS layout, although my layouts were solidly based on their reference designs and use the same BoM parts, but after burning a lot of time and energy on it I discounted it as an option. There is quite a bit going on that's hidden from you during power up, so debugging options are predominently limited to empirical scratch and sniff methods.

[Howardlong]

Another option if you're already familiar with the PIC32 might be the upcoming PIC32MZEF Curiosity board (DM320104)... if you have the temerity to suffer the Harmony framework nonsense.

I've had two on order for a month from MicrochipDirect, they still have not shipped despite a ship date of 21 Sept.

Be aware that typically the WiFi throughput of these devices is limited.

I managed a maximum UDP throughput of about 14Mbps with the CC3200, but only about 5Mbps with the 802-11n MRF24WN0MA WiFi module attached to a PIC32MZ and an AP two feet away. Some of this is inherently due to the device's own limitations, and some of it is a bottleneck managing the SPI interface, exacerbated by the overhead of the Harmony framework.

Be aware of throughput limitations for all WiFi modules at this level, they might talk about bit rate at the 802.11 interface, but finding real world practical IP throughput expectations is much harder.