Atmega328p Assembly I2C Transactions

Image

The development environment.  Breadboard, Computer, zeptoprog, saleae logic 8

The first of three tasks to get working for the thermal camera build is of course, to read the sensor.  The other two tasks are writing a display driver, and then combining the two.  Since I am doing it in assembly (because why not?), it is a little trickier than just some C snippets from the datasheet or the arduino wire library.

Anyway, here is a practical breakdown and code snipped for the i2c master peripheral on the atmega328/atmegaXX8 series, in assembly.  The datasheet is nice, but it looks like it is copy pasted from every other atmel chip with this peripheral, which means there are some errors in the code they provide.  Specifically, the IN and OUT instructions on page 219 dont work- they only work on registers 0×00-0x3F, which is a tidbit hidden away on page 625.  The solution is to use STS and LDS.  Atmel provides a nice macro for this that lets you write LOAD and STORE, but the whole point of this project is to write some assembly, so I didn’t use them, as they hide some of the details and are not included by default.

To be an I2C master you need to do two things: put data on the bus, and get data from the bus.  This comes out to four things you might want to do to the bus, which are put, get, start, and stop the bus.  You also need to configure the master clock speed.  There are four important addresses for a master- TWBR, TWCR, TWSR, and TWDR.  TWAR and TWAMR are for slave devices, so we wont worry about them.  The below code is based on this hardcoded example, but has been cleaned up into more flexible and portable subroutines.

Setup the Bitrate

The registers to pay attention to in setup is the TWBR, which is the Two Wire Bit Rate register, and TWSR, the Two Wire Status Register.  The last two bits of TWSR set the clock prescaler, and the entire TWBR is used to calculate the I2C clock frequency:

SCL Hz= Clock/(16+2*prescaler*TWBR)

You should refer to the datasheet for more information about TWBR and TWSR if you are trying to implement this.  My clock speed is 8MHz since I set the CLKDIV fuse to 0 and I am running off the internal RC oscillator.  This means the highest selectable speed is 500kHz.  The chip I want to read from is only rated to 400kHz, although I tested and it works at 800kHz.  As you can see in the code below, I ended up choosing the 400kHz speed, although I may increase it later.  Here is the assembly snippet for setting the TWBR/TWSR.  Since TWSR is read only for the top 6 bytes, it is pretty safe to write the whole thing to 0 in the beginning.  It would also be ok to comment out the last two lines since the default TWSR is 0bXXXXXX00.

ldi     r16, 2
sts    TWBR, r16

ldi    temp, 0×00
sts    TWSR , temp

There you go, that’s how you set it up.  Now lets look at some the subroutines that start, stop, put and get.  The code is broken up below, but uninterrupted copies of the subroutines are pasted at the bottom of the document in case you want them.

START

I2CSTART:
ldi         temp, (1<<TWINT)|(1<<TWSTA)|(1<<TWEN)
sts             TWCR,temp

This is the beginning of the subroutine.  First, the data register (which we assume holds the R/W address of the slave) is sent to the Two Wire Data Register (TWDR).  Then, it sets TWINT, TWSTA, and TWEN.  Writing TWINT clears the TWI interrupt flag, which is a little misleading- it doesen’t generate in interrupt unless you have the correct bit masked in TWCR (TWIE, TW interrupt enable).  The other purpose is to let you know that the bus is done doing its stuff, and it is time to check on it.  Writing TWSTA tells the peripheral that it is time to send a start, and TWEN enables the module.

WAIT_START:
lds         temp,TWCR
sbrs         temp,TWINT
rjmp         WAIT_START

Now that we have the start condition in progress, we just check the TWINT flag to see if it is set.  Once it is set, it means that the the start condition is sent, or more generally that the bus is waiting on the controller for some kind of next move.

lds          temp,TWSR
andi        temp,0b11111000
cpi          temp,0×08
breq       PC+2
jmp         errloop
ret

Eventually, TWINT is set and we move on in the code.  We and the value in Two Wire Status Register (TWSR) with 0b11111000 to mask the last three bits, which are the clock prescaler bits and a reserve bit.  This stores the bus status in TWSR- we want it to be 0×08, which means “start condition” on the bus.  It could be something else, which would be an error- in the debug code it goes to errloop, which is just a do-nothing loop.  If it is 0×08, it skips over the jump to the error loop and returns.

STOP

I2CSTOP:
ldi         temp,(1<<TWINT)|(1<<TWSTO)|(1<<TWEN)
sts            TWCR,temp

Much like a car, an I2C transmission needs to be able to stop just as well as it can start.  This snippet should look familiar- it is the same as the start instruction, only instead of 1<<TWSTA it has 1<<TWSTO, which tells the module to send a stop condition.

Check1:
lds            temp,TWCR
andi        temp,0b00010000        ; Check to see that no transmission is going on
brne        Check1
ret

Just like before, we want to wait and check to make sure the command is on the bus before returning to the main code.  Here we check TWCR to see if the right condition is on the bus- this bit in TWCR is the stop condition, which we just wrote.  If that checks out, it returns.

PUT

ldi       r17, your_value

This function assumes the value you want to put on the I2C bus is in r17.  That just means you call this line before calling the put function.

I2CPUT:
NEXT1:
ldi         r16, (0<<TWINT) | (1<<TWEN)
sts        TWCR, r16
sts        TWDR, r17
ldi         r16     , (1<<TWINT) | (1<<TWEN)
sts        TWCR, r16

This should start to look familiar.  Here we turn off the TW peripheral (or kind of pause it with 0<<TWINT).  Then we load r17 into TWDR- this is the thing that gets pushed out of the micro to the slave.  After that is loaded up, we start the peripheral again by writing 1 to TWINT.

