It was going so well, with the 3D Printer posts, all good posts and not too far apart, and then… nothing.

I did continue to work on the 3D printer a bit past that, and will resume those posts again, probably once I have everything working – it’s still waiting for some software development which I have been stalling on / doing other things.

So, what has been taking my time? Let’s see…

First I messed around with some Nordic RF chip stuff (I’ve built some infrastructure, but these projects are still ongoing)

I built some PCBs for an RGB POV spinning top, which still hasn’t been fully assembled or programmed…

I designed a board to control the PSP LCD, and finished its software (it works!) – I normally do everything but a friend of mine did the PCB layout on this board.

And most recently I’ve been working on a gameboy cartridge. Not much to say about this one yet, but will be fun when there is :)

And of course a few other things along the way; my Flickr Stream has more, and is usually the first place new stuff shows up.

Feel free to ping me with any questions or comments! I’ll try to post a bit more regularly.

My design goals would be:

• Ensure the design will work, by using chips I’m familiar with & already have code working on.
• Reduce complexity by only having one motor driving voltage, but still allow that voltage to be changed.
• Reduce the part count per motor, by consolidating components into fewer packages and taking a different design path driving the motors.

As usual, I have a progression of design image captured through the process to give an idea of how the project unfolded:

1)  Decided on the core pieces to use, and approximate board size. CNC rev 2 is based around a single BGA FPGA, and an ARM Cortex-M3 chip I use heavily in other projects (LPC134x). The plan at this point was to drive 6 motors and allow USB from both the micro and from the FPGA (to eventually produce a working system without the micro)

2) Prototyping the component placement for a single motor block. Changes from CNC Rev1 are: Clamp diodes are now more integrated (rotated chip replaces 4 diodes that were on the other side of the board), using a level shifter chip rather than an arrangement of fets (each level shifter replaces 6 fets & a dozen resistors)

3)  Decided 6 was too many, dropped back to 5 motor blocks; Added header block for end-stop switches, and resistors / clamp diodes to feed back motor pins to the FPGA safely.

4) Routed the power trace for motor voltage; The header at the top allows the motor voltage to be changed by an expansion board, or the pins can just be jumpered to provide the 12V default.

5) Adding more support parts and starting to make some connections within the motor blocks and for the microcontroller.

6) Adding some more external connectivity; the 4-pin JST 2mm connectors are for external I2C connections, and there’s a 4×3 pin header that can be used to drive servos.

7) Prototyping the motor block connections

8) Adding yet more important stuff! The big header was only added temporarily though, to provide a linear target to attach pins to (to easily see that the motor block signals came out in a specific order)

9) Added analog current measurement stuff. I drop the FPGA’s USB port as I note space and pins are likely to be an issue, and I don’t really want to drop the uC anymore because it’s an easy way to get ADC results.

10) After much planning, have  decided on the FPGA orientation and started to map the pins to the fpga.

11) Finished mapping the motor blocks to the FPGA, and generally organized the analog stuff into a nice cranny up by the ATX connector.

12) Showing the breakout of fpga signals so far. I opted to allow using a much cheaper FPGA so not all of the pins are present/connected. In order to remedy this sometimes I run internal pins out through some of the (unconnected) outer pins. (I need all the I/O I can get!)

13) Starting to route the motor blocks to the FPGA. When the planning is done this is generally pretty simple.

14) Continuing that…

15) All motor blocks connected!

16) Started to route peripherals on the right side, and worked on organizing the remainder of the components to fit in available space.

17) Finished routing all the right-side signals! So far all the routed signals are all on one layer, pretty happy about that. There are around 90 signals connected to the FPGA at this point.

18) My attention turns to the microcontroller which is now almost fully routed, and I start routing 3v3 power and FPGA jtag.

19) FPGA Power. Srs bzness. the really thin traces are gnd, and are only there to keep track of connected things, there will be a gnd fill later. Ultimately this is not going to be a very demanding application for the FPGA, the pins will not be switching at a high frequency.

20) With almost everything else done, attention turns to finishing the power routing for the level shifters on the motor blocks.

21) That is finished and ground fill is added. This is the electrically complete board.

22) Even that was not entirely complete… Also the component names needed to be adjusted to ensure they are readable. This is effectively the final board.

I have another bigger version of this image up on flickr:

Do be sure to point out any flaws ;)

I expect to get the first copies of this board back today (maybe) – I sent this board off in Laen’s order to get prototypes back relatively cheaply in case there are bugs, but if there aren’t problems I will probably manufacture a few dozen more.

So now the blog entries on this reach the current point in time, and I have to do actual work to write more of this path – wish me luck :)

