Archive for the ‘Uncategorized’ Category.

The esp32 wroom32 design

wroom32_gerbs2

Espressif kindly provide the schematics and layout files for the esp32 based WROOM32. In preparation for my own design (based on my espusb) I’ve been looking over these files.

The zip file they provide (local copy) contains wroom32_pcbdesign files in a variety of formats. The source .PCB and .SCH files appear to be included, but there are no notes and I couldn’t determine which tool they are for (if you know please comment – my best guess is OrCAD). They also include pdf printouts of the schematic and and layout. The Layout pdf is reproduced to the right. However, it doesn’t show any of the silk and only appears to be the top copper layer. I therefore generated the image above from the gerbers that are also included.

The gerbers also don’t use a naming convention I’m familiar with, but from what I can tell the WROOM32 is a 4 layer board. I’m kind of surprised that they didn’t try and squeeze everything onto 2 layers, like they do with the esp1. Will be interesting to see if the esp32 also forces me to start doing 4 layer designs.

For reference, the BOM and schematic are below:

wroom32_bomwroom32_sch

Dual esp8266 board

espdual

I’ve been playing with a new esp8266 design. The board has 2 esp8266s on one PCB. It’s based around my espusb design.

The board contains a ch340g usb interface, an MSP1603 buck converter to power the 2 esp8266s. The SPI buses of the esps are linked so that they can communicate. There are headers that allow the 2 esps to be programmed independently.

One idea of course is that I could uses these boards to build a basic mesh network. I think they’ll be fun to play around with in any case. Gerbers and Kicad files below. If boards work, and there’s any interest, I might stick them in my shop. If you think you’d like one email me (new@sgenomics.org).

Kicad design files and gerbers: espusb_dual

Weird PCB Layouts with Kicad

flowerpcb2

I designed the board above for my solar flower kit. It was partly an experiment is designing a weird shaped PCB, with funky traces and complex edges.

The process is kind of messy, and requires command line tools. If you’re a graphic designer and would like me to do this for you, click here. If you want to do this yourself, my notes are below.

The board edges have to be imported into Kicad separately from the graphics. You can only import DXF files. I use Inkscape to design the board edges and then export them as DXF. In Kicad in PCBnew select “File->Import->DXF” and import the DXF into the “Edges.cuts” layer.

First, I designed the flower shaped edge cut in Inkscape. In recent versions of KiCad it’s pretty easy to import the edgecuts. Firstly create your edges in Inkscape, ensure that the design is a simple line drawing and save it as a DXF file. Then just select “File->Import->DXF” in KiCad, and import the DXF into the Edge.cuts layer.

Creating interesting looking traces is more difficult. Kicad doesn’t really have a concept of non-straight line traces, and pads are similarly limited. There’s a tool in Kicad called “Bitmap2Component” which is ok for basic logos, but it doesn’t work that well with vector graphics.

For graphics I therefore use svg2mod. This is a neat little command line tool which takes a vector image into a Kicad component composed of a bunch of straight-line segments. After you’ve downloaded the tool you can run it as follows on an SVG:

./svg2mod.py -i ~/design.svg -o ~/design.mod -p 0.1

The “-p” parameter determines how many segments a curve is broken into, and may require some experimentation. svg2mod also works with multi-layer SVG files. You can create mask, copper, and silk layers and import them all into the Kicad component (the svg2mod readme specifies all the layer names you need to use).

You can them import the .mod component into Pcbnew and place it as you would any other part. In my case, I’d mark locations where LEDs should sit on the Inkscape design. I then placed LEDs over these in Pcbnew, this ensures that the drill holes get created correctly. I also had a small layout in the center of the board, the traces designed in Inkscape therefore needed to be manually aligned, and of course your DRC never passes.

That’s the basic process, and while it’s pretty messy but it works and you can create some entertainingly odd PCBs this way.

PIC Versus AVR

pic

As a general purpose microcontroller board I was always a bit disappointed with the Arduino. When in Arduino appeared in 2005 the 8bit AVRs were already pretty old school microcontrollers and cheap 32bit microcontrollers were already available. These days when you can pick up a cheap STM32 for under a dollar it seems kind fo crazy to use 8bit mid-90s technology…

The reason we do of course is because the Arduino has great support and a large active community.

For a recent project I wanted a small microcontroller. All it had to do was send a few very simple serial commands. For this, I really didn’t need anything more than an 8bit microcontroller, which for me comes down to PIC versus AVR.

I cut my teeth on PICs in the 90s using MPLAB under windows 3.11. PICs have a kind of nasty architecture. They’re Harvard architecture. Which means code and data sit in separate memory spaces, and that takes a little getting used to.

One of the nice things about PICs is that very have very very low power, cheap versions. The PIC12F629 has ~2KB of flash and 64 bytes of RAM. It’s about 1USD on digikey and about 10 cents on taobao. It also looks like there might be cheaper clones down to about 1 cent.

So I went with the PIC12F629 and it was a nightmare. Firstly, I thought I’d try using a C compiler, inefficient for sure but hopefully quicker than writing assembler. So I installed the debian package sdcc, which is the only compiler I know that supports PICs on Linux.

Debian sdcc doesn’t have PIC support.

sdcc uses the microchip header files which have a non-free license. It look me a while to figure this out but I then downloaded sdcc for their sourceforge site.

It’s a sourceforge site. I should probably have stopped right there. Binaries are available, but they are 32bit only. I checked out the source from their svn.

./configure;make;make install

Looks good. Could at least start to compile code, lots of issues. Size issues due to 32bit in library requirements (removed 32bit ints) etc. etc. Finally code looks like it should fit in the flash, but it’s failing to link with libsdcc.

Building sdcc doesn’t build libsdcc. Googling… digging around in random directories, and try and configure;make it. Fails. Missing instructions in the floating point library. Hack the floating point library until it builds…

Finally get a binary from sdcc.

I’m using a minipro to flash the controller. Fails.. the hex file is the wrong size.

The hex file contains a single word way off the end of the flash memory. This was actually the configuration bit, but the Linux minipro software doesn’t know how to flash this correctly. However with this removed the devices would flash and verify.

PIC does nothing when powered. Can’t even get an LED to blink.

I try reference hex files which should just blink LEDs… they don’t work.

I figure maybe the Linux minipro client doesn’t work well. So I try the Windows client. Many people have reported successes with minipro and the PIC (including the PIC12F629) so it should be an issue.

Fails.

Spend hours fiddling with config bits. Decoupling.. Power supplies..

Fails.

Give up, and buy a Digispark with a ATTINY85. Works within 5 minutes.

I’d literally spent hours with the PIC. I’m guess one possibility is that I’d overwritten the OSCVAL config in the PICs (which stores internal oscillator calibration) and the PIC was hosed because of this. But the conclusion is basically the same.

The AVR has a clean, open toolchain and a larger community, it’s just easier to get things done. At some point I’ll likely migrate my code to the ATTINY10 which are about the same price as the cheapest PICs (