WAIT_ACK:
lds           r16 ,TWCR
sbrs         r16 ,TWINT
rjmp         WAIT_ACK
ret

Now we just check TWCR until TWINT is set (which is how the peripheral lets you know you are done) and then return to the program.  If we were fancy, we could also check TWSR to make sure we have the right status.

GET

GET works a lot like put, only the result ends up in the register r17 once it is done.

I2CGETACK:
ldi              r16, (1<<TWINT) | (1<<TWEN) | (1<<TWEA)
sts             TWCR, r16
rjmp I2CGET

Again, are setting TWINT and TWEN, but what is that (1<<TWEA)?  I am glad you asked!  TWEA sends an ack if it is set to 1, or an NACK if it was set to 0.  So if you want an ack, call I2CGETACK, otherwise call the next label:

I2CGETNACK:
ldi              r16 ,(1<<TWINT) | (1<<TWEN)
sts             TWCR, r16

This does exactly what it says on the tin- it gets a byte from the i2c bus and then NAKs.

WAIT_FOR_BYTE:
lds         r16, TWCR
sbrs       r16 ,TWINT
rjmp        WAIT_FOR_BYTE

This snippet waits for the TWCR to tell us it is done, by checking TWINT
lds         r17,TWDR
ret

Then the TWDR is loaded into the data register (r17) to be used in the program later, and the subroutine returns

Reading the AMG8852

 

So to read both the high and low bytes of the AMG8852, the steps you want to take are:

call I2CSTART ;send a start
ldi data,0xD0   ;load the write address into data
call I2CPUT     ;put the data (the slave write address) on the line
ldi data,0×80   ;load the address of the register you want to read in to data
call I2CPUT     ;set the address you want to read on the amg
call I2CSTOP  ;send a stop

Now the grid-eye knows that you want to read address 0×80 (the beginning of the pixels).

call I2CSTART        ;send a start condition
ldi data,0xD1          ;write the slave read address to data
call I2CPUT            ;write the slave read address to the bus
call I2CGETACK    ;get a byte and send an ACK
call I2CGETNACK ;get a byte and send a NACK
call I2CSTOP        ;send a stop condition

Now, after I2CGETACK and I2CGETNACK we can store the data somewhere, but that has not been implemented yet.

Code Paste

After this is a paste of the code.  The commented out sections are additional (not implemented) that catch errors on the i2c bus lines.  some the .equ s are from the reference code from here.  Additionally, there is no error catching right now- if it errors out the code goes straight to the error loop.

/*
* AssemblerApplication5.asm
*
*  Created: 4/21/2014 1:00:03 AM
*   Author: alouie
*/
.device atmega328p
.nolist
.include “C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR Assembler\Native\2.1.39.232\avrassembler\include\m328Pdef.inc”
.include “C:\Users\alouie\Desktop\macros.inc”
.list
; ISR table

.org $0000
rjmp Reset
;—————————————————————–
; DEFINES
;—————————————————————–

.def        temp =r16            ;worker register
.def        data =r17

; Equate statements
.equ        start        = $08        ; Start Condition
.equ        Rep_start    = $10        ; Repeated Start Condition Message
.equ        MT_SLA_ACK    = $18        ; Master Transmitter Slave Address Acknowledge
.equ        MT_DATA_ACK = $28        ; Master Transmitter Data Acknowledge
.equ        MT_DATA_NACK= $30        ; Master Transmitter Data Not Acknowledge
.equ        MR_SLA_ACK    = $40        ; Master Receiver Slave Address Acknowledge
.equ        MR_SLA_NACK    = $48        ; Master Receiver Slave Address Acknowledge
.equ        MR_DATA_ACK = $50        ; Master Receiver Data Acknowlede
.equ        MR_DATA_NACK= $58        ; Master Receiver Data Not Acknowledge
.equ        W            = 0            ; Write Bit
.equ        R            = 1            ; Read Bit
.equ        SLA            = $D0        ; Slave Address of AMG8852
.equ        Inches        = $50        ; Return result in Inches
.equ        CommandReg    = $80        ; SRF08 Command Register
;—————————————————————–
; Reset
;—————————————————————–

Reset:
;—–Setting Stackpointer—————————————-
ldi        temp,low(RAMEND)            ; Set stackptr to ram end
out        SPL,temp
ldi     temp, high(RAMEND)
out     SPH, temp

;—————————————————————–
;setup DDR/IO
;—————————————————————–
;set pullups, DDRC output
ldi temp, 0xff
out DDRC,temp
out    PORTC,temp

;—————————————————————–
;setup speed etc. of i2c port
;—————————————————————–
;400Khz=8MHz/(16+2*TWBR*CLKPRS) TWBR and clock presecaler set
;i2c freq.  clock prescaler default is 1, and is set in
;TWSR
ldi    temp,2
sts    TWBR,temp

ldi    temp,0×00
sts    TWSR,temp

rjmp I2CLOOP

I2CLOOP:
call I2CSTART
ldi data,0xD0
call I2CPUT
ldi data,0×80
call I2CPUT
call I2CSTOP

call I2CSTART
ldi data,0xD1
call I2CPUT
call I2CGETACK
call I2CGETNACK
call I2CSTOP
;take a little nop
;good for debugging
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
rjmp I2CLOOP

;—————-SEND I2C START—————————————————————–
;—————-This will send a DATA out as the address—————————————
;—————-sends start condition and address———————————————-
I2CSTART:
ldi         temp, (1<<TWINT)|(1<<TWSTA)|(1<<TWEN)
sts             TWCR,temp

;wait for start condition to be sent.  when TWINT in TWCR is cleared, it is sent
WAIT_START:
lds         temp,TWCR
sbrs         temp,TWINT
rjmp         WAIT_START

