Close
0%
0%

RPi WiFi

Fast RPi WiFi without USB

Similar projects worth following
WiFi on a Raspberry Pi using the HAT connector and an ESP8266. The goal of this project is to add WiFi to the Raspberry Pi Zero while keeping the USB port free for devices or OTG connection to another host.

The instructions below tell how to connect a $2 ESP-12F module to any Pi that takes HATs with a small amount of soldering, and how to get it working under Raspbian. There are KiCad projects in the sidebar for inspiration and a starting point for ESP8266 SDIO projects.

When the Raspberry Pi Zero was announced, a significant chunk of the hacker world dismissed it for having the same fatal flaw as the other Pis: only one USB host port for high speed I/O.

Network connectivity is a major reason that people base projects around a Pi or other embedded Linux board. The 2B and B+ both have onboard USB hubs providing 4 USB ports and an Ethernet interface, making it easy to connect to a wired network or add on a USB WiFi adapter. But the A+ and Zero do not have this luxury. You need an external hub to get the same functionality, which compromises the size advantage and makes for an unwieldy cable mess.

That's unfortunate, because other embedded Linux boards in similar form factors are at least $50 (Intel Edison). These often are designed for commercial products, and so have hacker-unfriendly interconnects that need a breakout board that drives the cost up even further. What's worse is that alternatives don't have the same online support community that Raspberry Pi has fostered.

What the Zero desperately needs is WiFi that doesn't involve the USB port.

SDIO and HATs

The BCM283x SoCs at the heart of every Pi has two MMC controllers. One of these connects to the SD card slot that the Pi boots and runs its OS from. The other has largely been ignored, but comes out on the HAT connector as alternate functions on GPIOs 22-27. Recent kernel and boot blob changes have enabled these pins to be mapped to the MMC controller that also supports SDIO devices.

SDIO started out as an extension of the SD spec to allow for cards that have functionality beyond flash storage. Some PDAs could be expanded to have WiFi or cameras through SDIO. Although smartphones killed the market for SDIO cards by integrating these common features, the bus still lives on as a bridge between SoCs and WiFi modules.

At the time of this writing, the rpi-4.2.y branch of the Raspberry Pi supports the SDIO interface on the HAT connector well. Simply build and install the kernel and edit /boot/config.txt to include the following line:

dtoverlay=sdio,poll_once=false

This enables SDIO on the HAT connector, and asks it to poll for SDIO cards past the initial driver probe at boot time (more on this later).

Enter the Eagle

In all the excitement over the Zero, I noticed a bunch of questions about using cheap ESP8266 modules as a WiFi bridge. Usually these threads were killed by someone by saying that the SPI interface would constrain the speed too much. Fortunately those questions jogged my memory a bit.

I remembered this blog post showing a decapped ESP8266, noting that in the corner is printed "ESP8089". The post mentioned that ESP8089 is another Espressif part, a commodity SPI and SDIO to WiFi chip. That got me thinking that, if the ESP8089 and ESP8266 are the same die, then there is a good chance that an ESP8266 module could work as an SDIO WiFi adapter on the Pi.

Espressif isn't helpful with ESP8089 documentation, but some Googling landed me at the center of the cheap Chinese tablet universe. That pointed me to a driver in a kernel tree for a specific Rockchip-based tablet that happens to have an ESP8089 adapter, as well as an attempt to break out an older version of the driver as a standalone module to use with ESP8089 in SPI mode.

So there's a driver, and possibly a physical interface between the Pi and ESP8266, but what about firmware?

The ESP8266 we're all familiar with normally boots from an off-chip SPI flash device, and can optionally boot code over the UART. The determination of how to boot (UART vs SPI) is done by GPIO strapping at power-on. Most ESP modules are set so that one pin alternates between booting from SPI flash or the UART. This lets the UART be used to download new firmware to the SPI flash when hooked to a PC and to run from flash when not. But the sparse ESP8266 documentation does mention a third SDIO boot mode, but there is no explanation of how to use it.

It turns out that SDIO boot is intended for the ESP8089. The driver contains a few firmware...

Read more »

esp-12f_hookup.svg

Hookup diagram for the ESP-12F

svg+xml - 64.02 kB - 02/23/2016 at 20:35

