AVR – protofusion http://protofusion.org/wordpress Open Hardware and Software Thu, 12 Dec 2013 01:44:47 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.3 11753368 Open Hardware Pogo-Pin Programmer http://protofusion.org/wordpress/2013/05/open-hardware-pogo-pin-programmer/ http://protofusion.org/wordpress/2013/05/open-hardware-pogo-pin-programmer/#comments Thu, 09 May 2013 04:12:41 +0000 http://protofusion.org/wordpress/?p=1613 ]]> ProtoProg adapter and test PCB

The ProtoProg is a small open source hardware pogo pin programming solution. The ProtoProg does not need a physical connector on the board, it uses surface-mount pads for signals and thru-holes for alignment. Two standard footprints are available, the smallest of which takes up very little space–only 7.6mm x 1.2mm!

Design


The ProtoProg was originally designed for use with AVR microcontroller programming (using 6 pins), but this design can easily be repurposed for other programmers. Several footprints are available for this programming connector as shown on the test PCB above, but only two are recommended for real-world use:

  • J1 (ProtoProg Standard) – Small pads with alignment holes (8 pins required)
  • J4 (ProtoProg Micro) – Small pads with alignment vias (6 pins required)

Choose the micro footprint for small size

J4 does not include any dedicated alignment holes  and instead uses two of the signal lines with vias for pin alignment. The pogo pins do not go through the vias, they rest on top of the vias and “snap” into place for alignment. This footprint is very compact.

Choose the standard footprint for easier alignment

The standard footprint includes dedicated alignment holes, and requires 8 pins to be populated on the ProtoProg  programming adapter. This connector takes up more lateral room, but allows for easier insertion and likely more reliable long-term use.

Assembling the ProtoProg

ProtoProg assembly - step 1

To begin, make sure you have these components:

  • 6 or 8 pogo pins (depending on which footprint you want to use) [ebay]
  • 2 ProtoProg PCBs (one is used for alignment) [gerbers provided below]
  • Vise (recommended)
  • Soldering iron and solder

ProtoProg assembly - step 2

First, take one of the ProtoProg adapter PCBs and solder a 6×2 pin header on the top side.

If you are using an AVR programmer, I recommend soldering the VCC solderjumper on the top of the PCB. This allows your programmer to detect target voltage and power the target (if your programmer supports this feature). You can also solder on an optional LED and current limiting resistor, which is placed on the AVR ISP VCC pin.

Next, take your ProtoProg board with the 6×2 pin header and a blank ProtoProg board and place them in your vise (see photo above). Carefully insert pogo pins into each hole before you completely tighten the vise. This will align the pins before you solder them.

Next, align the pins so that the two outside pins stick out about 3mm past the other pins. These pins will make contact with the alignment holes on the footprint before the rest of the signal pins.

ProtoProg assembly - step 3

Finally, solder each pin to the PCB. Make sure each pin makes a good solder joint with the pads, as these joints form both an electrical and mechanical connection.

ProtoProg Adapter

Finally, attach your programming adapter to your programmer. If your programmer is configured to power your target board, the ProtoProg LED will illuminate. If the target is self-powered, the LED will illuminate when you plug the ProtoProg into your target board.

When programming, carefully press the ProtoProg adapter on your footprint. If you are using the micro connector, make sure the two outer pins “snap” into the alignment vias before fully pressing down the connector.

If you are using the standard connector, make sure the two outer alignment pins go into the outer alignment holes before completely pressing down the connector.

Note: This project was recently renamed, but the PCBs and photos above still bear the old name.

Design Resources

If you have any questions or suggestions, leave a comment below or send a message through our contact page.

]]>
http://protofusion.org/wordpress/2013/05/open-hardware-pogo-pin-programmer/feed/ 9 1613
MNL: Networked LED Lighting http://protofusion.org/wordpress/2011/08/mnl-networked-led-lighting/ http://protofusion.org/wordpress/2011/08/mnl-networked-led-lighting/#comments Mon, 29 Aug 2011 00:13:52 +0000 http://protofusion.org/wordpress/?p=1037 ]]>

MNL is a multi-node high-power RGB lighting system. It consists of a controller (PC or embedded system) and multiple light nodes networked with RS485. The first prototype nodes are up and running, and we will be developing the second revision of prototypes in the coming months. Read on past the break for more information.

Node Hardware