;check TWSR for bus status.
;andi masks last three bits, which are 2=? 1:0prescaler value
lds         temp,TWSR
andi        temp,0b11111000
cpi         temp,START
breq        PC+2
jmp            errloop
ret

;————–PUT I2C————————————————————————–
;————–bytes is stored in r17 aka data————————————————–
;use this by putting the address or data to put on the i2c line in data (r17)
;then this function will disable the TW int, write data to TWDR, and wait for an ack
I2CPUT:
NEXT1:
ldi         temp,(0<<TWINT) | (1<<TWEN)
sts             TWCR,temp
;ldi         temp,SLA+W
sts             TWDR,data
ldi         temp,(1<<TWINT) | (1<<TWEN)
sts             TWCR,temp

;another wait for the TWINT flag, which lets us know if ACK/NACK is back (received
;but I couldnt help myself with that rhyme)
WAIT_DONE:
lds         temp,TWCR
sbrs         temp,TWINT
rjmp         WAIT_DONE

;check and see if TWSR is ACK, or not.  if it is, keep going
;lds         temp,TWSR
;andi        temp,0b11111000
;cpi         temp,MT_SLA_ACK
;breq        SEND_REG
;jmp            errloop
ret

;—————-GET I2C ———————————————————————
;—————-received data is stored in r17 aka data————————————–
;
I2CGETACK:
;enable TWCR, then wait for TWINT
ldi            temp,(1<<TWINT) | (1<<TWEN) | (1<<TWEA)
sts             TWCR,temp
rjmp I2CGET

I2CGETNACK:
ldi            temp,(1<<TWINT) | (1<<TWEN)
sts             TWCR,temp

I2CGET:
WAIT_FOR_BYTE:
lds         temp,TWCR
sbrs         temp,TWINT
rjmp         WAIT_FOR_BYTE

lds         data,TWDR

;check and see if TWSR is ACK, or not.  if it is, keep going
;lds         temp,TWSR
;andi        temp,0b11111000
;cpi         temp,MT_SLA_ACK
;breq        SEND_REG
;jmp            errloop

ret

;—————-SEND I2C STop—————————————————————–
I2CSTOP:
ldi         temp,(1<<TWINT)|(1<<TWSTO)|(1<<TWEN)
sts            TWCR,temp

;check TWCR to see if there is still a transmission- if not, stop bit has been sent
Check1:
lds            temp,TWCR
andi        temp,0b00010000        ; Check to see that no transmission is going on
brne        Check1
ret

;error hell
errloop:
rjmp errloop

Therma Camera Project

The GRID-EYE.  What a name!

The GRID-EYE. What a name!

A few months ago, I bought an AMG8852 “Grid-eye” sensor from digikey.  It is an 8×8 thermopile array, which is one way of saying it is a low resolution thermal camera, which is totally worthy if its terrifying and vaguely sci-fi name.   I soldered it down to a breakout board from osh park, tested it with some arduino code (provided at that link), and then threw it in a parts pile for a while.  I knew its future would be as the input to an 8×8 LED array, but I didn’t have time to work on it back then, so it hid in my logic analyzer case for a while.  This weekend I pulled it out to work on.

The grid-eye datasheet on digikey is pretty garbage, but there are some good resources online that actually describe what all registers are and what bytes are r, w, r/w.  Turns out most of the settings are already what I want them to be, but knowing that is better than leaving it up to chance.

I decided that this project would be done in assembly, since I haven’t used it in a while.  The first task was to choose a development environment.  The last time I wrote pure assembly was a while ago, and I wanted to see what was out there.  I tried avr-as, avra, and atmel studio 6 (in windows).  Atmel studio 6 won out since it has all the up-to-date XXXXXdec.inc files, and it has a nice interface for setting and checking fuses.

I chose an atmega328p as my controller since I have about 10 of them rolling around in my bag-o-microcontrollers, and they are extremely common.  I didn’t want a repeat of when I ordered attiny20s only to find that they could barely be programmed in assembly (not supported by avr-gcc).  One of my other options was an attiny 25/45/85, but they don’t have real I2C peripherals (UART instead) and don’t have much in the way of pins, so they got passed over.  I could have also used an atxmega32a4u or an atmega32u4, but that seemed like overkill.

Here are a few sketches of enclosures or usage ideas.  There are two main ideas here- a lipstick/lytro shaped camera, and a “twin lens reflex” camera.

Lipstick/Lytro design

Lipstick/Lytro design

This design is supposed to be small and easy to stuff in a bag or toolbox and to be easy to hold in one hand.  The use case here is producing a “live” thermal image, that you can use to find hot/cold spots in a project or space.  The case could be striped black/orange/black to give it a cool color scheme.  The case prototype would be 3d printed.

Twin lens reflex idea.  Thermal camera data superimposed on small jpeg

Twin lens reflex idea

A TLR is an old kind of camera that had one lens for viewing the image, and one lens for capturing the image.  In this case, the thermal image would be the one you would use to sight the camera, and in addition to the thermal camera there would be a static serial camera on board.  This could have some cool applications in sensing wildlife or people as they approach the camera.  The saved image would include the thermal profile tacked on, so you could do a temperature overlay of the final image.

TLR idea detail.

TLR idea detail.

This is another image of the camera body.  I am excited by this idea, but it is more complicated than the simpler thermal imager.  The simple version could be a stepping stone to the more exciting version.

Scrolling LED Display

They look pretty good...

They look pretty good…

I am working on a project for someone, which I was encouraged to post here.  The goal is to explore making big led panel displays available as a module for new wireless development platform (the tessel).  As part of my assignment, I need to asses the viability and quality of several LED panels.  I will be starting with the LDP-6416 from Embedded Adventures.