Download

  • 1 × ESP-12F WiFi module - ESP-12E will probably work
  • 1 × Raspberry Pi Any HAT compatible Pi: A+, B+, 2B, Zero
  • 6 × 33 ohm resistor
  • 1 × thing to stick the ESP-12F on perfboard, cardboard, a graham cracker, Pi Zero, etc.
  • 1 × 2x20 HAT Connector (optional) run of the mill dual row 100 mil 40 pin female header. or just solder to the Pi Zero

  • WiFi broken? Update your driver!

    ajlitt05/11/2017 at 02:58 1 comment

    Recently Raspbian switched to a 4.9 kernel from the 4.4 based kernel that's been the norm for a while. This breaks the esp8089 driver. If your esp8089 module no longer loads following an apt-get upgrade, this is likely the problem.

    Thankfully den4ix on github issued a pull request this morning that updates the APIs for 4.9. The fix is in the latest Debian DKMS package released this afternoon.

    To update the driver, download the new esp8089 DKMS package from github and install on top of the old package:

    wget https://github.com/al177/esp8089/releases/download/1.9.20170510/esp8089-dkms_1.9.20170510_all.deb
    sudo dpkg -i esp8089-dkms_1.9.20170510_all.deb

    Reboot after the package is installed to reload the esp8089 driver.

  • It's been fun

    ajlitt02/28/2017 at 15:27 3 comments

    Now that the Raspberry Pi Zero W is out, there's not much reason to use a WiFi Pants board. The Zero W is more compact, cheaper, and has out-of-the-box Raspbian support for WiFi. Also Bluetooth.

    If you need battery power for your Pi Zero project, please consider the amazing LiFePO4wered/Pi .

    Thanks to everyone who supported this project!

  • Licenses, longevity, lights

    ajlitt10/23/2016 at 04:01 0 comments

    It's been a while, huh?

    Much has happened over the last few weeks. The biggest news is that Espressif has agreed to allow their ESP8089 driver to be licensed under GPLv2 and the associated binary blob firmware to be put under the Apache license. Now the driver powering this project as well as many tablet devices can be submitted for inclusion in the Linux kernel. A few embedded Linux enthusiasts have stepped up to clean up the code and push it through the kernel patch submission process. Thanks to Jeroen@Espressif for getting the approvals, and the free-electrons folks, jwrdegeode, noahwilliamson, and icenowy for their ongoing work in making the driver kernel-ready.

    About two weeks ago I sold the last finished WiFi Pants kit in my inventory. I'm also running out of my long lead time components: PCBs, ESP modules, and the long stack through headers. I will be doing another run of kits which should be in stock in a couple of weeks, but after those are gone it's going to take a couple of months to build any more.

    Finally, I was lucky enough to participate in the first Hackaday TV hangout and talk for a few minutes about my project with Sophie Kravitz and Limor Fried and hear about some really neat Pi hacks. But while excitedly rambling on about my WiFi Pants project, I forgot to point out the demo I put together to show off the WiFi pants board's power supply. You can see it on the bench behind me in the video blinking away.

    Behold, the Access Point Sniffer Thing With LEDs in a Jelly Jar That I Haven't Considered Naming Until Right This Moment, or APSTWLJJTHCNURTM for short:

    It's a WS2812 LED strip in a jar that changes patterns depending on the number and strength of WiFi accesss points in the area. It uses a 60 LED WS2812 strip, WiFi Pants, a Pi Zero, 3 AAA NiMh batteries, a jam jar, a plastic tube from the packaging for a USB charger, plenty of clear packing tape, a few dabs of hot glue, and a WS2812 level shifter board made with junk box bits. Software is in Python using the rpi_ws281x library for talking to the LEDs and iw_parse to simplify the AP scan.

    Every second or so the Pi does a scan of the available networks. The networks are sorted by the signal strength and assigned an LED for each 4dB of signal strength. Each access point gets its own color by hashing the last 3 octets (the non-OUI portion) into hue and saturation. You can see at the bottom in the gif above that the LEDs towards the bottom of the jar are more uniformly colored and don't change much, while the APs that have weaker signals dance around with a larger variety of colors towards the top as they come in and out of range.

    Total time spent on this was about 5 hours. I figured that the string at full brightness plus the Pi and ESP8266 would push near the 2A limit of the boost converter, making it a good demo. However the LEDs at full power saturated my webcam to the point that the jar looked like it was filled with burning magnesium, so it's limited to 1/8 brightness. That's probably for the best, as the AAA batteries droop too much at full LED power to keep up with the 4A or so the converter pulls at its limits.

    Thanks HaD, Adafruit, Limor, Sophie, and all the other hackers for a fun hour of sharing projects!

  • Need Pants?

    ajlitt06/07/2016 at 19:34 3 comments

    I have a few WiFi Pants boards listed on Tindie. Have at 'em

  • Driver update

    ajlitt05/23/2016 at 15:52 3 comments

    Last night I checked in a change to the esp8089 driver that automates toggling the reset (CH_PD) on the ESP by GPIO. With this change ESP hacks based on the instructions here will automatically come up during boot without any scripting or external reset circuits. This also issues a reset on module unload which is needed so that the ESP is detected after a soft reboot (reboot on the command line, etc) and keeps the module from OOPSing when reloaded without a previous reset.

    The project instructions have been updated to reflect this change. If you previously added sysfs GPIO or module unload commands in your init scripts for the ESP (rc.local and otherwise) you'll need to take them out. The driver defaults to GPIO0 (ID_SD like the WiFI Pants uses), but you can pass the esp_reset_gpio module parameter with the GPIO number your board uses. This should be platform agnostic as long as the target has a kernel GPIO driver.

    The driver still isn't ideal since it must always be rebuilt every time the Pi kernel changes. On other Debian based systems this could be handled with dkms, but the Pi Foundation's non package based kernel scheme makes it difficult. Of course I have a build process to help with this, but that's dependent on a network connection and gets unpleasant on the Zero. One solution would be to build the driver against each Pi kernel release and index it by the kernel's commit hash (like rpi-source). If anyone has ideas for a cheap (or free) binary release hosting service I'd be open to setting up an automated build server.

    As for the WiFi Pants... I still have the first batch sitting on my desk. I wanted to get this driver change in to simplify initial setup, and still have some documentation to do. Keep an eye on the github wiki and on this project for details.

  • Production starts!

    ajlitt04/14/2016 at 06:04 4 comments

    Repeat 9x.

  • Testing the tester

    ajlitt04/10/2016 at 16:59 0 comments

    The test jig / bed of nails is coming along nicely. I OpenSCAD'd a mount and retention clips for the DUT, and with some filing and drilling out the PCB the DUT and pogo pins line up reliably and the DUT stays put. A choco-block terminal strip connects to the PSU and lets me clamp to the disposable DMM probes. The DMMs need test leads with an odd mini banana plug, so rather than trying to make custom cables I just clamp the probes in the terminals. They're used only for voltage measurement so this is fine. Some more drilling, standoffs, and a power jack for separate power to the Pi A+ round out the fixture.

    The output load is simply 8x 20 ohm power resistors in parallel for 0.4 ohms which gives 2A at 5V. They get a little toasty but don't seem to need active cooling.

    A few bugs to fix in the next couple of days:

    I'm seeing much higher voltage at the DUT for the input than at the fixture's DMM, so I'll try doing the Kelvin sense thing and run separate wires from the terminal block to the pogo pins for the input rail. Unfortunately there's only one pogo pin feeding the input to the DUT so I'm likely not going to see the actual voltage unless I redesign the PCB with a dedicated test pad for the input.

    Also, the regulator is getting excessively hot, moreso than when I've tested it on proto builds. Most of the heatsinking is done with vias to the ground flood on the back, and my design for the mounting frame has a solid fill behind the DUT except for where the pogo pins are. I'm currently reprinting this with much more area under the part exposed and a little vent towards one side in attempts to let the switcher cool naturally.

    The resistor load is working as planned, except it's just below the 2A point I want to test due to wire losses. So I might add another resistor in parallel to get closer to 2.25A which should make for sufficient testing margin. Easy enough since I've got a big bag of spares.

    I drilled holes for three standoffs to support the fixture, but realized I located the pogo pins too close to an edge for one of the corners. Need to find a dowel or something to hot glue there.

    I put a toggle switch from my junk bin on the board so I can shut off the Pi between DUTs, but the switch is flaky and cuts power at the slightest touch. It's shorted closed for now, but I'll eventually get a replacement.

    And a final mistake that should have been obvious: I am seeing lower throughput on WiFi than on my proto builds. I don't see this when using the same DUT carefully held on a Pi's header, so it's likely the fancy recycled perfboard I'm using with the ground plane restricting the signal. That's ok as long as I'm seeing consistent behavior between units.

  • Knife sharpening

    ajlitt04/07/2016 at 17:24 0 comments

    Now all the parts for my first small run of boards are sitting in a box on my bench, and I've built up a test board. This is what I plan to sell:

    The headers are shipped unsoldered to allow for different assembly options and to simplify packaging. Ignore the plastic spacer on the header, as it can be removed. I'm not in a place to stock a ton of different options, so if you want to mount this underneath a Zero you'll need to find a different header.

    Based on suggestions kindly offered by others, I'll be selling three kits: "full" with everything above, "basic" with only the WiFi populated on the PCB and including all the headers except the JST, and a bare PCB.

    Although I have materials in hand to crank out boards, I need one critical tool in place before production starts. I want these board kits to work once customers solder them together, so I'm working on a test jig for running the SDIO interface and power supply through their paces. After many years of getting along without a real bench supply, I invested in a nice Korad 30V 5A programmable linear that I can use with a pile of power resistors to run the 5V output to 2A at various input voltages, and to test the undervoltage lock-out. I also got a couple of cheap-o DMMs from Fry's over the weekend for a rough output voltage check, and some miscellaneous bits and pieces to put it together. I intend customers to use this board to run motors, LEDs, and other current sucking peripherals, so I want each board tested at load.

    Eventually I'll have a printed frame for the PCB and stand to take the load off the Pi underneath. I plan to have this working this weekend, and to start cranking out boards.

    I can't give any estimates when this will go on sale. March was exceptionally busy, and I've had little free time to work on this, and April is shaping up to be more of the same. But I'm making progress which I'll continue to share here.

    In the meantime, enjoy this picture of my messy bench:

  • Surprise boards

    ajlitt03/26/2016 at 21:26 4 comments

    Up until now I've been ordering OSHPark quick turn proto boards because they're cheap for very low volume. For the initial Pants run I went with Elecrow in China from the good reviews I've heard. I put in the order last week for 50 Pants boards with 3 day shipping to the US.

    DHL just notified me that I should expect them on Tuesday. But I'm totally unprepared. I don't have stencils, I'm missing some of the more expensive parts, I don't have a Tindie account set up yet, I haven't figured out shipping or packaging, I don't have a test jig built yet, and my bench is a mess! I don't know why, but I didn't expect 50 PCBs to be manufactured, shipped halfway across the world, and delivered in under 10 days!

    update - and here they are:

  • On the loss and renewal of focus

    ajlitt03/21/2016 at 05:08 0 comments

    (TL;DR: spent a few weeks on a tangent eating my own dogfood, finalized PCBs and ordered a bunch)

    Spring Break is always full of distractions for me. The kids are out of school, work slows down a bit, and South by Southwest takes over Austin, TX. A few weeks ago I got an email from @Sophi Kravitz asking if I might have any hacks I could bring for a panel she was giving at SXSW Create. Naturally I wanted to show off this project, but it hadn't occurred to me 'til then that I had built exactly zero projects using the WiFi Pants board.

    The board isn't that interesting by itself or on a headless Pi, so I wanted it to do something flashy. It needed to be battery-operated to show off the boost converter. So I turned to my junk bin for inspiration, and made a simple LED scroller with the LED matrix from Sparkfun's BadgerHack swag they gave out at last year's SXSW (thanks again!):

    I... uh... went a little crazy on this. I didn't expect the show-and-tell to be anything more than what it was: a short demo during the panel. But somewhere along the line I got it in my head that it needed to be a polished looking gadget and not a pile of boards and bodge wire.

    I spent a few late nights building the board stack and designing a 3D printed case. The Sparkfun LED array has mounting holes on 23mm centers, conveniently matching the Zero's screw holes, so I scrounged some washers, standoffs, and screws from my junk box and point-to-point soldered the array to end up with this:

    Initially I wanted to fit a small LiPo pouch in between the Zero and Pants board, but I ran into a few problems. I couldn't just go down to the local hobby shop and grab a battery for a nano quadcopter. I needed a protected cell to compensate for forgetting the UVLO (under voltage lock-out) programming resistors on the switcher on this board rev. Failing to have either cell protection or UVLO on the switcher could drain the battery too far and lead to surprise fires of the sort I'd like to avoid. Unfortunately there seemed to be a run on cells with the characteristics I wanted: reputable seller, fits in a 45x23x6mm volume, has protection, big enough for 1hr runtime (>=400mA), and fast enough shipping to get here in time. It seems that the sorts of batteries I wanted were all snatched up by hackers making one of the DIY Zero-based Gameboy projects.

    I ended up sticking a 3-AAA battery holder to the back of the case. I used 750mA NiMh cells which consistently give 2:15 runtime with the scroller running constantly. It wasn't as pretty as it would have been with a LiPo, but it worked and was likely safer. I had to make changes in the case model to make the battery connector accessible from the outside, but otherwise it worked well.

    The software is all Python. I could have done a C userspace daemon or kernel driver to make the display scanning smoother, but I didn't have time and figured a 1GHz CPU could handle it. It is multithreaded though, with the display scanner / scroller in its own thread that relies heavily on sleep() for timing, and the main loop and Twitter checker in the parent. There is a little flickering when the CPU is loaded, but it's not too distracting and only seems to show on feed updates.

    The case was modeled in OpenSCAD and printed in translucent gray (actually thermochromic "hypercolor" plastic) filament. The front of the case is .8mm thick, acting as a diffuser for the display. The thin front is a bit fragile, but it survived the demo. I did print and carry around a second copy the day of the demo though. The insides are lightly friction-fit to the screw heads on both sides of the body, and has stops inside to prevent putting stress on the protruding ESP-12F module antenna. A friction fit lid and hoop for attaching to a lanyard finishes it off.

    So this is great and all, and I hope some of the audience found it interesting, but what about making some boards available for sale? Last night I put in an order for 50 PCBs, and will get stencils and additional components...

    Read more »