(Will be continued in part 5)

The ARM Chip I was using on the CNC board (NXP LPC2927) has two JTAG chains – one of them is a boundary scan / flash (and who knows what else) chain, and the other is for the ARM9 standard debug interface. I only really wanted to program the flash, so I started out with the flash chain – There was some documentation for the JTAG flash interface of a previous chip in the series so I was hopeful this one would be similar.

Unfortunately it was not meant to be. The enable bits / initial handshake sequence for the flash controller on this chip seems to be entirely different than the earlier one, sometime I may go back and find the right bits to make that work, but I shifted my focus to using the ARM debug interface. The first thing I noticed, is that it didn’t work :) As it turns out (after connecting the layers of deep indirection in the documentation), you must have a crystal in a specific range of frequencies for it to work; After fixing that though, I began to make progress on that front. the ARM debug interface for this chip is relatively well documented in the ARM9 documentation on ARM’s site. Documentation always seems to leave something to be desired, but this was at least relatively unambiguous – and worked!

Effectively, the ARM9 chips (also most other ARM chips), for a debug interface, simply intercept the processor’s instruction and data busses, and allow you to single step the processor. So you can perform operations by injecting the instruction you wish to execute, and single stepping. You can write a register to an arbitrary memory location, which causes it to be intercepted on the data bus (afterwards you can read the data bus) – Similarly you can read from memory and it will end up reading the value you insert onto the data bus into a register. It’s a rather minimal and effective debugging interface, it doesn’t consume much in the way of hardware resources, though the software to do anything useful with it has to be a bit complicated as a result.

Since the single step operations capture the data bus, it’s not possible to directly modify or read system memory through them, but there is another special provision for doing this, for executing individual instructions synchronized with the normal CPU clock that can interact with memory. So, I wrote a handful of wrappers that would allow me to manipulate the CPU’s registers and read from / write to memory, and around that built a small program that wrote the flash using the system’s internal flash controller.

With that literal pile of work behind me, I set off building software for the ARM chip itself. A short amount of time later, I had a blinking LED (Because this is naturally the most important thing to do with /any/ piece of hardware)

(Not visible: LEDs blinking)

(Continuity note: Note that the above board is not the same one as the board shown in part 1! At some point in messing with the JTAG chains I became sufficiently frustrated with the quality of connections on the first board, which had been reworked a few too many times perhaps, that I built a second board and took special care in making sure the JTAG chains and other important connections were in good shape. It’s a bit less than fully populated because… placing some 400-500 components is HARD!)

(More to come in part 4…)

I took the one CNC board I had assembled, such a long time back, and subjected it to an initial smoke test (connecting the power, that is). There was smoke. Not discouraged by the loss of a chip or two, I took a further look. I found that the assembly of the first board had hit a number of major snags; The board was 2oz copper in order to be capable of routing large current loads to the motors – but the groundplane was exceptionally difficult to solder to, even though the pads have thermals. I found that one of the chips broke because a resistor intended to keep an “enable” signal low was not connected to the groundplane, and the other one, a FPGA, was installed backwards (these FPGAs have two circles on the top which could indicate pin 1; Unfortunately the wrong one was chosen and I didn’t check.)

Undeterred, I pressed forwards with getting this board to work. I replaced the FPGA and rotated the other one, doublechecked a lot of signals (there were still some components on the back side of the board that were not properly connected to ground). All the poor connections were on the back side of the board, the top side had been reflowed and the connections seemed uniformly good there.

After those fixes and some cleanup, ran the smoke test again – The board powered up without smoke! A first small victory down this path – But many more things remained.

So, let me tell you about JTAG. I made a post on jtag a long time ago, when I was first starting to mess with it; but for this project I decided to build my own JTAG tools to program the chips involved & for other nefarious purposes.

I have made a few starts  towards my own jtag stack over time, first was an AVR-based board intended to program all manner of things – This project ultimately stagnated as the jtag level shifting interfered with actually programming the AVR chip itself. Despite a fix, building out the stack was a big project and never was completed.

While I was designing the CNC board though, I had the idea for a more specific debugging helper tool geared for it, and not too long after designing the CNC board, I did build such a device based on a chip I had come to know and love (and built a USB stack for…) – this was the ucHelper, PCBs shown below.

ucHelper is really just a minimal JTAG and serial interface board – Being exactly what I needed for programming and debugging here though, I got started on writing the code for it.

(more in part 3)