The display is 64 lines “long” and 16 lines “high”.  Only one row of 64 LEDs can be on a time- this means to create a persistent display, the rows need to be enabled over and over very quickly.  Additionally, the LED display is relatively “dumb”, and the line needs to be shifted in each time before it is displayed.  This means that you put some data on the R1 and G1 pins, then you pulse a pin to put that data into the LED driver register.  The reasons behind this are covered in the electronics tear-down below.

The result is that the person developing on the board needs to be protected from having to devote a lot of resources to flash the board over and over, because that would take a lot of memory.  Also, there needs to be some way of scrolling the display, since that is a pretty common task that should not require the image to be shifted on the main processor, then retransmitted to the panel module and re-displayed over and over again.  My goal was to evaluate if functions like scroll_text(‘ASDF’); and static_text(‘ASDF’) would look good and be easy to implement.

It turns out to be pretty easy to scroll text if you store your data thoughtfully.  My experience with the code is below, followed by an electronics teardown of the module, and a short second on reducing ghosting and flickering.  At the very bottom are a few caveats and suggestions if you want to use the code.  If you want to run it, check the caveats.  the code is available on github, as well as being pasted below.

CODE

There were three main revisions of the code, which got faster and faster.  The speed had to increase to reduce flicker due to refreshing of lines.  The takeaways are: use the right type of variable, and put pins you want to change at the same time on the same PORT.

The metrics for “goodness” of the code were how much program storage and dynamic storage it took up, and how much the display flickered.  The dominant function in terms of time-usage is the function that loads the image into the row, so that is what is scrutinized in these attempts.  The code was compiled with the -O3 (optimize for speed) optimization command passed to the compiler, so some of the code blowup in the first two functions may be because of in-line arguments etc.  Also, only the data for the image and the data for the data driving were compiled- no extra loops or functions.

The latest code is available on github, complete with comments

Naive Attempt: 1484 byte program memory, 521 byte dynamic memory, flickery

Each byte contains four pixels

Each byte contains four pixels

My normal approach is to try the easiest way to do something first- just to check things out, and to make sure things are hooked up right.  Sometimes it even works well enough to use as a prototype.  In this case it would have worked if the arduino were about twice as fast, but it was still a good way to start seeing how the panel worked.

The “image” data was stored as an “int image[16][16]={{0xff,0×55..},…}”.  Each alternating bit was a green, then red value for a pixel.  This turns out to be a stupid way to store the image, but it does work.  The issues with this image storage are that ints are 16-bit in this implementation, and I only used up to 8 bits of them.  byte image[16][16] is the way to go if you want to store 8 bit values.

The code was also pretty bad.  The wiring was such that the pins that were clocking the signal out to the LEDs were on different PORTs.  Here is the function:

void noob_line(int line){

for(int k=0; k<16; k++)
{
for(int j=3; j>=0; j–)
{
digitalWrite(0,bmp[line][k]&(0b1<<j*2)>>j*2);
digitalWrite(1,bmp[line][k]&(0b10<<j*2)>>j*2);
digitalWrite(2,LOW);
digitalWrite(2,HIGH);
}
}

digitalWrite(13,HIGH);
digitalWrite(13,LOW);
}

On the surface this doesn’t seem too bad- it is basically just doing two writes, clocking in the data, and then latching it at the end.  The thing that kills this function and causes the flicker is actually digialWrite.  It seems innocent enough, but digitalWrite actually takes quite a bit of time.  One guy clocked it at 4.75us, which is around 40 instructions.  Round that up to 5us, see that there are 4 calls, and the loop runs 64 times, and you will notice that it is 1.3 miliseconds!  That means the whole screen is only updating 50 times a second.  With no fine grain or motion blur, like a movie has, this is pretty apparent.  That doesn’t take into account the logic operations and retrieving the data form the image, but its not a good number to start with.

Proof Attempt: 1120 byte program memory, 265 byte dynamic memory, no flicker

flckr-less.  Showing off some of the colors with a silly test pattern

flckr-less. Showing off some of the colors with a silly test pattern

At this point, I just wanted to make sure that the display would work without flicker.  This one went way faster and used much less program memory to store the image, since the type was set to byte instead of int.  I could have used half as many ints instead, and taken the same amount of memory, but there is something appealing and fast about using 8 bit numbers on an 8 bit micro.

This loop went a lot faster because I wrote directly to the PORT, and I put all the pins on the same PORT.  I didn’t clock the function since it was not flickering, but an easy check would be to use an oscilloscope on the latch line.

Here is the code:

void send_line(byte line){

for(int k=0; k<16; k++)
{
{
for(int j=3; j>=0; j–)
{
PORTD =0b11111000 | ((bmp[line][k] & (0b11<<j*2))>>j*2); //access some memory
PORTD|=0b00000100;
}
}

}
digitalWrite(13,HIGH);
digitalWrite(13,LOW);
}

As you can see, the four digital writes have been replaced.  The nice thing is the boolean functions are all acting on 8 bit registers, so each one should take about one operation.  Thee are five of them, which even with 200% overhead for getting variables from memory only takes 63 microseconds.  The estimated time for the function to run is then 40 microseconds, or about the amount of time it takes to run 10 digitalWrites.  If I wanted to go faster, I could even use a PORT write instead of digitalWrite to latch the data.

Anyway, this was MUCH faster.  But still, there was no good way to scroll the data.  The obvious approach to scrolling is not to rewrite the entire image, but just to shift it over.  However, since the data was stored in bytes, there was not an easy way to index a shift of one pixel, because of the inner loop always runs four times.  Since the data was indexed by bytes that coded for four pixels, it was easy to scroll by four, but not by one, two, or three pixels.

Wise Shift: 740 bytes program memory, 137 bytes dynamic memory, no flicker

now each bit of a 64 bit row is addressable individually

now each bit of a 64 bit row is addressable individually