View all 30 project logs

  • 1
    Step 1

    HARDWARE

    (WiFi Pants owners skip to SOFTWARE below)

    You'll need 6x 33 ohm resistors (either through-hole or SMT), some wire, and an ESP-12F module.

    Some variants of the ESP-12E should work as well, but there are some that do not have the GPIO9 and GPIO10 pins connected to the edge, and others that have a different pinout than listed here. From what I can tell there is only one variant of the ESP-12F (labeled "ESP-12-F QIO L4" on the back) so that is a safer bet. ESP-12F also has an onboard 10uF capacitor across the input supply, which saves you from having to add one yourself.

    You probably want something to mount the ESP-12F on. Perfboard is fine, as would be cardboard or just double-sided foam tape on the back of the Pi. No matter what you use, make sure that nothing is under the antenna or range will be greatly reduced. The ESP-12F LED is a good mark for the start of this keepout region.

    I use outdoor double-sided foam tape on my hand-built boards since it's tough but not hard to reposition, and raises the module enough to not short against the board. Creative application of hot glue or epoxy putty might work fine as well.

  • 2
    Step 2

    Make the connections between the ESP-12F or -12E and the Raspberry Pi HAT. Keep wires short as possible, and minimize the number of times they cross over each other. If you're using magnet wire or Kynar (standard issue blue wire) you might want to use a heavier gauge for the 3.3V and GND. Ideally the wire lengths of the 6 SDIO signals should be identical, but even a couple of inches of difference shouldn't matter. If you can, keep SD_CLK close to the average length of the other wires.

    The SDIO signals (names beginning "SD_") should have 33 ohm resistors in series (in between the Pi and ESP-12F connections). It may work with other slightly larger values, or with no resistor at all.

    If using 1-bit SDIO instead of 4-bit, omit D2 and D3. There's not much of a good reason for this though.

    A capacitor of 10uF or more may be needed between 3.3V and GND near the module, though a legit ESP-12F already has a 10uF supply cap onboard.

    Wire it like this:

    SDIO signalRPi HATESP-12F pin / signal
    ESP-03 pin / signal
    CLK15 / GPIO2214 / SCLKFlash pin 6 (CLK)
    CMD16 / GPIO239 / CS0Flash pin 1 (/CS)
    D018 / GPIO2410 / MISOFlash pin 2 (DO)
    D122 / GPIO2513 / MOSIFlash pin 5 (DI)
    D2 (optional for 1-bit)37 / GPIO2611 / GPIO9Flash pin 7 (HOLD)
    D3 (optional for 1-bit)13 / GPIO2712 / GPIO10
    Flash pin 3 (WP)
    -1 or 17 / 3.3V8 / VCCModule 1 / VCC
    -2, 4, 14, or 20 / GND15 / GNDModule 8 / GND
    -27 / ID_SD3 / CH_PDModule 13 / CH_PD

    Note that the CH_PD signal is connected to the ID_SD signal. This must be mapped as a GPIO (GPIO0) and switched to an output and driven low then switched to an input again before the driver is loaded in order to reset the module. This will be added in the near future in the driver.

    The ESP-03 column above is for people who want to use an ESP-03 module instead. This requires soldering to the pins of the SPI flash chip for some of the signals. The SPI flash may be desoldered first, or left in place.

  • 3
    Step 3

    SOFTWARE

    Start with a fresh 32-bit Raspberry Pi OS SD image of 2023-05-03 or later.

    A network connection to the Pi is required for the initial installation for the OS to fetch dependencies to build the driver module. This could be the onboard Ethernet of a model B Pi, a supported USB-Ethernet or USB-WiFi adapter, or the Pi Zero connected through another PC over USB.