The CNC Controller in the last two posts was my first big move towards realizing the idea; Being  a stubborn sort, I’ve wanted to build the entire thing entirely myself – Historically this has been both a good and a bad decision; I like owning the entire stack in a project, but it comes at a price – Actually building and completing the project takes a lot longer. The upside is I get a lot of experience from such projects, and learn a lot about a wide variety of things – this is ultimately the reason I do it so much.

I did finally concede to use an existing 3D Printer hardware design, and near the end of last year built a Prusa Mendel from a kit of printed parts & hardware (pic below)

However I am still quite determined to own the electronics. Around the very end of 2011 I finally decided to put the effort into making this project happen, and started to bring up the CNC board I had designed.

(More in part 2)

Since I opted to stop posting on a fixed schedule, that seems to have eliminated any hope of regular updates – oh well.

So, I have been largely tied up in a (Very big) project that’s still secret, I’m not saying much about it. But there have been a few bits of progress in other areas – Most notably, I finally got a CNC controller board populated!

Isn’t it lovely?  I certainly think so, after all the work that went into getting this far :)

Sadly, I won’t really get much further at the moment (need to get back to an all-consuming secret project), but this has marked a pretty big milestone in a few of my projects (the reflow controller also works pretty nicely!)

I’ll be sure to take some time and write up these when I make some more progress (or just get sick of working on the more important stuff again)

Over the past month I have been designing a CNC controller for various small projects I’ve been kicking around (oh things like 3d printing, building a pick&place, and some other random thoughts)

Being the hopelessly stubborn sort that I am, I decided to build it from scratch. The design work for something like this is something I enjoy immensely, and while I don’t always get everything right the first time (There are a few inefficiencies, but nothing terrible), it’s been a lot of fun and a good learning experience.

Here’s an image of the final board design, and past the break is a very long thread of text and images showing the steps getting to this point:

(After weeks of looking at this really closely, it seems amazing to me how small the board actually is)

Let’s start with the big questions:

Why design a stepper motor controller when so many already exist?

Mainly because I hadn’t done so before, and it seemed like a fun idea. Also because I have the unhealthy tendency to reinvent the wheel, and I’m not about to do anything to fix that. ;) Additionally though, I wanted to make something better than just the standard off-the-shelf motor controller

What are the design goals for this project?

The core design goal is to be very flexible. This system is rather overkill as a result, it can drive 12V and 5V steppers, and also has a lower current variable voltage rail intended to drive voltages between 5V and 12V. There is an ARM microcontroller that handles all the interface and data management, and it’s attached to two FPGAs which will be able to drive the steppers with very precise timings. As it stands, the board is designed to drive 5 stepper motors and additionally a bank of 8 standard R/C servos for miscellaneous other stuff; And each of the stepper interfaces could be used to drive two normal motors too, or resistive elements for heating, or …

Being easy to repurpose and reuse with other systems was a priority too; This design uses motor connectors which should be compatible with the system makerbot is using. For everything else (end stops, etc) it’s using 2 and 4 pin 1mm pitch JST-SH connectors which are also pretty common. There are two I2C busses which are designed to accept arbitrary sensors or controllers to be added to the system

Will you sell them / release design files / etc?

Likely one or more of the above,  but I want to get it working first.

I’ll be happy to field other questions, let me know if you have any!

About design challenges:

This board started with  the basic stepper motor design, and in trying to make it as useful as possible – I wound up with a motor controller as a train of 4 H-Bridges, attached to a local per-motor power rail. Each h-bridge would get two control lines from the FPGA (drive up/down), and one sense line, which tells the FPGA whether the voltage is above about 1V or so. Not a lot of information but will probably come in handy.

Ultimately this area is where the design flaw in this first revision is – The output stage of the H-Bridge is driven by a pair of FETs, a P-Fet to pull up, and an N-Fet to pull down. Since the P-Fet’s gate needs to be near the high level (these P-fets will turn on when the voltage is less than the high voltage minus a volt or so), I’m using a second stage of fets to invert the FPGA signal and make sure it can fully be turned off. I am driving the N-Fet’s gate directly with the FPGA though, and while the 3.3V signal is high enough to turn on the FET, it’s not high enough to turn it “all the way” on, so it operates in a less efficient mode. This effectively limits the amount of current I can drive efficiently to about 1A instead of 2A or so which I was designing for – but that’s not a major loss for my application so I’m going ahead with this revision anyway. I’ve found some level shifter chips that will use in subsequent versions which will solve this problem for me though, and drive both P and N FETs fully.

Routing this board was also a fun challenge, I tried to keep as many of the signals as possible on the top layer to have good return paths to ground. Ultimately this didn’t work out to be perfect, but it’s pretty good. The motor area in particular is very clean on the back side, and only has the ground plane and local power traces.