I called this function wise_line since the data structure used to store the image was wiser.  To be efficient, I packed the data into bytes just like before, but to be wiser, I made the two matrices of [64][2] instead of [16][16].  This means that imj[0,1,2...63][0] gives you the top 8 pixels rows, and imj[0,1,2...63][1] gives you the bottom 8. Now if i want a 64-pixel long row, I can just ask for imj[0...64][0] and mask it with the correct row.

Same amount of data, but much easier to deal with!  Now I can iterate down a column and start and stop at any point.  This makes scrolling easy!

void wise_line(byte line,byte shift)
{
for(byte i=shift; i<64; i++) //print everything from shift onwards
{
PORTD =0b11111010 | ((img[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111));
PORTD|=0b00000100;
}
for(byte i=0; i<shift; i++) //print the rest of the picture
{
PORTD =0b11111010 | ((img[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111));
PORTD|=0b00000100;
}
PORTB|=0b00010000;
PORTB&=0b11101111;
}

Now to scroll, all I have to do is print  img[shift,shift+1...63][n], then print img[0,1...shift][n]. I decided that byte line would hold all of the data for what line you to print, specifically:

byte:  | 7: upper/lower display | 6-3 empty | 2-0 column mask |

so line>>7 tells you if you want image[n][1] or image[n][0], and line&0b111 tells you what part of the byte is the correct row.  The nice thing is that to display a given row of pixels, you don’t have to change any index except how far down the row you are- the top/bottom and mask information is the same.

The result is that scrolling and other effects involving shifting images are easy, and the code is much, much smaller and faster.  Over the three iterations, the program memory only dropped by about 50%, and the dynamic memory dropped by about 75%.  The main memory gains were made by using bytes instead of ints, which are half as big, and replacing slow arduino function calls with faster PORT writes and a little bit-math.

ELECTRICAL

Wires.  Everywhere.

Wires. Everywhere.

The panel itself is pretty easy to hook up and use.  Power is needed in abundance to drive the panel, but it only needs one line lit at a time, and that line can be PWMed on the ~enable pin to reduce average current draw.  Fully lit, the datasheet says it will draw 4A a row, so a 5V 5A power supply seems like it would do the trick with a spare amp- a tiny portion of which could be used to power a microcontroller.

There are 10 connections that are important, but 16 pins in the header, so it is not nearly as bad as it seems at first.  Since it is a test setup, I just jammed some male-male headers into the connector.  The important lines are:

  • ground
  • ~enable
  • latch
  • shift
  • ~Green data
  • ~Red data
  • A, the first bit of the row selector
  • B, the second bit of the row selector
  • C, the third bit of the row selector
  • D, the fourth bit of the row selector

The arduino pin numbering for these pins is provided in the code on github. and copied at the bottom of the document.

The backside of the board.

The backside of the board.

The chips on the board are the usual suspects- lots of 74 series logic, and some FETs.

There are 8 FDS4953 FET packages, on the board, each containing two transistors.  There are two SM74HC138D decoder/demultiplexers, and 16 74hc595 shift registers.  The LED panels look like the typical sort which can only actually have one row on at a time anyway.

With 8 FET packages at two FETs per package, you can imagine pretty much exactly what is going on.  Each FET powers a row of LEDS.  Using a continuity tester reveals that the top and bottom decoders are connected to the ABCD row select pins on the control header, so those pins get demultiplexed and used to turn on the FETs, which are each connected to a row pin on each of the LED panels.  So the flow looks like this:

ABCD pins–>74HC138D–>FDS4953–> all of the H# pins on the top panel

The H# (where # can be 1-8) turn on one row of each of the panels on one side of the board.

So that is power.  The logic is pretty simple as well, since it is just a bunch of chained shift registers.  One chain of 8 registers controls each color, and turns on all the pixels in a column.  The FET then selects the row, and the two output a single line.

And there you have it- a big, cheap LED driver board.  The last interesting thing here is that it was not designed by Embedded Electronics- I think I was shipped an old rev. of the board, because it lacks the screw terminals, chip position, and silk of the picture on their website.  This board is copyrighted 2013 by linsn, which looks like an LED panel supplier.

Increasing Brightness, Reducing Flicker and Ghosting

Ghosting is noticeable between rows here in this picutre.  *(cylon noises)*

Ghosting is noticeable between rows here in this picutre. *(cylon noises)*

Flicker is caused by going too slow, and Ghosting is caused by having the enable on before the data is shifted in.  In my first, slow attempts I had a line like:

analogWrite(EN,1); //keep EN low most of the time, flash it at ~500hz

This made the display ghost, because the LEDS would light up as the data was propagated across the registers.  It would also cause flickering because the code was slow.  One way to mitigate flickering if your code is too slow is to display lines in a random fashion- it can be the same pattern every time, but if you refresh lines next to one another it can cause a traveling wave pattern of flickering if the code is not running smoothly.  This goes for anything that has a consistent direction, including refreshes from the outside in or inside out.

Once the code was much faster, I would manually enable/disable EN after the line was written.  This causes a dim display because the code loops back around and pushes the next line immediately, like so:

void loop() {
disable_display();
push_line();
enable_display();
}

Inevitably, it would spend most of the time doing the push_line() command, and during that time the display was off.  The fix to this is to write:

void loop() {
disable_display();
push_line();
enable_display();
delayMicroseconds(a_few_us);
}

to allow the panel to shine.  This value can be tweaked up to the point where you start to see flickering, and it will make the display brighter.

Caveats and Suggestions for Implementation:

So you want to scroll some pixels.  The only bugs right now are a tiny pause when the shift value is reset, but this could be fixed with some clever use of binary math.  It is only noticeable if the scrolling is fast.

This code was written at max speed- therefore some lines are somewhat obfuscated.  They have been commented to try to de-obfuscate them, but I admit they could still be confusing.

You may need to change the delay value, discussed above.

There is also a pretty big problem in loading the data, since you have to generate the map by hand at the moment.  you could write some python that pushes it to the arduino, or a gui for generating maps.

Lastly, the scrolling function is pretty boss.  You could change the code to have a longer img matrix, like a [128][2] and have a longer scrolling message, or you could save sprites and make an animation…there is a lot of room left on the arduino!

CODE PASTE!

/*
LED driver software for LDP-6416
Written by Avery Louie for Ryan Hurst
*/

//defines used on old versions of code, still useful for wiring reference
//all these pins live on PORT D, D0-3
#define RD  0
#define GR  1
#define  S  2
#define EN  3

//all these pins live on PORT B
#define  A  8
#define  B  9
#define  C 10
#define  D 11

#define  L 13

//the “image” for the static test using send_line and noob_line
byte bmp[16][16]={

{0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0×55,0×55,0×55,0×55,0×55,0×55,0×55,0×55},
{0×55,0×55,0×55,0×55,0×55,0×55,0×55,0×55,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA},
{0×00,0xff,0×55,0xAA,0×00,0×10,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0×01,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×10,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×01,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0xFF,0×00,0xFF,0×40,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×50,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×70,0×50,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×80,0×00,0×00,0×00,0×00,0×00,0×00,0×00},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×90,0×00,0×00,0×00,0×00,0×00,0×00,0×01},
{0×00,0xff,0×55,0xAA,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00},

};

//the “image” for the wise_line function.  Can even scroll!
byte img_G[64][2]={
{0xAA,0xFF},
{0xAA,0xFF},
{0xAA,0xF1},
{0xAA,0×55},
{0xFF,0×55},
{0xFF,0×55},
{0xFF,0xFF},
{0xFF,0xFF},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xFF,0xFF},
{0xFF,0xFF},
{0×00,0×08},
{0×00,0×00},
{0xFF,0xFF},
{0xFF,0xFF},
{0xAA,0×55},
{0xAA,0×55},
{0×55,0×55},
{0×00,0×55},
{0×01,0×55},
{0×03,0×55},
{0×07,0×55},
{0x0F,0×55},
{0x3F,0×55},
{0x6F,0×55},
{0x7F,0×55},
{0xFF,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0xfe}
};