View all 11 instructions

Enjoy this project?

Share

Discussions

turne327 wrote 03/21/2016 at 16:49 point

Have you evaluated the antenna on this design? It looks like a copy/paste from Texas Instruments. Since your application differs from the TI reference design, it is likely that the antenna performance has changed or possibly tuned off of frequency.  If you provide me with a prototype board, I would be happy to impedance match and optimize the antenna for this project. 

  Are you sure? yes | no

ajlitt wrote 03/21/2016 at 16:54 point

Thanks for the offer!  The version with the TI appnote antenna has not been characterized since I ended up replacing the ESP8266 chip and support components with an FCC certified module with a built-in antenna.  Qualitatively my implementation of the antenna seems to work well, but I wouldn't be surprised if it needs adjustment.  I don't plan to make any more of that variety so I haven't planned to do proprer testing.

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 02:02 point

I must be doing something wrong... :)

I get this in syslog on the pi... (see below)  my esp8266 is an AI-THINKER version...  not sure how to tell much beyond that without pulling off the cover...

it pretty clearly looks like the module either doesn't initialize or it's putting garbage out...

it would be wonderful if one of you had an idea and pointed me in the right direction..

245.349490] mmc-bcm2835 20300000.mmc: no support for card's volts
[  245.349514] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.349552] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.349576] mmc1: error -22 whilst initialising MMC card
[  245.393883] mmc1: Controller never released inhibit bit(s).
[  245.409294] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.409328] mmc1: Got command interrupt 0x00030000 even though no
command operation was in progress.
[  245.420365] mmc1: Controller never released inhibit bit(s).


  Are you sure? yes | no

jacksonliam wrote 03/19/2016 at 13:03 point

I've seen this. try either unloading the driver (modprobe -r esp8089) and trigger a reset of the esp8266 or completely remove power from the Pi and module for a few seconds.

Also make sure the hardware connections are correct. Only the CS and clock pins need to be correct for the mmc driver to load.

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 16:24 point

I'm using a NodeMCU esp-12 dev kit breakout board which seems to have the right pins broken out.    I reverified pinout, but i'm still getting the same results.     the driver itself doesn't ever seem to load.

I don't need to flash anything specific onto the esp12 right?  the driver will take care of loading the right firmware.

  Are you sure? yes | no

jacksonliam wrote 03/19/2016 at 16:44 point

Which pins does the NodeMCU have pulled up/down by default? The ESP8266 needs to boot in SDIO mode but the NodeMCU probably has it hardwired to boot from the flash (GPIO15 pulled down IIRC). 

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 17:46 point

