Posts Tagged ‘software’


My magic AVR build script


Don’t get me wrong, I like make…  Hah! Yeah, right!

make has its place, no doubt, but small microcontroller projects not so much.  In my projects I like to just start coding, pulling in existing code where it makes sense.  Maintaining a makefile for that gets old really fast, and is massively overwrought compared to the requirements.

So, over the last couple years I’ve developed my own scripts to build AVR projects.  The latest variation has just received a major speedup, so I thought I’d share it along with some selected Bash tips.

Read the rest of this entry ?


Graphic demonstration of remote clock sync


So I’ve been perfecting the method I use in my current project to sync up the two clocks.  In a previous post I explained the generation method, which consists of using a master-generated reference pulse on the data bus to drive a PID that pushes the slave’s crystal frequency around to get them to line up.

Originally I’d maintained a local difference between the master and slave clocks, and any request for the clock would be adjusted by that.  However, I realized it would be very useful for the actual hardware timers to line up with the same values, and it turned out to be almost a trivial change.  Instead of just taking the offset and storing it, I pause the timers and reset them with a value that’s adjusted by the offset (plus a fudge factor for the time it takes to actually change the timers).  Any slight deviation left over can be handled by the I and D of the PID controller.

The main cycle counter is actually two daisy-chained 16-bit timers, and the daisy-chain mechanism is what on Xmega is called an “event”.  If I select the right event channel (0 out of 0..7) and flip a few config bits, I can output the 16th bit of the cycle counter to a pin, which I can then connect my scope to.  I hooked up my scope to this output on both the master and slave event outputs, and set it to trigger off the master’s pulse.

Initially there is only a master trace (channel 1) visible, with the slave (on channel 3) somewhere entirely else along the 488.3KHz cycle period (32MHz / 16 bits).  Halfway through the video I hit the key that triggers the sync protocol, and you can immediately see the slave’s clock trace show up and home in on a lock.

A quick eye-ball measurement of the jitter and delay gives me about a 1 cycle average delay (32MHz cycle) or about 31nS, and a worst-case jitter of about +-2 cycles or about 62nS. I’m betting some of this has to do with the tuning of my PID, as I can clearly see some periodic overshoot in the crystal adjustment parameter. My goal was supposed to be around 25,000nS if I remember right, so I think I’ve managed fairly well ;-)

Next step is to trigger a single pulse at another time and use that to start the ADC’s conversion clock…


Getting started with nrf24: Hardware connection


The nrf24 chips are all SPI-based, which means they use a bit clock (SCK), chip select (CS#), and two data lines (MISO, MOSI) to communicate with the host.  In addition, there is a chip enable (CE) that is used as an external control over the radio itself.  Finally, if your application calls for it, you can elect to connect the interrupt line (IRQ), which tells you when various events complete within the nrf24 itself, to save you from status polling.

I won’t cover the various non-digital connections at this point, but rather leave that to other sources such as the schematic for SparkFun’s nrf24l01+ module.  I’ll probably write a section on that eventually though, stay tuned.

Now, to connect it to your average microcontroller, you simply want to find the SCK/MISO/MOSI pins and connect them straight across.  The CS# pin may or may not go to one labeled on the microcontroller as such (or SS# for “slave select”), and in general it doesn’t matter because most microcontrollers do not maintain automatic control over the slave/chip select lines in master mode, since there could be an arbitrary number of them.  CE is even more loose as far as were you connect it, since it’s not actually part of the SPI interface itself anyway.  IRQ would ideally connect to a microcontroller pin that’s capable of actually triggering an interrupt, should you wish to use that functionality.

Here’s the nrf24l01+ connected up to an ATmegaXX8:

An Xmega is “better” since you can use any of the “serial” ports you want, and since every single pin is capable of triggering an interrupt you can wire IRQ anywhere you want as well:

However, if you are prepared to “bitbang” your interface, you can connect it any which way you want.  If communication speed and efficiency is not your main concern, this can make your board routing significantly easier:

A special case are the various nrf24 chips which also contain microcontrollers.  Examples are the nrf24LE1 and nrf24LU1(+).  The actually SPI interface is present inside the chip, but instead of having to wire it up, they’ve simply connected them inside the chip.  In that sense it’s almost the same as connecting up a nrf24l01+ to a regular 8051 microcontroller and using the existing SPI registers, except you’re just using a different SPI port.  Kindof.

Now another option to seriously consider in your PCB design is that of actually driving the chip’s power entirely from the microcontroller.  This gives you the ability to completely turn off the chip if you so desire (for power savings), or to hard reset the chip in case it goes wonky (which I seem to have happen on a regular basis):

Be sure that the maximum current of the nrf24l01+ does not exceed that which your microcontroller can supply.  In the above case, the Xmega is capable of driving 20mA on each pin, which is plenty of headroom over the 13.5mA max draw of the nrf24l01+.  If your chip doesn’t drive that hard, you can simply connect multiple pins together.  Just make sure those pins all turn on at exactly the same time, or you’ll short out your power supply and probably fry your microcontroller…

The next post will cover the software side of the physical connection: getting and setting registers, transferring actual packet data, and making the radio actually radiate.


Getting started with nrf24: Introduction


So anybody who’s been following my blog for the last few weeks will have noticed I’ve been fighting with the nrf24 series of chips, trying to get a wireless protocol in place I can use for program & debug capabilities.  Unfortunately, finding any kind of coherent and properly documented example code, or tutorials that make sense, has been rather hard.  I’ve found a few that at least got me partially started, in particular diyembedded‘s tutorials even though they’re based on the PIC and ARM.  However, the many and varied code examples all seem to say slightly different things, generally in less than straightforward ways.  Thus, I’m going to attempt to write my own tutorial series, as I bootstrap my way up through the available functionality.  It’s going to be very code-based, yet hopefully in a form that’s not too confusing.  This will also provide me with the opportunity to solidify my own understanding of the chip(s).

To start things off, the nrf24 series of chips from Nordic Semiconductor have gained a lot of popularity both in product and DIY circles because of their (relative) simplicity and low cost.  The radios themselves operate in the 2.4GHz band, and have a maximum air bitrate of 2Mbps in a 2MHz channel.  They use a GFSK encoding with a -82dBm sensitivity at 2Mbps, giving them a range in the 10’s of meters on average.  There are relatively few external components required, though I’ve had some problems there myself…

The tutorial sections themselves are [will be]:

  1. Hardware connection
  2. Physical layer communication
  3. Trivial transmission
  4. …[TBD]

The sections will be linked here as they are written, and this will eventually be the root document for the tutorial.


Abirtrary clock generation (with benefits)


The product I’m working on right now has a load of very arcane requirements, forcing me to delve into areas totally new to me.  One of those is precision clocking, since the product requires synchronized capture of data across multiple units.  As such I went hunting for PLLs that would do the job I need.  The key is the ability to adjust the speed very slightly in order to synchronize multiple clocks on multiple units to the exact same speed over the long term.

TI’s CDCE9xx series of chips turned out to have all the right features.  Each chip in the series has an onboard VCXO, which allows me to tweak the exact speed of the crystal with a voltage input, up to +-150ppm.  The various chips in the line have differing numbers of PLLs, each with 2 outputs on separate dividers.  The 12+9 bit N/M divider and 7-bit predivider allow for almost any sane clock speed you can dream up.  Coupled with the right crystal, it does exactly what I need.

But, there’s the problem.  TI specifies a whole mess of arcane crystal parameters needed in order to make the pullable VCXO actually work.  The catch is that nobody selling crystals actually publishes most of those numbers.  That means that you can neither determine the pullability range of a given crystal, nor find a crystal that actually works.  They list a number of specific crystals that “should work”, but not only are those datasheets no more help, but nobody (Digikey, Newark, Mouser, or anybody else I can buy from) sells them.  Hard stop.

Well, as I was looking through the listed vendors hoping to get my hands on some at least some samples, I tried to focus on US-based companies so I could actually communicate with them (all the others are in China etc).  Turns out Pletronics is based in Lynnwood, Washington, just a couple hundred miles north of here.  I sent them an email asking if they could point me to a crystal that’s supposed to work with and be pullable by the CDCE9xx series, and got back an answer that surprised me, and made my week.  They happen to sell a part that’s a CDCE9xx and matching crystal in one package!

The FD77T is the biggest of that line, based on the CDCE949.  The package is all of 5x7mm, which is ever so slightly larger than the CDCE913 alone (5×6.4mm), and noticeable smaller than the CDCE949 (7.8×6.4mm).  Compared to the CDCE949, crystal, and related parts, it’s radically smaller and easier to deal with.  It takes VCCIO, VCCINT, I2C, and VCXO control and spits out 7 PLL outputs, end of story.  The smaller versions (FD7[345]T) have fewer PLLs and outputs, but in the exact same package.  Pletronics seems to stock the FD77T for at least sample quantities with 24MHz, 24.576MHz, and 25MHz crystals.

The kicker is that the 1,000 unit pricing I was quoted was in the $2.50 range.  That’s cheaper than either the CDCE913 or the high-spec crystal separately!

In order to do testing, I made up a tiny adapter board for the FD77T that brings out all the pins, supplies the 1.8V VCCINT, and adds an extra set of top-side headers for the I2C programming interface:

In order to program the actual chip, you have to set up a rather complex sequence of registers.  TI provides a program called ClockPro that does it for you, but it seems to be written in MatLab and is ludicrously slow.  To top it off, it’s Windoze only and doesn’t provide any easy way of getting the register values out in a form that can be programmed in.  I’ve had to resort to literally typing in hex from the binary show in the bit viewer, which is very error-prone and not much fun at all.  So last night I constructed a Python script that does the core PLL calculation, and this morning added code to use the BusPirate to set the clock.  So far it works like a charm!

The code uses an iterative method, but one I’ve already thought through as far as implementation in a microcontroller.  It works back from the target clock, first finding a Pdiv that results in a Fvco closest to the nominal 135MHz.  It then tries all valid Pdiv’s above and below that still fit within the 80-230MHz range.  For each Pdiv/Fvco combination, it tries all the N multipliers from 1 through the max 4095, checking if the multiplied frequency modulo the Fvco results in no remainder, producing a viable M.  From there it calculates the intermediate values required to shove into the PLL registers, and outputs an I2C string to the BusPirate to set the clock.

As useful as the above is, setting the clock speed can sometimes be something you want to do at run-time.  Or more likely, you just don’t want to have to go through all that trouble when prototyping requires you to change the clock.  To solve that problem, I also designed a board that includes a microcontroller:

Populating this board is lower priority, but it’ll happen sometime soon.  The Xmega32A4 on the right is intended to run a microcontroller version of the above algorithm, with some tweaks in place for performance.  Mostly that means trying to fit the calculation into common bit widths, and dealing with the cases where it can’t gracefully and efficiently.  The goal is to have a register set on the MCU accessible via the various available protocols (the upper row of the board is a straight copy of a “serial” port on the Xmega, providing hardware async serial, I2C, and SPI) that lets you simply say “I want xx.yyyMHz on pin X, go!” and get a clock out.  Things get a little bit more complicated when you ask it to deliver two different clocks on pins that share a PLL, but that’s only a matter of finding a common Fvco with which two Pdiv’s generate the requested clocks.

A more interesting feature of the code destined for the MCU is the ability to lock the crystal to an external pulse.  To do so you would designate one of the interface pins as a trigger, and configure it for a particular mode.  To start off, the MCU will switch its clock from the internal oscillator to one of the PLL’s outputs, thus creating a cycle counter based on the crystal.  When these pulses are detected on the pin, the MCU will compute the difference between the actual counter and the desired counter, and run a PID to generate the VCXO control voltage, thereby dragging the crystal back into alignment with the external source.

The trigger modes would be pulse-before-count, pulse-after-count, and pulse-per-X.   In the first, the controlling circuit is expected to provide a trigger pulse, and then set a register with the cycle count that it was supposed to be located at.  In the second, you would set the register before the trigger pulse.  In the last, you set the number of cycles that are supposed to occur between pulses that come at regular intervals.  This mode is ideal for interfacing with the 1PPS signal coming off a GPS receiver.  Run the MCU off Y1 at the base 24.576MHz frequency, set the register to 24,576,000, connect 1PPS to the right pin, and suddenly you have a locked atomic frequency.

I intend to sell both of these modules on my (still upcoming) webshop.  The bare module should probably run about $10, while the Xmega-based module will likely run around  $20-$25.  As usual, if you need one of these and can’t wait for the webshop, let me know and I’ll see what I can do.  Just remember the code for the MCU doesn’t exist just yet.


Xmega fractional baud-rate source code


Earlier I posted a spreadsheet I created that calculated the BSEL and BSCALE for the Xmega’s fractional baud-rate generator.  This works well to determine what the potential is for getting your chip to run a viable baud-rate for a given clock, but isn’t so useful when you actually want to write a configurable piece of code.

Since then I’ve developed two methods for generating the appropriate register settings for a given baud rate.  The first method was designed around the original constraints I had, which were that the CPU frequency and baud-rate were set statically in the source code, and never changed or dealt with programmatically.  As such, it’s a set of macros that determine the best available BSEL and BSCALE:

#ifndef __XMEGA_BAUD_H__
#define __XMEGA_BAUD_H__

#define _BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,bscale) (                \
((bscale) < 0) ?                                                      \
  (int)((((float)(f_cpu)/(8*(float)(baud)))-1)*(1<<-(bscale)))        \
: (int)((float)(f_cpu)/((1<<(bscale))*8*(float)(baud)))-1 )

#define _BSCALE(f_cpu,baud) (                                         \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-7) < 4096) ? -7 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-6) < 4096) ? -6 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-5) < 4096) ? -5 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-4) < 4096) ? -4 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-3) < 4096) ? -3 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-2) < 4096) ? -2 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,-1) < 4096) ? -1 :              \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,0) < 4096) ? 0 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,1) < 4096) ? 1 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,2) < 4096) ? 2 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,3) < 4096) ? 3 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,4) < 4096) ? 4 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,5) < 4096) ? 5 :                \
(_BAUD_BSEL_FROM_BAUDSCALE(f_cpu,baud,6) < 4096) ? 6 :                \
7 )

#define BSEL(f_cpu,baud)                                              \

#define BSCALE(f_cpu,baud) ((_BSCALE(f_cpu,baud)<0) ? (16+_BSCALE(f_cpu,baud)) : _BSCALE(f_cpu,baud))

#endif /* __XMEGA_BAUD_H__ */

(beware the line continuations!) Basically, the BSCALE macro steps through the +-7 range hunting for the highest legal (12-bit) BSEL value, and the BSEL macro uses that to generate the right divider.  A typical usage would be something like this:

#define F_CPU 32000000
#define BAUDRATE 115200


More recently I’ve been developing a more “object oriented” set of routines that allow me to stack one thing on top of another (more about that later).  As a result, I needed to develop a form of the above code that would work at runtime.  As you can see from the first macro in the above code, a naive approach would bring a microcontroller to its knees in a matter of seconds (as in: it could take entire seconds to calculate…).  In order to solve this problem I took a look at the problem from a different perspective, and ended up with the following code:

#define F_CPU 32000000

uint8_t xmega_usart_setspeed (USART_t *usart, uint32_t baud) {
  uint32_t div1k;
  uint8_t bscale = 0;
  uint16_t bsel;

  if (baud > (F_CPU/16)) return 0;

  div1k = ((F_CPU*128) / baud) - 1024;
  while ((div1k < 2096640) && (bscale < 7)) {
    div1k <<= 1;

  bsel = div1k >> 10;

  usart->BAUDCTRLA = bsel&0xff;
  usart->BAUDCTRLB = (bsel>>8) | ((16-bscale) << 4);

  return 1;

The above code will result in the best available baud rate, calculated with 0.1% precision (but does not guarantee 0.1% baud-rate accuracy), using only a single 32-bit divide.  My current headache prevents me from properly explaining how it works, but the clever reader should be able to puzzle it out pretty quickly.  I’ll try to replace this excuse with an actual explanation at some point in the future.  If I haven’t yet, write a comment reminding me….

If you’re running on a system with a variable system clock (e.g. stepping the clock up for a burst of performance and back down for a long sleep), you could easily modify the function to take the F_CPU as a function parameter rather than a #define.  Replacing the (F_CPU/16) with (F_CPU>>4) and (F_CPU*128) with (F_CPU<<7) might be necessary to hint the compiler, but everything else should work the same.  You could then precalculate and store the BAUDCTRL values for each clock speed, and swap them in as needed, or if your clock is more variable than that, just run the calculation each time.

I haven’t profiled the runtime of the code yet, but I suspect it’s well under 1000 cycles, dominated by the 32-bit divide.


Reduced-pin-count program+debug connector for Xmega


I’ve been struggling recently with the extremely small JST SH connectors, which are 1.0mm crimp-style.  No matter what wire I use, I can’t get them to stop breaking, and they’re a royal pain to put together in the first place.  This is a problem, because it’s one of the only connectors I can find that’s small enough to fit on my current project’s board with 6 pins.  I need those pins for power, ground, the two Xmega PDI lines, and a debug serial port.  Currently I connect either a standard AVR-ISP mkII or a Bluetooth serial adapter to the boards via this tiny connector, and all that wear and tear on the connector and wires is becoming quite evident.

I’m about to ditch Bluetooth for quite a few reasons, but that’s a whole other story.  Suffice it to say: the replacement will be an Xmega-based device, and that’s where this nifty little trick comes from.

I did some hunting and found that there actually is a connector that’s even smaller than the SH-6: USB micro-B.  It’s a hair narrower, and about 20% shallower, resulting in that much more board space to work my routing magic.  The only problem: USB only has 5 pins….

My first (or near enough) thought was “use the shield”.  Since I’d be constructing the cable from scratch, I can solder a 6th wire to the shield (which is not otherwise connected to anything but the cable’s braid) and use that as ground.  Cheesy, but functional.

Then I thought about how the PDI protocol is actually implemented.  I’d rewritten most of the PDI stack based on the example code in LUFA recently, and it turns out that PDI is basically a bidirectional synchronous serial protocol.  That means that RX and TX are both connected via 220R resistors to the PDI_DATA line, and XCK drives PDI_CLK.  This presents the possibility that the PDI and serial lines could be shared.

As it turns out, this works very nicely.  On my breadboard I hooked up an Xmega target and Xmega programmer, with a crazy serial loopback chain that routed from an FT232R through the programmer to the target, and out another FT232R.  The PDI and serial ports from the target are routed to the middle, where the resistors create PDI_DATA from RX and TX.  PDI_CLK, RX, and TX hop over to the three pins on the programmer.  The software running on the programmer is a two-port serial loop-through, with the exception of a “p” coming from the test computer.  In that case, it shuts down the normal serial port, starts up the PDI interface, confirms the chip’s signature, then switches back.

The end result is a 5-pin interconnect between the two chips with both full hardware programming and serial debugging capabilities.  As such, we can now route it through a USB micro-B connector ;-)

(click for larger, readable version)

Now, this won’t work with a “discrete” PDI prorgammer, since you only get the combined Rx+Tx line out of the programming header, and this trick depends on combining them on the device.  Thus, you pretty much have to have a “custom” unit doing the programming and serial bridging.  However, that’s exactly where I’m headed after Bluetooth bites the dust…