byte img_R[64][2]={
{0×07,0×55},
{0x0F,0×55},
{0x3F,0×55},
{0x6F,0×55},
{0x7F,0×55},
{0xFF,0×55},
{0xAA,0×55},
{0xAA,0xFF},
{0xAA,0xFF},
{0xAA,0xF1},
{0xAA,0×55},
{0xFF,0×55},
{0xFF,0×55},
{0xFF,0xFF},
{0xFF,0xFF},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xFF,0xFF},
{0xFF,0xFF},
{0×00,0×08},
{0×00,0×00},
{0xFF,0xFF},
{0xFF,0xFF},
{0xAA,0×55},
{0xAA,0×55},
{0×55,0×55},
{0×00,0×55},
{0×01,0×55},
{0×03,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×55},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0×50},
{0xAA,0xfe}
};

void setup(){
//setup all pins interfacing with the panel to be outputs
pinMode(EN, OUTPUT);
pinMode(RD, OUTPUT);
pinMode(GR, OUTPUT);
pinMode(A,  OUTPUT);
pinMode(B,  OUTPUT);
pinMode(C,  OUTPUT);
pinMode(D,  OUTPUT);
pinMode(L,  OUTPUT);
pinMode(S,  OUTPUT);

//default state of S is high
digitalWrite(S,HIGH);
}

void loop(){

//lin, leaf, ud and rd are different refresh patterns.  Try them out!
int leaf[16]={0,2,1,3,5,4,6,8,7,9,11,10,12,14,13,15};
int ud[16]  ={0,15,1,14,2,13,3,12,4,11,5,10,6,9,7,8};
int rd[16]  ={3,1,6,13,7,14,4,10,5,11,0,12,2,8,15,9};
int lin[16] ={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};

//top    0×87, 0×86, 0×85, 0×84, 0×83, 0×82, 0×81, 0×80
//bottom 0×00, 0×01, 0×02, 0×03, 0×04, 0×05, 0×06, 0×07
byte xd[16] = {0×87, 0×86, 0×85, 0×84, 0×83, 0×82, 0×81, 0×80, 0×00, 0×01, 0×02, 0×03, 0×04, 0×05, 0×06, 0×07};

unsigned long oldtime=millis();
byte shift=0;

//uncomment this part if you want to see noob_line run
/*
analogWrite(EN,1);
while(1){
for(int i=0 ; i<16 ; i++)
{
noob_line(rd[i]);
PORTB=rd[i];
}
}
*/

//uncomment this part to see send_line run
/*
analogWrite(EN,1);
while(1){
for(int i=0 ; i<16 ; i++)
{
send_line(rd[i]);
PORTB=rd[i];
}
}
*/

//comment this and uncomment the other functions to change to the other functions.  Use this to see scrolling images.

while(1){
if(millis()-oldtime>70)  //change the value of millis()-oldtime>70 to something other than 70 to make the scroll faster or slower
{
oldtime=millis();
shift++;
if (shift>64){      //images are 64 bits long, so if you get to the end of an image you need to reset the shift amount to 0. playing with how this works, you could do bouncing images etc.
shift=0;
}
}

for(int i=0; i<16; i++)
{
PORTD|=0b00001000;        //toggle en low
wise_line(xd[i],shift);   //to change it to no scroll, replace shift with 0
PORTD&=0b11110111;        //toggle en high
PORTB=i;
delayMicroseconds(500);     //light the leds for 500us before drawing the next line.  longer can make it brighter, but adds flicker
}

}

}