thanks for the pullup/down comment.  it seems obvious now that you say it... time to pull the 8266 off the board...

  Are you sure? yes | no

John Weers wrote 03/19/2016 at 19:43 point

and... it works...   it doesn't often work upon boot, but a quick reset makes it work just fine...  recommendations on how to make it work on bootup?

  Are you sure? yes | no

ajlitt wrote 03/21/2016 at 16:57 point

What are you doing with CH_PD?  It should be pulsed low after power-up (or before loading the driver) to cause the chip to reset and kept high otherwise.

  Are you sure? yes | no

txdo.msk wrote 03/02/2016 at 22:45 point

agreed.  ajlitt, I want that board!  Good job, dude!

  Are you sure? yes | no

gir wrote 03/02/2016 at 17:18 point

Well deserved winner! congratulations. my project wouldn't be the same without yours!

  Are you sure? yes | no

Craig Hissett wrote 03/02/2016 at 11:55 point

Congratulations for winning a Pi Zero buddy! Well deserved :)

  Are you sure? yes | no

David Lowe wrote 03/02/2016 at 16:31 point

I wasn't aware until now, but yes great to see @ajlitt getting some reward for his great work & write-up on this :-)

  Are you sure? yes | no

ajlitt wrote 03/02/2016 at 17:35 point

Thanks all!  This wasn't done in a vacuum either.  I appreciate all the suggestions and advice along the way.

  Are you sure? yes | no

gir wrote 02/27/2016 at 08:53 point

Hi ajlitt, i can't compile esp8089 - it can't find <mach/gpio.h>

what am i doing wrong? i followed your instructions and am hanging on number (8)

thanks

  Are you sure? yes | no

txdo.msk wrote 02/17/2016 at 18:44 point

started reading your instructions today.  This is flipping sweet!

  Are you sure? yes | no

txdo.msk wrote 02/13/2016 at 02:16 point

this is another one that I think My project would benefit from, keeping the Pi Zero flat.

  Are you sure? yes | no

Martin wrote 02/09/2016 at 15:32 point

Thinking about the series termination resistors: Normally The sum of the driver output resistance and the external termination resistor should equal the line impedance. Which of course depends on line width and PCB thickness - you probably do not use a multi layer board (what increases the line impedance because of the thickness), but you have the GND plane very close to the traces (what lowers the impedance). So if you did not try it yet, I would lower the termination resistors from the 150 Ohm you mentioned. Normally you have 22 to 47 Ohms, depending on line imoedance.

  Are you sure? yes | no

ajlitt wrote 02/09/2016 at 15:45 point

Thanks!  As you can tell my SDIO routing isn't controlled impedance.  After some testing it looks like 33 ohms is fine for the ESP-12F boards I made.

  Are you sure? yes | no

sundin.mikael wrote 02/07/2016 at 17:09 point

Great work, i have get my own version of PCB working too. i have also added footprint for I2S DAC.

I can choose between rpi 3.3V or a regulator, it works with RPI 3.3v as long i don t reset ESP8266EX (suspect a current spike cause RPI to crash).



  Are you sure? yes | no

David Lowe wrote 02/07/2016 at 18:14 point

Nice board! I like the idea of taking parts off the module, but I'd have been tempted to discard the ceramic antenna & print a folded-F on the PCB like ajlitt's original RPi WiFi HAT board.

Re your crash when resetting the module. While holding CH_PD low, do a sudo modprobe -r esp8089, then let CH_PD go high. Does that stop the crash?

  Are you sure? yes | no

sundin.mikael wrote 02/07/2016 at 18:31 point

Works as a charm, then its the driver causing crash.

I thinking adding restart of ESP at boot...

  Are you sure? yes | no

sundin.mikael wrote 02/07/2016 at 19:09 point

I was also choosing between PCB and ceramic antenna, i choose ceramic antenna because its easier. I only want to do one shot on the PCB manufacturing. I also added a ufl antenna connector if more range needed.

  Are you sure? yes | no

ajlitt wrote 02/07/2016 at 22:24 point

Are you using the reset signal, or CH_PD/CHIP_EN as a reset?  Per the Espressif docs, I leave the reset floating and use CHIP_EN to affect a reset.  I don't deassert CHIP_EN at any time while the driver is loaded, and if the driver was previously loaded (i.e. reset or reloading the module) I toggle CHIP_EN to force the ESP to revert to the SDIO boot ROM and forget the ESP8089 firmware.

Eventually (I keep saying that word...) I'll roll the CHIP_EN GPIO control into the driver so it can properly manage the firmware loading.

In the meantime, you should always bring CH_PD/CHIP_EN low and high again before loading the esp8089 driver, and never bring it low unless the driver is unloaded.

  Are you sure? yes | no

jacksonliam wrote 02/07/2016 at 22:05 point

Very cool board! You reflowed that right? Those tiny packages! 

What throughput have you got? 

  Are you sure? yes | no

ajlitt wrote 02/07/2016 at 22:18 point

Wow!  That's a pretty board!  The antenna overhang reminds me of the antenna bump on the last-gen Dell Axim PDAs.

Any reason to cut around the CPU?  Heatsink? 

As for the antenna, the inverted F from the TI appnote worked well enough qualitatively on the first try.  I don't have RF gear to verify the tuning though.  The ESP has an antenna tuner onboard so it shouldn't matter too much.  Certainly my design with the PCB antenna gets better range than the ESP-03 I have (which uses that Rainsun chip antenna), though on par with the ESP-12F.

Also, seeing as how you're using series termination resistors... have you scoped the SDIO signals?  I know there doesn't seem to be much of a functional difference with and without them.  But on my scope it looks like using 100 ohms in series overdamps the edges while no termination leaves considerable ringing.  I'd love it if someone could take a look.

FWIW running bandwidth tests in one direction at a time (iperf -c $IP -r) I can tell when the test changes from transmission to reception by watching one end of the termination for a change in the signal edges.

  Are you sure? yes | no

sundin.mikael wrote 02/07/2016 at 23:52 point

The board is not reflow, hand soldering without microscope.

Yes, the cutout is for heatsink. Antenna placement is to avoid the dc/dc and get the antenna outside rpi zero grounding plane.

I using 75ohm serie resistance, i will check later at work when i got time

