Overclocking an Atmel 328P--"Seems Working"

Back when dinosaurs roamed the earth, I worked at a place where one of the dev guys was from Russia, and when you asked if he got his code right, he'd say, in a very thick accent, "seems working".  

Pretty soon every other tech started saying the same thing whenever they were ready to move on.

Boss: "Did you get that rack built out OK?"  Tech: "Seems working".

Boss: "Did you review the code for the new firewall's security policy?"  Tech: "Seems working".

Boss: "Is the CEO OK with his new home theater the shareholders built for him?"  Tech: "Seems working."    

This time I laid out a revised minimalist Atmel 328 development board to experiment with overclocking.  

Yep, seems working.  At least for blinking an LED.  

From various web pages I found (here and here for instance), overlocking these ubiquitous 8 bit MCUs is pretty common, and at least one user went all the up to 50Mhz--that's 30Mhz over what the 328 is designed to run--and lived to tell the tale--but many users caution that overclocked things work until they don't.

PCBs for the overclocking project come from audiodiwhy's generous sponsor, PCBWAY.  Please help out this blog and check 'em out.  

I wanted to mess with the basics, having never overclocked anything before, so I laid out a slightly larger footprint "AVR minimalist development board (post about original design is here) to accommodate basic experimenation. 

Why bigger? I wanted to be able to get my finger onto the MCU chip to see if was heating up and be able to quickly get to the crystal to desolder it and drop in something faster (or slower). 

For experiments sometimes bigger is better, right?

As far as I can tell, after letting a main.c blink code run for about 20 minutes, with a 30Mhz crystal, the Atmel 328P chip wasn't heating up; it didn't seem to be drawing appreciably more current either (I powered the on board regulator using a Siglent 3303 at 9VDC, 100mA max). This seemed almost too easy.

You can get a box of crystals cheap (I paid about $10USB for what you see here) from AliExpress. Hours of fun.  

 

The populated board is built from common junk-box type parts. It's the same schematic used in the dirty digital LFO, with a larger footprint.

The ZIF socket (chunky blue thing, top right), which would have allowed super quick swaps of Atmel 328's to see if chip A survived overclocking better than chip B, was the idea didn't pan out. The drills I designed into this post's PCB, to accommodate the ZIP socket, weren't big enough in diameter, so I ended up using a normal 28 bit skinny socket for this build. For experiments like this a ZIF socket would have helped, but oh well.  

I have already laid out a REV3 board with bigger drills to accommodate the ZIF. I will get that fabbed as well, um....sometime.....eventually?

Overall you can barely see a 30Mhz xtal indeed runs a blink C program at almost twice the speed of a 16Mhz xtal board with similar design, parts, and MCU. the LED on the left is flashing faintly....junk box! 

Just as expected. 

Here is the test code used:

#include <avr/io.h>

#include <stdio.h>

void Delay(void);

int main(void)

{

//DDRB = 0x20; /* set bit 5 of DDR register which makes PB5 an output */

DDRB = 0b11111111; // 1 is output

while(1)

{

 

PORTB = 0b11111111; // switch LED on

Delay();

 

PORTB = 0b00000000; // switch LED off

Delay();

}

}

void Delay(void)

{

volatile unsigned long count = 150000;

while (count--);

}

The Dirty Digital LFO needs a faster output frequency, and it's arguably easier to put in a faster crystal and overclock it than do a bunch of code optimization. But will it still work?  Will ADC get screwed up?  Will the AVR chip turn cherry red? Will I burn down my lab? One of these days I will drop a faster crystal in there, change the FCPU variable, and see what happens.  

For now, time to move on.  At the very least, use a 20Mhz xtal in your C work right?--the AVR is designed for that, even though the Arduino Uno R3 uses 16Mhz.  

You can get this post's overclock experimenters board, BOM, PDFs of board layout, eagle files, etc., from PCBway's, project site, go here. Have fun--quickly! 

Simple Buffer/Clamp for Analog to Digital Conversion

Hello Again.  

Let's get back to the analog to digital side of things; specifically, a buffer circuit to prepare a signal for an analog to digital converter, or ADC. 

 A genuine Arduino Uno R3 costs about $20USD, has built in ADC's, and you can blow up its ADC circuitry from overvoltage, so you want to treat that with care....