In order to make the input section as dense as possible, there are actually two PCB levels. There’s a second PCB which will stack on top of the first one, attached with one rectangular board-board connector mating, and another one with ribbon cables; This makes it possible to also enclude end-stops, rotary encoder inputs (which may not be really interesting, but may be used for something else entirely) and LEDs per motor. It’s also used for the I2C connections.

As is my custom, I have taken screenshots of the board’s layout at various arbitrary points in the design process, and the result is that you can see how the board has evolved over time.

This project has been extremely long running, as far as projects go, so I have accumulated a massive 27 WIP images. They are here below with inline commentary for your amusement:

First things first – Settled on a core design and layout, and the set of parts to use. This greatly shaped what the rest of the board ended up looking like

Added some more important things: Power and interface. The line voltage footprint was added for spacing reasons, and because I am considering building a line voltage -> ATX module to fit on top at some point. But that’s a crazy project in its own right.

Duplicated the motor tile for all 5 motors… And ended up with a huge mess of components!

Mostly sorted out the motor tiles at this point, and added FPGAs

The power distribution traces have been added. These are >100 mil traces for high current capacity (And the PCB will be 2Oz copper); Oh also added an ARM

Added the switching power supply for the variable voltage rail, and started working on layout for the per-motor power distribution on the first two tiles. Added 4 R/C servo outputs (was planning on putting the other 4 on the stacked second layer board)

Decided how the motor tiles should connect to the FPGA, for the first 3 tiles. Started working on routing them, and further layout/routing on the motor3-4 tiles.

Further progress routing attachments to the FPGA

More traces!

Yet more traces! Started thinking about second FPGA placement, and R/C servo connector layout

Many things here! Decided on a scheme for  attaching I/O to the upper level I/O board, Also decided to put all 8 R/C servo interfaces on the bottom level to be consistent (after realizing that the top board would need to stick forward, so the JST connectors will be remotely close to the front of the other pins). And also designed the voltage/current measuring circuts, whose components were stuffed up in the top middle for now.

Started routing the power enable lines from the motor2-3 tiles, this was a bit tricky as there’s no good place to put the traces except on the back side. With the other constraints in place there really isn’t another good place to put them.

Starting to route the second FPGA, messed with a ground plane up by the switching power supply.

Routed almost all the rest of the second FPGA!

Added FPGA jtag connector, started to organize current measuring components, and attached the FPGA2 to the uC in a convenient location

Added serial level shifter, and finished organizing the current measuring components – Starting their layout.

Added a serial flash and a second JTAG connector for the ARM. This isn’t a standard ARM jtag connector, but I didn’t have space for one, this will work well enough though.

Added components for a “shutdown” switch. Decided to add a 3.3V serial connection broken out to a header, and continued stuffing the power measurement components into the space near the CPU.

Started routing power for the first FPGA. There are 3 voltage levels to manage; GND, 3.3V, and 1.2V. Routing strategy was to run 1.2V on the top layer, 3.3V in the middle on the bottom layer, and GND will fill everything else. ARM cpu is similar, except 1.8V rather than 1.2V

Finished placing and routing (most of) the power measurement components! Also finished layout of the shutdown / serial header components in the middle of the top.

Starting to route some other stuff around, and power for the ARM

Finished JTAG signals

Finished ARM chip power routing!

Now finished second FPGA power too! So very close now :)

Went back and enabled the Names layer and repositioned all of the uncooperative part labels :)

Added ground fill. Added lots of vias, started vetting design for bad features in the ground fill & vias too close to pads & etc.

Add pick&place markers, some silkscreen, further vetting, overall is pretty much done at this point!

That’s the last image I have – I have made a few tiny changes since that (found some more vias too close to pads on the back layer)

And after this board was done, I went on to build the I/O board that will sit on top of it. That was far less difficult and the images I have are below:

I’ve had fun building this board but I’m rather glad this phase is over. I’m now sending the design to be produced and will have to order a large pile of parts to populate some boards with :)

Wish me luck!

With that said, there’s nothing to  show for this week besides minor progress on a few fronts; so here’s a picture of my desk as it stands pretty recently:

In the meantime however, I have received the reflow controller PCBs I mentioned a month ago! Some pictures are up on flickr, one is below – I don’t have it working yet but that will become a priority pretty soon.

Coming next:  I’m currently working pretty hard on a CNC controller for stepper motors and some other things; As usual my ideal is to build my own solution instead of using any existing one, so I’m desiging my own now. I will post a full writeup on it once I have it completed, but don’t want to share any details at the moment.

Happy new year, all.