I am using CHIP_EN to enable/disable the chip. Reloading and reseting ESP8266EX and the driver via a script is not a big issue for me..

I have around 2-3Megabyte/sec if i download a file from local network. Router is located in same room.

Added a photo of the blank pcb, via under QFN is to be able to hand solder the QFN. The other board is 40pin to 26pin RPI (reroute unused pins) and two 5v <-> 3.3V i2c level shifter


  Are you sure? yes | no

David Lowe wrote 02/08/2016 at 06:40 point

Re antenna placement. The ESP8266 Hardware User Guide warns against putting the antenna close to high frequency lines . The end of the board you choose has SDIO + HDMI. I opted for the other end against DC/DC... wonder which is the better choice?

  Are you sure? yes | no

AVR wrote 02/10/2016 at 17:46 point

wow, where can I buy that or get the sources? this is exactly what I needed.

  Are you sure? yes | no

usedbytes wrote 02/07/2016 at 09:10 point

Great idea, great write-up, thanks! Is anyone trying to upstream the driver?

  Are you sure? yes | no

ajlitt wrote 02/07/2016 at 22:46 point

Not that I know of.  It's got a few binary blobs and unclear licensing (though inclusion in the kernel makes it technically GPLv2) and likely needs some cleanup to make it fit style-wise.  Any pointers would be great...

  Are you sure? yes | no

Daniel Baldes wrote 01/24/2016 at 19:09 point

Thanks for this great project! I needed an USB-less WiFi on my Raspi Zero and had a spare ESP03, so I built one of these for myself, and I'm going to brag about it with these pictures:  http://imgur.com/a/eMZCI

(actually I destroyed one ESP03 when trying to unsolder the flash chip, I ripped out two pads)

I used a 10uF capacitor and it seems to work so far.

  Are you sure? yes | no

ajlitt wrote 01/24/2016 at 19:29 point

Looks good!  How is the performance?

  Are you sure? yes | no

Daniel Baldes wrote 01/24/2016 at 20:04 point

test.gz              67%[=============>        ]  80.81M  2.50MB/s   eta 16s

About 2.5MB/s (close to the AP), I'm impressed. At first I thought I logged into one of my other Raspberries by accident but I checked again ;-)

  Are you sure? yes | no

David Lowe wrote 01/25/2016 at 12:17 point

PhilE has added overclocking options for the SDIO interface this morning.  The next release will allow dtoverlay=sdio, poll_once=off, sdio_overclock=62 for a 50% boost to 62.5MHz.  That will certainly improve the read speeds of SD cards on the SDIO bus, and will likely be useful for 1-bit mode on the esp8266 and 4-bit mode on the esp32 when that is available.

I have one of these http://www.ebay.com/itm/311051402241?ru=http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=311051402241&_rdc=1 on its way to me. Despite looking like a mini PCI-Express card, it is an SDIO WiFi adapter. Hopefully I'll be able to figure out the pinout and see how the BCM4329 performs.

  Are you sure? yes | no

jacksonliam wrote 01/25/2016 at 14:38 point

@David Lowe interesting. Looks similar specs to the AP6210 module in the cubietruck. I've got a few of those but it's got a bit more of tiny package and big BOM compared to the ESP modules so haven't designed a board for it yet!

  Are you sure? yes | no

ajlitt wrote 01/25/2016 at 15:14 point

@David Lowe  Looks like this bus is getting some attention now!

I looked at other chipsets a while back, but dismissed them since I couldn't find a module with SDIO and FCC certifications for a reasonable price.  The biggest advantage to the Realtek is that I think it has a mainline driver.

  Are you sure? yes | no

David Lowe wrote 01/25/2016 at 16:16 point

Which Realtek module? The Azurewave module in the ebay listing I posted uses mainline brcmfmac driver https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211, but needs a file taken from nvram. Goodness knows where I am going to get that from! If I can overcome the pinout mystery too, this module should run at up to 150Mbps. There are newer chipsets which exceed 400Mbps. @ajlitt did you get in touch with sprite _tm from espressif  as he requested? Maybe he has an ESP32 for you...

Edited to add: good news re the Azurewave module, the datasheet inc pinout is public https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1417868, and an nvram.txt file can be found via google.  Looks like the module is only 65Mbps, not 150, but as a bonus includes BT2 & FM radio to play with.

  Are you sure? yes | no

ajlitt wrote 01/25/2016 at 16:51 point

I did get in touch with him.  Exchanged a few emails but haven't heard from him since.  Still waiting to hear if the ESP8089 SDK alluded to in the drivers is available and if they'd consider allowing it to be mainlined.

Looking through the Pi kernel patch, it's clear now why the bus comes up at 41.66MHz: The SD/SDIO clock is divided from a 250MHz clock, but the divisor must be even.  Time to redo throughput tests at 62.5...

As for the module, there were a couple.  The major distys had a Taiyo Yuden module and another from SiLabs (from the Bluegiga buyout) that I think are both Broadcom and do not have mainline drivers.  Both were in the $10-15 range, which is more than my current BOM for the Pants board.

  Are you sure? yes | no

sundin.mikael wrote 02/07/2016 at 17:09 point

Tips for desolder ESP8266Ex on ESP-03, scratch the pcb under ESP8266EX, use solder and solder iron, lift the QFN from the other side after some seconds. Works for the crystal too

  Are you sure? yes | no

jemartel1 wrote 01/11/2016 at 23:52 point

Can this be purchased yet?

  Are you sure? yes | no

ajlitt wrote 01/18/2016 at 18:09 point

Not now.  I'm still prototyping, and even then I have no definite plans to manufacture or sell these.

  Are you sure? yes | no

Joshua Alto wrote 02/05/2016 at 18:56 point

Awesome! Hopefully you can make them cheap enough, but who knows what perils your manufacturing process may hold.

I think it'd be great to only have to spend $10 to get a PiZ and ESP bundle.

  Are you sure? yes | no

ajlitt wrote 02/05/2016 at 20:42 point

@Joshua Alto  As usual cost is the limiting factor.  The Zero this is intended for is $5.  Despite other peripheral costs users need to face (SD card, cables, power supply, adapters, hub...) people have it in their mind that this is a full computer for $5.  So to make an accessory for the Zero attractive it must be <$5 or the whole value proposition of the Zero is lost.