/*
The smart way to do things.
*/
void wise_line(byte line,byte shift)
{
for(int i=shift; i<64; i++) //starting at the shift value, print the image
{
//set portD to be the data you want to clock in
//lets break this down
//img_G[i][line>>7] gets an 8-bit value from the green image.  the first bit of line tells you if it is from the top or the bottom
//this value is masked with whatever part of the line we want.  for example, if line is 0b100000011, we want the 3rd line.  to get this mask just shift 1<<3
//so img_G[i][line>>7]&(0b1<<(line&0b111) masks the 8-bit value with the actual line we want
//Once we have that, we need to shift down to the bottom of the byte
//finally, for green only, we shift it up one, since the last two bytes of portd are 0bGR, where G is the green bit and R is the red bit
PORTD =0b11111000 | (((img_G[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111))<<1) | ((img_R[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111));
PORTD|=0b00000100;//clock in the actual data by raising the S line.
}
for(int i=0; i<shift; i++)
{
PORTD =0b11111000 | (((img_G[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111))<<1) | ((img_R[i][line>>7]&(0b1<<(line&0b111)))>>(line&0b111));
PORTD|=0b00000100;
}
digitalWrite(L,HIGH);
digitalWrite(L,LOW);
}

void noob_line(int line){

for(int k=0; k<16; k++)
{
for(int j=3; j>=0; j–)
{
/*here is some more bit-mathgic.  not very pretty but this function takes the nth bit of the map on a line
then it masks it to get the two bits you want, and shifts those down to the right position to write them to the pin
*/
digitalWrite(RD,bmp[line][k]&(0b1<<j*2)>>j*2);
digitalWrite(GR,bmp[line][k]&(0b10<<j*2)>>j*2);
digitalWrite(S,LOW);
digitalWrite(S,HIGH);
}
}

digitalWrite(L,HIGH);
digitalWrite(L,LOW);
}

void send_line(byte line){

for(int k=0; k<16; k++)
{
{
for(int j=3; j>=0; j–)
{
//similar to noob_line, only it masks for two bits at the same time, not one
PORTD =0b11111000 | ((bmp[line][k] & (0b11<<j*2))>>j*2);
PORTD|=0b00000100;
}
}

}
digitalWrite(L,HIGH);
digitalWrite(L,LOW);
}

GELIS Redesign: Dirty Power Supply Part II

The test-desk.  Power supply hooked up to an old gel tray with TBE in it.

The test-desk. Power supply hooked up to an old gel tray with TBE in it.

I did some testing on the boost converter today.  My naive methodology to learn what to expect was to first RTFM on the IOR site, then read the links they provided in their documentation on boost/buck converters.  Some links I found handy on that page/that I found were:

*this design uses almost exclusively (expensive looking) SMD components, so it is a good reference

Once I read those documents and took a look at the BOM, it looked like I would be able to figure out SMD replacements for most of the components.  This is good, in case I want to make 10-20 of these, since they can be batched in an oven, or even by a PCB assembler instead of done one lead at a time by hand.  The next task, since I have the parts, was to build the power supply with as few parts as possible.  A gel power supply does not need to have low ripple, or be particularly “clean”.  This means that a lot of the decoupling caps, and associated assembly cost, can be left out.

I eventually settled on adding in all of the capacitors except the input capacitors, C2, C3, and C4.  This didn’t work very well, as I suspect it tripped the over-current protection on my 12 V 10A input from a computer power supply.  Unfortunately, I don’t have a very good scope in my room for testing this- I am using a xprotolab on the feedback pins (FB on the max1771) to take my fast measurements, and a ‘harbor fright’ multimeter for my slow higher-voltage readings.  With no input capacitors I could reach about 40V, which is about half way.  Adding in C4 allowed me to easily reach 100 V.

The next step is just to get equivalent SMD parts where I can.  Some things like the MAX1771 chip are cheaper in DIP-8 than SOIC-8, so it might be worth looking into re-flowing DIPs, but I would want to make sure that that did not also impact pick-and-place-ability.  I could look at other controller chips, or simpler types of control, but I really want to get this out fast, and with as few iterations as I can manage- after all, each iteration is a pretty big cost on my end, which reduces the other cool things I can spend time and money on to revamp the gel box.

GELIS Redesign: Dirty Gel Power Supply

New vs Old GelIS sketches

New vs Old GelIS sketches

I am proud of the Gelis system, but it has some flaws caused by the major dimensions of the box being driven by the need to accommodate the off the shelf power supply.  This causes material wastage in the mostly empty back half of the box, and forces me to use screw-terminal connections in the box for wiring.  This is kind of awesome in that you can wire it all without a soldering iron, but kind of a pain in that it requires wires being routed from four faces of the box.  Some redesign options I considered were:

  • using a terminal strip to simplify wiring instead of binding posts
  • move meter/control buttons to back of box
  • use off the shelf capacitive sensors+transistors instead of switches
  • re-evaluate multi-enclosure design
  • Build custom power supply

The last option has been something I have been avoiding, because it would be capital and time intensive- I don’t have tons of experience with power electronics.  However, an Eames quote comes to mind “Never delegate understanding”.  In this case, I had delegated the power supply design to whoever had a cheap boost converter.  Whoever designed it had different goals- probably to provide way more power than my tiny gel needs, hence the enormous heat sinks.  So I decided that it was time to take on the burden of understanding the power supply.  This freedom gives me some room to make some key design decisions:

  • I can choose a knob to control voltage
  • I can choose a better way to control the LEDs
  • I can choose a better way to connect to the LEDs
  • I can choose a better power jack

These modifications will make assembly easier with regards to wiring the LEDs, which is currently a pain.  The disadvantages will be that I need to spec out each individual part, make a board, and then possibly find somebody to assemble the boards.

To get started, I ordered the parts for the iorodeo gel power supply.  Their supply works, has amazing documentation, and has few enough parts for my tiny mechanical engineer brain to handle.  My goal in building this supply is to figure out what is absolutely necessary for it to function in terms of which capacitors and parts are totally necessary, then convert it to an SMD design.  IOR very explicitly wanted this to be all through hole- for ease of assembly by everyday people.  However, SMD assembly is cheaper, and certainly faster to do in large quantities provided you have a stencil and a reflow oven.

Olympus XA Teardown and Rebuild

The Olympus XA with several panels removed

The Olympus XA with several panels removed

I have been shooting the olympus XA recently, and it is a wonderful camera.  It is small enough to fit in my the pocket of my jeans, but it makes nice big pictures with its fast f/2.8 lens.  When shooting, all the important controls are at your fingertips.  Some would say, given that it has a full-on rangefinder, that it is the poor mans leica.  Having never tested a Leica, I wouldn’t know.

However, it does have a few niggling issues.  There is no bulb mode, which makes taking more than 10 second exposures impossible.  There is also no remote release, which means that when I put it on my pocket tripod I can still get shutter shake, and I have to run into the frame if I am taking a group shot with people.  A remote release adds a lot of hackability, like triggering on motion, or at a particular time of day.  It would also make it possible to use the +1.5ev setting with a timer.  Some people also complain about focusing with the small rangefinder patch, but it is less of a big deal to me.

Finally, there are no filters available for it.  Now I didn’t realize how important this was until I took some pictures in my suite.  They are a horrible greenish color- and filters could help with this, except that there aren’t any.

In order to figure out the feasibility of hacking on some of these missing features, I found a donor camera to take apart.  It seems to be plagued by the mysterious and dreaded lens fungus, so I decided that since I couldn’t sell it, it would be donating its body to science.

If you are going to attempt this, I suggest grabbing a copy of the repair manual found here.  It does an ok job explaining the teardown, but real photos and notes are definitely useful.  It goes without saying (but I will anyway) that if you are going to do this, you are responsible for whatever damage happens to your camera.  That being said, it is an amazing piece of mechanical engineering.

IMG_4196

The first part to go (and the last one back on) is the base plate.  It is attached to the bottom by five screws- three shorter ones on the right of the picture, and two longer ones on the left.  One of the longer screws is hiding under the options lever in the upper left part of the camera.

IMG_4198

If you pull up on the bottom cover, it should come off.  This is the inside of the cover.  The only thing that might stick is the selection lever- but there is no firm mechanical connection there.

IMG_4200

Here is the inside of the bottom of the camera.  It already looks pretty exciting!  If you are having battery/power/self check problems, this is a good way to take a really good look at the battery holder and test for (or clean out) any corrosion.

IMG_4206

A groove in the bottom plate holds the sliding door on, via the hook you can see at the bottom of the cover in this photo.  Once the bottom is gone, the sliding door can be removed by gently prying the bottom part of the door upwards.  It should pop right out, but be careful not to let the tiny roller bearing escape (and it will).

IMG_4207

The next step is to remove the rewind lever.  This is pretty simple- just unscrew the bolt right in the middle.

IMG_4240

Next is the top.  The first thing to do is to carefully pry up the iconic red shutter release.  It is fastened to the camera via some kind of glue.  With that removed, the only things keeping the top on are two more screws in the well of the rewind lever and a conspicuous screw next to the rangefinder window (on the back side of the camera).

The Olympus XA with several panels removed

The Olympus XA with several panels removed

The next thing to go is the front panel.  A few obvious screws hold it in.  This gives you access to the front of the lens and the CdS cells that control exposure, but I didn’t need to tear into it further because it turns out that the front plastic on the lens is threaded onto the brass that holds the front element!  Score, if I want to add a filter.  Could turn a metal adapter to replace the plastic that would mate with a filter.  The only complication would be adding ev compensation to the meter, without using the 1.5 ev lever.  I wouldn’t want to use the lever because then I would loose some flexibility if shooting with a filter.

IMG_4210

 

Reassembly is pretty straightforward, except for the shutter release button. The shutter release it both loved and hated by the users of the camera- it is oh-so-sensitive, but it also wears out and is not very tactile- it is a lot closer to a membrane switch than a modern DSLR release.  Personally, I like it, and when I took the camera apart I decided not to just superglue it in.  Instead I used the large mating surface of the shutter release and the button face to put on more adhesive than was originally used, but at a lower strength.  Hopefully this allows me to take the button out more easily next time.

Lightbulb PCR Usage

Exploded/Cross sectioned view of Lightbulb PCR Machine

Exploded/Cross sectioned view of Lightbulb PCR Machine

If you really really want to use the lightbulb PCR machine, here are a few tips:

Note the plug

Note the plug

It is a good idea to add a small ball of wax or a drop (20ul) of mineral oil to your reaction.  This will form a plug/barrier so that your reaction cant evaporate and condense all over your tube.  There is no heated lid here!  Watch out if you use oil because it will solidify into a plug in your tube if you don’t pipette the sample out withing a minute or so of the final extension.

It is a good idea to add a few (10-20) seconds to each PCR step to allow your sample tube to get to the same temperature as the sensor.  The reaction is almost definitely larger in thermal mass than the sensor, so it will take longer to get to the correct temperature.  To help this, use the smaller .5ml thin-walled tubes.

IMG_4973

The proper way to mount samples is by taping them inside the taper of the 2-4 coupler, as seen here.  The sensor should be taped nearby.

And dont forget to modify the parameters of your reaction per the instructions in the code section of the documentation (previous post)!