The node board is a small PCB with two RJ-45 ports and a power terminal strip, along with an ICSP header for flashing firmware. The nodes are designed for daisy-chaining both data and power.

Current features:

  • RS485 communication
  • Supports LEDs of up to 1.2A per channel
  • Upgradeable firmware for additional features
  • TBD: Firmware updates over RS485
  • Multiple fade types, dwell modes, etc.
  • Hardware-agnostic network supports different types of nodes (e.g., strobe, motor driver, etc)

LED Circuit

The LED used for prototyping is a 10W RGB LED from DealExtreme, which provides a generous amount of light with low cost per lumen. Although the heatsink is a bit small, forced-air cooling keeps things at a reasonable temperature.  The PCB includes a fan output which is PWMed according to the average instantaneous luminosity of the node. Forced-air cooling could be helpful for installation in compromising environments, such as can lighting fixtures.

The current design incorporates 3 current-limiting resistors for each channel of the LED. Although this is less efficient than current-regulated supplies, it allows flexibility in LED choice without requiring extensive PCB modifications.

Prototype Software

I developed a quick Processing sketch for testing purposes. It creates a FFT of the stereo mix and uses the lowest three bins to determine R/G/B brightness. If the largest of the three values is over the threshold specified by the slider, then an update command is sent to the node. The processing sketch also has an Open Sound Control (OSC) interface, allowing easy control from the TouchOSC app for iPhone or Android over WIFI as well as any software package that supports OSC.

This project is still under heavy development, and is still in the prototype phase. We are adding additional features to the software and hardware, so expect significant updates in the coming months.

]]>
http://protofusion.org/wordpress/2011/08/mnl-networked-led-lighting/feed/ 2 1037
The OSRAM SLG2016 and AVR http://protofusion.org/wordpress/2010/10/the-osram-slg2016-and-avr/ http://protofusion.org/wordpress/2010/10/the-osram-slg2016-and-avr/#comments Sun, 17 Oct 2010 21:33:39 +0000 http://protofusion.org/wordpress/?p=531 ]]>

I happened to scavenge a couple of SLG2016’s from some old workstation debug displays. After finally locating a datasheet, I realized that they used the standard ASCII charset, so they are extremely easy to drive. Note: The SLG2016 differs from the SLR2016, SLO2016, and SLY2016 only by LED color.

The only downside to these displays is that they use quite a few pins (7 data lines, 2 digit select lines, write line, and optional blanking line). For now, I’m driving the display with all pins in parallel on a tiny88 which has plenty of pins; however I plan on using a shift register to cut down on data bus pin usage in the future. The displays only need the data lines to be held stable during a write cycle, making shift registers well-suited to this task.

To flash the attiny88, I’m using a Bus Pirate (pictured above) flashed with the STK500v2 emulation firmware. This allows me to use avr-gcc with AVR Studio to program the chip.

Here is some code I used to test the displays, using PORTD for data lines, and the 2 LSB’s of PORTC for digit select lines. This is the first time I’ve worked with AVRs outside of the Arduino environment, so pardon any flagrant errors and drop me a comment if you have any suggestions.

#define F_CPU 1000000UL

#include <avr/io.h>
#include <util/delay.h>
#include <string.h>
#include <stdlib.h>

void wr();
void wrChar(char toWrite, int dig);
void wrWord(char *word);
void scrollWord(char *word);
void delay_ms(uint16_t ms);

int main (void){
  DDRC=0xFF;
  DDRD=0xFF;
  PORTD=0x00;
  PORTC=0x00;

  // Loop through a few strings for testing
  while(1){
    wrWord("Helo");
    delay_ms(500);
    wrWord("*?%$");
    delay_ms(500);
  }
}

// Toggle write pin (PC0)
void wr() {
  PORTD &= ~(1<<7);
  delay_ms(1);
  PORTD |= (1<<7);
}

// Write char to position
void wrChar(char toWrite, int pos){
  PORTC = pos;  // Set digit select lines
  PORTD = toWrite;  // Set data lines
  wr();  // Toggle write pin
}

// Write 4-char word
void wrWord(char *word){
  for(int i=3; i>=0; i--){
    wrChar(word[i], 3-i);
  }
}

// Generic delay function
void delay_ms(uint16_t ms) {
  while (ms) {
    _delay_ms(1);
    ms--;
  }
}
]]>
http://protofusion.org/wordpress/2010/10/the-osram-slg2016-and-avr/feed/ 2 531