I can buy $2 ESP-12E modules all day from China, and possibly get Zero sized PCBs in bulk for $1.  With the current design, headers are another $2, and discretes are ~$0.50 at worst.  Add in assembly, distribution, test, and replacements for assembly fallout and RMAs and it's more expensive than the Pi.  And that's before I get to the margin I'd need to add to make it worth spending my scarce free time on.  As fun as the idea is, I don't see the volume being there even after the Zero is no longer scarce.

If it were a $20 add-on for a Raspberry Pi 2 or a Beaglebone it would probably sell well.  But the false economy of the Zero dooms this from the start as a low volume product.

That said, I have spent a lot of time thinking about a way to sell this that doesn't involve Craigslisting my house or kidneys.

  Are you sure? yes | no

Joshua Alto wrote 02/05/2016 at 20:52 point

Well, best of luck. I know if you make it to manufacture, I'll probably end up buying a few.

  Are you sure? yes | no

Dorijan wrote 05/31/2016 at 09:14 point

Don't sell yourself and your idea to short and do not be to concerned about how much the cost/price would be. People would be willing to pay more than you think. I made a similar mistake when the first Rpi came along.

The SD card was expanding from the PCB so I designed a microSD adapter, put it on google code under OSHW and published it on twitter #raspeberrypi because I thought nobody would pay $6 for microSD adapter but maybe somebody would like to build it.

https://code.google.com/archive/p/raspberry-pi-rs-micro-sd-adapter/downloads

Within few weeks gerber files download counter was in the hundreds and similar/same adapters sprung out on kickstarter and other sites. After 3 months it was cheaper for me to buy ready made adapter from ebay than just the connector from farnell.

Electronics is cheap hobby but there some equipment can be quite expensive and from my experience it is nice to have some extra income from the hobby that you can throw for that equipment guilt free :).

You can start very slow and on the cheap. I would suggest you to go by this steps:

1) check https://www.tindie.com/ (craigslist/ebay for DIY electronics)

2) At the beginning forget placed PCBs to avoid cost for production and the trouble of getting cheap esp8266 in quantities form china.

3) Start with just bare PCBs. You can get 100PCBs in the size of RPIzero from PCBway for $80 shipped.

3) put 2pcbs in a bubble envelope(~$20/100pcs) go to your nearest post office and ask How much would this cost to ship to some city in EU if you are from US or the other way around. Probably about $3-4.

4) Price for customer has to be around 4x of production cost to enable development and cover some unforeseen costs.

5) Put a pair(it is easy to accidentally destroy one board) of PCBs on tindie

6) Price set must be around 2pcbs for $0.8 + envelope($0.2) = $1.8*4 = $7.2 + shipping = ~ $11.00.

7) Since the pi is $5 and you do not have much manual labour involved you can drop the price+shipping for most countries to $9.90. That means you sell SDIO wifi boards with shipping for $5/board(most of your customer base already have some esp12 lying around).

8) Never publish your personal email/telephone to avoid people asking you for things you already wrote here or on github documentation

9) Create a zip file with everything needed inside, manual in pdf, BOM, firmware program for flashing firmware

10) Send me a link so I can buy a pair :)

Short recap: Looking at the comment section a lot of people are willing to buy this and 90% will probably just solder esp-12f on it and be done with it without the switcher PS. The initial investment on your part would be $100 and time. Potential return is $200 so basically $100 in net. So the hours invested in project will be paid terribly. But you will learn a lot and get the grasp and experience on what it takes to manufacture and deliver a product that you can use later ob more complicated projects.

  Are you sure? yes | no

ajlitt wrote 05/31/2016 at 15:05 point

@Dorijan : Thanks for the encouragement and advice!

I'm on the verge of bringing my Tindie store online, but only stocked with the full switcher version of the board.  I have far more blank PCBs in hand than I do parts for the switcher, and about half as many extra ESPs.  I've had requests for exactly what you've mentioned...

You're right that the overall ROI is blown on this project if you take into account how much I've put in already.  But I've been treating this as a learning experience not just in the hardware itself, but in manufacturing and distribution as well.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 02/06/2016 at 01:41 point

I think you shouldn't keep people from being able to buy this just because the Pi Zero is cheap.  I think most people who would be interested understand the false economy of the Pi Zero, the fact that it can do very little on its own, and that an accessory like this makes it significantly more useful (or useful at all).

None of the Pi accessory makers can compete on price with the Raspberry Pi foundation.  I think it's pretty normal for add-ons to be as expensive or more expensive than the Pi.

  Are you sure? yes | no

ajlitt wrote 02/07/2016 at 22:31 point

I'm not saying "no"... and since posting that have heard from others not to worry about the Zero's price.

  Are you sure? yes | no

jaromir.sukuba wrote 01/11/2016 at 12:40 point

This is great project, I like it. In project details you mention the option of booting via SPI. This is interesting for me, as I hope it would be usable for #Unix on your breadboard project. PIC32 currently has no SDIO master and bitbanging is perhaps out of question, but it has a few free SPI master interfaces.

I assume the current binary images of firmware wouldn't work on SPI mode even though the SPI mode would be invoked and firmware downloaded. Did you try the SPI mode?

Do you have some other thoughts about this?

  Are you sure? yes | no

ajlitt wrote 01/11/2016 at 15:01 point

From the driver source it seems that there is a SPI slave boot mode in addition to SDIO.  The driver has a separate HAL for SPI bus attachment, and a second firmware image stored within for use when the SPI HAL is chosen.

But to use this, you'd have to port the driver to the target OS, which isn't trivial considering the driver itself is the only documentation on the firmware API.

There are supposedly examples of using SPI slave mode for communication with ESP8266 applications on Espressif's site, but I don't think it discusses the SPI slave firmware download process.  But the code that does this in the driver is fairly clear, so you can start there.  Keep in mind that you have to fit everything in RAM when running like this, since you can't page in code from SPI flash...

  Are you sure? yes | no

nistvan.86 wrote 01/10/2016 at 15:36 point

Love this hack! :) I do hope someone picks up the hat and starts producing it. For most of the IoT things the provided bandwidth is more than enough.

  Are you sure? yes | no

zeflo wrote 01/05/2016 at 00:04 point