Dedicated ADC chips have voltage limits as wekk--check out the datasheet for the popular MCP3008 (here); where max voltage at input is 7VDC, and ADC inputs can only be .6V over that. This chip costs approximately $3.75USD as of the writing of this post, so you want to avoid blowing up that IC as well.

Design goals for the ADC buffer: 

Must haves:

• a simple clamp to make sure the voltages presented to the ADC protect the circuitry.  
• Some way to attenuate the incoming signal.
• A way to buffer the incoming signal.

Also nice to have:

• A simple means to set a bias offset for the incoming signal--otherwise an LFO's sine wave (for instance) could get clipped
• A way to control the output impedence flowing to the ADC IC or MPU's ADC
• The ability to bring in the signal via 3.5" jack (for Euro modular synth
• A reference signal to send to the ADC if needed
• Thru hole design. Easier for bench experiments.
• Easy to find parts--resistors, caps, PDIP op amps; junk box stuff.

From the dirty digital LFO project (post here), I've hit on something I like that perhaps meets all these goals. 

I whipped up a small board in Eagle and sent it out to this humble blogger's sponsor, PCBWAY, for fab. 

It's back!

Here it is:

Fair warning: for this initial layout I made mistakes; consequently, there were "bodges" or "kludge wires" needed to make the PCB work--in other words, I had to cut traces and solder in small wires to get the PCB to work. 

I will have another set of boards made with these fixes included....again with the help of  PCBWAY who are always enthusiastic and happy to assist (shameless sponsor plug).

Once Rev 2 is in and tests OK, I will upload all of this, but I am pretty confident that REV2 of this design and layout will be good to go.

Designing the buffer: Here's the back of the napkin drawing that preceded the PCB:

It's basically a dual op amp summing mixer with a single input and a zener clamp at output. For a true mixer, you'd add more resistors parallel to R1.....you can find this basic and ubiquitous circuit fragment explained here. 

 

The offset at 1B + provides the bias offset while "level" port attenuates the signal.  These can be trimmers, more resistors, or whatever, but I had a lot of cheap 9mm PCB pots lying around, so that footprint made it to this design.

Fluffing the Buffer: This post's PCB follows the napkin layout pretty closely, but Rev 1 got into trouble when normalling reference voltages to the two input jacks.

Here's the corrected schematic after cutting traces and soldering in kludge wires:

In Ref'rence: The voltage at INREF, which feeds resistor R1 and the inverting input of IC3A, is formed by R4, R5, and the LEVEL pot (it could be a trimmer).  All 3 values at 100K 1% produce very close to 5VDC relative to ground if you use + and - 15V to power this PCB.  

Again with +/- 15V DC power, for 3.3Vmax output, R5 should be 40K while the pot and R4 are 100K and of course you want to use a 3.3V zener at output, or close.  

You can use an analog circuit simulator to try out resistors values for the circuit reference voltage here; do your math to keep your MCU safe; also please check your max voltage at the OUT pad to make sure the zener is working as a clamp before hooking the buffer into an expensive IC.

   

The only surviving and fully useless bench photo of a finished REV1 board:

Posting in the buff: With wire fixes in place and errant traces cut, the REV1 board works when viewing its output with a scope, but as far as protecting an MCU, I needed to dive deeper. 

I gave it a try with an Arduino clone:

I didn't use the reference out to AREF in of the Arduino--so there were minor scaling errors, but adding a voltage reference could be added in future designs.

Specifically, The Arduino of choice for this proof of concept was a Pro Micro clone.  

It has a 32u4 Atmel MCU, a great chip for DiWhy because it has built-in USB capabilities; no need for an expensive FTDI chip or clone; all the USB capability is built into the MCU itself. More about USB to Serial conversion in the posts starting here; more about USB and the 32u4 coded with C is here.  

Furthermore, there are "maker" libraries, ready to go, that expose the 32u4's USB capabilities with simple methods--for example, you can use this same USB-ready MCU to emulate an HID USB Windows keyboard--more in the post here.  

This time I am using the very capable  MIDIUSB library from the Arduino folks, to test the buffer. 

The simple Sketch language code below allows the user to control MIDI continous controller 72 on channel 1, and assumes the ADC buffer output is wired to the Arduino's A0 input.

#include "MIDIUSB.h"

int x = 0;      

int y = 0;

 void controlChange(byte channel, byte control, byte value)

    {

    midiEventPacket_t event = {0x0B, 0xB0 | channel, control, value};

    MidiUSB.sendMIDI(event);

    }

void setup() 

{

//Serial.begin(9600)

pinMode(A0, INPUT); 

}

void loop() 

{

   x = analogRead(A0);

  y = map(x,0,1024,0,127);

 //Serial.println(y);

 controlChange(1,72,y);

/*next line debug "Arduino-style" */

//Serial.println(y)

 MidiUSB.flush();

}

It works with this Arturia Solina Plugin; the frequency sweep was generated by the output of an LFO Prime module. I could amplify its signal to 20V P/P--in other words, way above the maximum 5.6V DC--but the zener clamped this errant voltage to about 5V and the MCU was fine.

Cool!

I might flesh out this idea and post to github finished code and PCBs for a dedicated Control Voltage to Continuous Controller ("CV to CC") module in a future post.

And yes, there are other ways to do this--for instance, there are software CV to CC plug-ins out there--but this soimple hardware and code so this is how I did it.  

Code-ah: No need to power the Arduino externally--USB does that, but I had to tie the ground from the buffer board to one of the GND pins on the Arduino. The buffer during the test was powered the from a simple Frac power supply (post here on how to this linear supply).

As far as improving/modding the buffer circuit, a voltage reference board or dedicated IC could be used instead of the R4/R5/pot network; you could use jumpers to select the reference voltage from a series of resistors; and the PCB could be made a lot smaller using SMT parts for inclusion into a project, but this board is more for bench experiments and designed for simplicity. Good enough.

Best of all, for this board, with all the parts laid out on the bench, it should only take a few minutes to build. 

I'll get more of these made, possibly improve on the CV to CC proof of concept, or to incorporate into a larger project, and post the whole thing, down the road.  

Until then, don't buffer the fumes!

 

Long Live FracRak! Frac Power!!

If you're going to build your own audio gear, you probably have to put it in a case, right?  Enclosure?  Rack?

Indeed, that's where the choices start. 

My DiWhy friends work with Euro mostly for their modular synthesizer projects, some MOTM, and a few the social media savvy "kosmo" format.

My geek audio buddies still aren't sure why I build almost exclusively in Paia Frac, but I'm sticking to it.  

It's a pretty uncommon format, but this week as I was blowing up power supplies I was glad I use to it rather than some of the more popular choices.

+/- 15V Frac power with temp front panel....

I was doing some recording when all of a sudden from my noise generator came a nasty 60 cycle hum.  Not all my modules did this, just a few, and I quickly traced it to one of my original (circa 2003) Frac power supplies. that powered the noise modules as well as a few balanced modulators.

I have already posted building a custom 15-15V linear supply (post is here).  

I hate 60 cycle hum, and it's more fun to build something new than fix broken, so let's build another.  

Frac power is modular, like everything else about it, and modular engineering is good engineeering.

A new linear supply for Frac is easy--especially when you have brand new boards provided by my generous sponsor PCBWAY--and uses mostly junk box parts:

 

I plugged in the new supply to test--second time in a day!!--SMOKE!  

This blew up a surplus16VAC 40VA wall wart as well as both of the regulators.  

Hello?  

The diodes used to safeguard the regs from reverse voltage looked like chunky diodes in my junk box, but turns out they were precision low value high watt resistors. 

Ooops.  that's what you get when using junk box components and a lack of caution and patience.

Not a big deal to replace impacted parts and put in diodes where they are needed; now it works.

The good news: when you have a power supply problem with Frac, it doesn't take out your whole rig, and conversely, if you have a bad module (DiWhy--that will never happen right?) it won't take out your rig's only power supply.  

Frac is also a reasonable size, not too tiny, but not like MOTM or Moog or synthesizer.com formats where it takes up your entire living room;  Frac is affordable, fits in a 3u 19" rack case, and maybe best of all, PAIA is a cool small mom and pop type company, left over from the phone-phreak/Radioshack electronics geek 70's. There aren't too many of those any longer.

Note that PAIA supply I laid out and built (this clone is based on some of PAIA's earlier 9700 series designs, but beefier in terms of sourcing and sinking more current) use a ton of .1uF caps close the the .1mil DC headers. I discussed these inclusions with some pro EE's--I am not one--and was told that all these .1uF caps makes no different close to the headers and can be omitted--these filter caps need to go on the modules that are being powered, not here. 

So for now, you can leave 'em off.  I have left them off my recent builds and can't hear any difference with ripple, buzz, or other unwanted distortion.

You can download the gerber and BOM for the power supply I use here from PCBway's project page, here. 

Please help support this geeky blog by checking PCBWAY out and consider using them for any fab work you dream up.  

If you come up with any sort of mod or change to the power supply comment below, I am curious what you folks, my trusted readers, come up with.

See ya next time.

MCP4922 Library for Atmel 328 MCU--Simple Low Cost Dual DAC Made Easy

Quick one this time.  I'm continuing coding in Embedded C for Atmel 328 MCU's, this time to write a driver for an inexpensive and useful Digital to Analog Converter--a DAC--The MCP4922 from Microchip. 

Datasheet is here--the 4922 is inexpensive, available in a DIP package for easy breadboarding, and  easy to program. This is a good chip for Audio DiWHY.

Let's get to it.

For my tests I wired it up like this: 

Wired this up on the bench:

The toolchain is my usual: Windows 10 running Atmel Studio 7; an Atmel ICE programmer, and a minimalist 328 development board of my own design that I got from my generous sponsor--PCBWAY;  read about the board here and order or get the gerber here.

The library didn't work at first--that's because I made a stupid mistake. The datasheet clearly says to make this chip work with SPI you do a CS pulldown, send 16 bits on each clock, then do a CS pullup. 

But I missed that while reviewing the datasheet, and the SPI3.h library I wrote/borrowed/revised  (post here) didn't have this exact cadence. I literally woke up in the middle of the night realizing what I had done wrong, and it took some will power not to go to the bench at 3AM to fix it. Next morning I wrote this addition to the preexisting Atmel 328 SPI3.h and SPI3.c libraries:

uint8_t SPI_TransferTx16_SingleCS(unsigned char a, unsigned char b)

 {

unsigned char x;

SELECT();

x = SPI_Transfer(a);

x = SPI_Transfer(b);

DESELECT();

return x;

 }

where a is MSB and b is LSB.

Fixed!

 Now I can see both analog outs on my scope:

And can also spy on the SPI using Pulseview--looks right:

Using the MCP4922 library.  The files you need are MCP4922.c and MCP4922.h. The rest of what I githubbed are simple examples and support files.

As of the writing of this blog post, here's a really quick rundown of the functions in the library:

/************/

/* output_4922  send data to outputs of chip.  

In my example, 0 = 0V, 4095 = about 5V.

  data is 0 to 4095; channel is 0 for channel A, any other uint8_t for Chan B 

 default chan A, unbuffered ref, gain 1, no shutdown */

 output_4922(uint16_t data, uint8_t channel) 

/* the 4922 has a buffer for the reference signal.  In case you want to use a reference that has a very low source current.

enter 0 to shut off the ref buffer; any other number < 255 to turn it on.

*/

 buffer_4922(uint8_t buff)

/* gain_4922--for highly accurate output, you can use a 2.048V reference.

enter damnloud = 1 for gain = 1, enter 2, any other number < 255 that's not = 1, for gain = 2 

Apply your 2.048 ref, then turn the gain up 2x. Now you should get, 0 = 0mV at output, 100 = 100mV a output, 1022 = 1022mV at output. 

Should be damn accurate! Very cool  */

/* 

enable_4922_output

enter 0 for silence to kill the 4922 analog outs and put the chip into low power mode

any other uint8_t to make it operate normally.  */

enable_4922_output(uint8_t silence)

/************/

That's about all the chip can do, so that might be all I code for this, at least for now.

You get my embedded C library for MCP4922, along with the example code for making the traces move at my github, here. The updated SPI library is here. I'll be using it in future posts. 

Until then, don't breathe the fumes!