Amazing work! Maybe for v0.2 you could ad some activity LEDs to one of the GPIOs of the ESP8266?

  Are you sure? yes | no

ajlitt wrote 01/05/2016 at 03:50 point

From what I can tell, there is no activity LED on the ESP8089 / ESP8266 when running the ESP8089 firmware.  That shouldn't matter since you can use the kernel LED class driver to make the onboard green LED or another LED on the expansion header blink along with network traffic.

  Are you sure? yes | no

ajlitt wrote 01/05/2016 at 18:23 point

I take that back.  The driver code has functions for controlling GPIOs.  This appears to be associated with entering/exiting sleep mode and for controlling the BT coexistance.  But it doesn't seem to be used for LED driving.  So it's theoretically possible to modify the driver to control LEDs on unused GPIOs.

  Are you sure? yes | no

Falkenad wrote 12/12/2015 at 20:32 point

Great work! I've tried to install the driver from your Github, but sending the "make" command  comes back with an error reporting that it can't find the Kernel build tree. Any idea what might be happening here? Thanks!

  Are you sure? yes | no

ajlitt wrote 12/12/2015 at 22:49 point

Try doing "export KBUILD=/path/to/your/rpi-4.2.y/kernel/tree" before running make.

  Are you sure? yes | no

Falkenad wrote 12/13/2015 at 02:17 point

Thank-you, that worked and I've ended up with a compiled .ko file. However, both insmod and modprobe give errors, saying "No such device" and "no such file/directory" respectively when the path has been explicitly defined. Kernel is 4.2.7.

  Are you sure? yes | no

Sabas wrote 12/28/2015 at 05:58 point

I am compiling as  next video, but error of  no found .config 

  Are you sure? yes | no

ajlitt wrote 12/13/2015 at 15:00 point

Oops, I forgot to include enabling the SDIO driver in the instructions.  See step 5, or just add "dtoverlay=sdio,poll_once=off" to your /boot/config.txt and reboot.

  Are you sure? yes | no

Falkenad wrote 12/14/2015 at 06:25 point

I had already changed config.txt and rebooted, and the error unfortunately persists.

  Are you sure? yes | no

ajlitt wrote 12/14/2015 at 07:01 point

Have you wired up an ESP module to your Pi yet?

If you're getting "No such device" that's likely because the driver can't find an esp8089/8266 on the SDIO bus.  I reproduced this on a Pi without the module plugged in.  After the module load failure you should see a few "esp_sdio_init ------ RETRY------" lines in dmesg as evidence that the driver attempted to power cycle the SDIO device to force redetection (this isn't implemented on my fork yet).

  Are you sure? yes | no

Sabas wrote 12/28/2015 at 01:51 point

Hi, I have the same problem, you could put the correct path

  Are you sure? yes | no

ajlitt wrote 12/28/2015 at 05:38 point

Are you having problems with compiling the driver or installing the module?

I updated the instructions the other day, and followed them faithfully through a fresh Raspbian install on my Pi 2.  I also made a minor change to the driver in github that works around a build failure when compiled against the most recent kernels.  Try the new procedure out and see if it works.

  Are you sure? yes | no

ajlitt wrote 12/30/2015 at 06:22 point

See the instructions in this project, particularly step 4.  Use this as opposed to the Adafruit video.  The video isn't wrong, but in this case we want to use the default configuration.  The "make bcm2709_defconfig" line generates a .config from the default config settings for the Pi 2 (bcm2709).

  Are you sure? yes | no

Sabas wrote 12/30/2015 at 18:34 point

I am compiling with "make bcmrpi_defconfig" for Raspberry Pi B+, Hat work with Pi B+?

  Are you sure? yes | no

davedarko wrote 12/12/2015 at 02:11 point

Hey @ajlitt and everyone else. I really like this idea and I was inspired to design a little board based on what you've documented here and datasheets and schematics from other ESP8266 boards etc. In my design the ESP points outwards, away from the board. So if anyone wants to look over my design while I sleep - that would make me happy! Everyone feel free to nag and give suggestions. https://hackaday.io/project/8252-me-building-projects-from-hackadayio/log/28949-rpi-wifi-hat-by-ajlitt

  Are you sure? yes | no

ajlitt wrote 12/12/2015 at 03:11 point

Nice!  l like the panelization.

I've been working on a pHAT (I guess that's what the Zero HATs are called) that's on my github.  I'll do an update in a bit with some info once I clean up a few things.

  Are you sure? yes | no

davedarko wrote 12/12/2015 at 09:09 point

Awesome :) Since we seem to be equally unsure about the design and you have already ordered your boards... I think I'll wait. Maybe not :D

I like where you've placed the ftdi header, that's what I did on an arduino pHAT I'm working on. I panelized it this way to save some money. 

I have two questions for you though: I'm unsure about the different wire length of the SDIO connection. Does it matter much with this speed? And do you think it is possible to use a 52MHz clock for a faster ESP == more throughput?

  Are you sure? yes | no

ajlitt wrote 12/12/2015 at 23:08 point

On my prototype, I cut the wires on the HAT side of the resistors to the same length ahead of time.  On the ESP side, I assumed they'd be fairly close.  The layout of the HAT connector makes it a little tricky to get that right.

On my PCB layout, I used the interactive router to run the signals through routes that put them a couple of mm of each other.  Originally I tried to use the skew tool to hit a target length, but all it did was make a mess.

SDIO is 50MHz so it should take more than a few mm for the skew to matter.

  Are you sure? yes | no

Luke Weston wrote 12/10/2015 at 08:08 point

Under "SPI flash pin# / ESP signal" your table shows "8 / SD_D3", which I believe is a mistake.

Pin 8 on the SPI flash chip is usually the Vcc, and the pin you want to use for SD_D3 is pin #3 (which is normally the WP pin on the SPI flash).

  Are you sure? yes | no

ajlitt wrote 12/10/2015 at 13:10 point

You are correct.  I deal with SPI flash all the time at work; I should know this.  Thanks for the catch!

  Are you sure? yes | no

Sprite_tm wrote 12/10/2015 at 03:42 point

Great work! Always nice to see people finding new uses for the ESP8266. I'd like to talk to you in private, see if I can do anything to make this hack even more easier. Can you shoot me a mail at jeroen at espressif period com?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates