daisy chaining multiple 74hc595s using USI/SPI on Attiny84.

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am confused about how to use the 74HC595 with the ATtiny84 uc. I would like to run 4 595s daisychained using spi off the ATtiny84. There is no CS or SS pin dedicated on the tiny84 and I plan on using one of the GPIO pins for this purpose. My question is do I need a seperate GPIO pin for each of the 595s RCLK or can I simply use one for all of the 595s and simply push through my 4 bytes of data (obviously with the 595s configured with Qh to SER)? 

Last Edited: Sat. Dec 28, 2019 - 11:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should be able to daisychain four of the'595s' and use all commonized wires, as though they were simply a single 32 bit shift register.

Of course, using separated latching lines would allow you to update individual '595 devices, at the expense of using up more avr pins.  The only advantage there would be speedier updates of a particular group of bits...In most cases you are not in an extreme hurry, so daisychain seems like a decent option.  However, if you will end up with spare AVR pins anyhow, then maybe go with separate latching signals.  A toss up! 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have written some code trying to get this tiny84 to do what I want but with very little luck.

when using the DO pin to feed data out to a shift register I am loading my data into the USIDR then toggling it out. The program doesn't work as expected. When I run the code in the debugger on AS7 and step through the code and get a high bit at the USIDRs msb the PINA5 bit goes high rather than the PORTA5 bit which would be my DO pin.

 

To make matters worse what I actually see is 10 repeatedly shifting through all of my shift registers. 

I must be making a mistake in setting this up somehow.

 

trying to drive 4 74hc595s from an attiny84 using TWI/USI

 


.NOLIST
.INCLUDE "tn84def.inc" 
.LIST

.org 0x00

Init:
	ldi r17, (1<<DDA5)|(1<<DDA4)|(1<<DDA3)     ; should be 0x38 in r17 after next line
	out DDRA, r17; 
	ldi r17, (1<<PUD)
	out MCUCR, r17
	
Main:
;	ldi r16, 0xff					
;	rcall SPITransfer
;	ldi r16, 0x00
;	rcall SPITransfer
;	rjmp Main
	;;
Starburst_pattern:
;;	ldi r18, 0x00    ; 
;    ldi r19, 0x05    ; used to count down complete pattern loop
Starburst_loop:
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x10
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r17, 0x08
	rcall SPITransfer
	ldi r16, 0x40
	rcall SPITransfer
	ldi r16, 0x11
	rcall SPITransfer
	ldi r16, 0x05
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer	
	ldi r16, 0x51
	rcall SPITransfer
	ldi r16, 0x11
	rcall SPITransfer
	ldi r16, 0x15
	rcall SPITransfer
	ldi r16, 0x01
	rcall SPITransfer
	ldi r16, 0x11
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x10
	rcall SPITransfer
	ldi r16, 0x01
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	ldi r16, 0x00
	rcall SPITransfer
	;dec r19         ; next 3 lines forces sequence to pass through 5 times before returning to main loop
	;cpse r19, r18
	;rjmp Starburst_loop
	;ret
	rjmp main


SPITransfer:				; step by step shift out from uc to 595
	out	USIDR, r16
	ldi r16, (1<<USIWM0)|(0<<USICS1)|(0<<USICS0)|(1<<USITC)              ;gave value of 0x11 in r16
	ldi r17, (1<<USIWM0)|(0<<USICS1)|(0<<USICS0)|(1<<USITC)|(1<<USICLK)  ;gave value of 0x13 in r17
	
	out USICR, r16	;MSB
	out USICR, r17
	out USICR, r16
	out USICR, r17
	out USICR, r16
	out USICR, r17	
	out USICR, r16
	out USICR, r17	
	out USICR, r16
	out USICR, r17	
	out USICR, r16
	out USICR, r17	
	out USICR, r16
	out USICR, r17	
	out USICR, r16  ;LSB
	out USICR, r17	
	ldi r18, (1<<PA3)
	out PORTA, r18
	rcall Delay
	ldi r18, (0<<PA3)
	out PORTA, r18
	ret	 


Delay:	
    ldi r19, 01     ; One clock cycle;
Delay1:
    ldi r20, 01     ; One clock cycle
Delay2:
    dec r20            ; One clock cycle
    nop                     ; One clock cycle
    brne Delay2          ; Two clock cycles for true 1 clock for false

    dec  r19            ; One clock Cycle
    BRNE Delay1          ; Two clock cycles for true 1 clock for false
    ret

 

Here is how the circuit is currently laid out on by breadboard

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see now in my code a mistake I've made. I am not allowing all 4 bytes to get pushed through the 4 registers before I latch the 595s outputs. Still conused why I'm seeing the pin go high instead of the port while debugging though. I'll modify my code tomorrow. Hopefully somebody smarter than me in the meantime can pick out other flaws in my setup or code and let me know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


 

 

NEVER allow lines to intersect with a dot, unless it is a "T" 3-way connection.  If such a dot becomes hard to see, such as a zoomed out copy paste, or poor printing, it will get very confusing & can lead to disaster.

 

Also, avoid showin a dot that is right at the component...dots should be along a wire.  Putting a dot right at the part may hide (cover up) a lack of a proper connection alignment.  Then  the intended connection can be missed during PCB layout, since it doesn't officially exist (in this case neither wire would be grounded , but they would connect together).

 

As far as your circuit, why is MOSI (Master Out Slave In) grounded??...are you trying to short the output of the SPI???!!!!  How do you expect data to get data out of the AVR to your shift registers?  Of course if you bitbang the whole thing you can use any pin...but it is bad form to use the opposite pin!

 

 

 

what is going on here???  Another dastardly connection?

 

 

You lack bulk caps on your power supply (like 47uF , 100uF, etc)..you don't want your power to glitch all around when you flash all of those leds!

 

 

more  dots......where are the wires!  You are preparing to create disasters in future designs.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Dec 31, 2019 - 06:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I do wonder why you'd design an SPI based application using a micro that doesn't actually have SPI?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
As far as your circuit, why is MOSI (Master Out Slave In) grounded??.

Better look again!

 

Over all the circuit looks ok to me, although as already pointed out you need some bulk caps on your 5 volt rail and I would also add some bypass caps 100nf to EACH shift reg close to the vcc/gnd pin pairs.

As for the code, the datasheet has an example assembly listing for how to use the USI as an SPI device, you should use that code for your SPI_xfer() function.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll add the capcitors as suggested previously. I've tried to use the code provided in the datasheet for the usi/spi function but with similar results. The code I'm using here was also provided by the datasheet too.

I'm still confused why i see PINA5 go high instead of PORTA5 when a logic 1 bit gets transferred out of the USIDR? I have DDRA5 set up as an output.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No good answer. I have dome components, I have an idea for something I want to accomplish, so I'll attempt whatever I can to make it happen and hopefully learn something along the way.

I guess I latched onto this because I want to send out bytes serially to a SIPO device and this usi on the 84 seemed like it could handle it.

What would you suggest? To get a tiny84 to control 32 leds in a grid with pre calculated patterns?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hexluthor wrote:
Still conused why I'm seeing the pin go high instead of the port while debugging though.

Since the USI controls the pin state, I would expect to see the PIN reg to reflect the state of the port pin, the PORT reg has been overridden by the USI peripheral. 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

As far as your circuit, why is MOSI (Master Out Slave In) grounded??.

 

Better look again!

 

DID YOU NOT LOOK YOURSELF?  Trace MOSI fully---it certainly shows going to gnd.  This schematic needs a serious redraw! Also, MOSI should be going to the chip, not MISO & MOSI should not be grounded.

 

Also, the reset switch as no effect since pins 2 3 4 5 6 7 are always grounded

 

Redraw & ensure dots are only placed on wires, NEVER on component pins

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Dec 31, 2019 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your spi transfer function includes usi init code, I would suggest you make a seperate function to init the USI that gets called only once at program start.

Also SPI has multiple clock modes, USI supports two modes (mode 0 or mode 1), it looks like your using mode 0, have you tried using mode 1?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shift registers are not speed-sensitive so you could test your hardware using pushbutton switches on the data, clock and latch lines, as slow as you like. There are many youtube videos demonstrating this. Unless you are very confident, always breadboard first before committing to a PCB. The devices cost pennies, are still available in a DIP package, and it's the work of 10 mins to wire it up.

 

is your data transfer requirement so fast that you really need to use SPI ? I'd keep things simple.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

is your data transfer requirement so fast that you really need to use SPI ? I'd keep things simple.

 

 

Since the data is a multiple of 8, either spi or bitbang would be just fine & very simple.  Slower is better, it will tolerate cabling, wiring, noise, etc.  However, the schematic shows reset permanently connected to gnd...so it's not going to run very fast!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that pin is for ISP, as it is DI for USI,

DO is connected to the shift registers!

 

Jim

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Tue. Dec 31, 2019 - 07:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No I haven't tried to use a different mode but I am sure that I am selecting the three wire mode which uses the DO, DI and USCK pins. I believe this because when my SPITransfer function is called a set but USIWM0 to = 1 which according to the data sheet is what I need to do. This may be why some of the comments have been saying that I need to use the MOSI pin rather than the MISO pin but this isn't actually SPI and the DO pin happens to be shared with the MISO rather than the MOSI pins. I do have my MOSI pin tied to ground because im not using it as I'm not intending on getting anything back from the shift registers I am driving. I could initialize the USI on its own to see if that is causing me problems. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I would like to run 4 595s daisychained using spi 

  I need to use the MOSI pin rather than the MISO pin but this isn't actually SPI 

 

I'm not sure what you mean by this.  SPI certainly uses 3 lines: mosi, miso, & sck, plus a chip select.   That's pretty much standard everywhere.   I'm not exactly following your explanation  

 

also, why is your reset always held to gnd?

 

edit:

Oh, I see this is rather strange...the data sheet says (as is expected)  • Port A, Bit 6 – ADC6/DI/SDA/MOSI/OC1A/PCINT6 • ADC6: Analog to Digital Converter, Channel 6. • SDA: Two-wire mode Serial Interface Data. • DI: Data Input in USI Three-wire mode. USI Three-wire mode does not override normal port functions, so pin must be configure as an input for DI function. • MOSI: Master Data output, Slave Data input for SPI channel. When the SPI is enabled as a Slave, this pin is configured as an input regardless of the setting of DDA6. When the SPI is enabled as a Master, the data direction of this pin is controlled by DDA6

 

However, it appears you can't use the spi as master (or at all???)....so I see why you are not using MOSI (even though the datasheet mentions setting & using it!)

 

also, why is your reset always held to gnd?

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Dec 31, 2019 - 10:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Further to the comments with the schematic - I doubt the hc595 will want to source 160mA. There are specific chips for driving leds - I'd suggest you seek these out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

 

is your data transfer requirement so fast that you really need to use SPI ? I'd keep things simple.

 

 

Since the data is a multiple of 8, either spi or bitbang would be just fine & very simple.  Slower is better, it will tolerate cabling, wiring, noise, etc.  However, the schematic shows reset permanently connected to gnd...so it's not going to run very fast!

 

LOL yeah it wouldn't run very fast at all. the switch for my reset is NO and the reset pin connected to 5v via 10k resistor. I don't need spi or speed. I see suggestions of bit banging and I think that's what ill end up doing. I looked at my circuit running and see I'm running way to fast for the 595ic anyways and need to slow the whole thing down. I'm sending the pulse out to the SRCLK for such a short duration of time it's never triggering the 595 I think. or not controlling it correctly at least.

 

the schematic is messy. thrown together not necessarily using the exact parts I have on my bread board...

Last Edited: Wed. Jan 1, 2020 - 12:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, you should spend some minutes to clean up the schematic & try to follow it...so they match your build....your schematic shows reset pin going to some other pins all tied to gnd.  Since you code runs, you can't be following the schematic (unless you've disabled the reset pin functionality).

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The hc595 is good for at least 15MHz, so I don't think speed is the issue. You do need to ensure the data setup and hold times are observed.

 

If you're going to do a pcb - the quality gets put in the schematic. Cut corners here and it'll end up as pcb problems.

 

Last Edited: Wed. Jan 1, 2020 - 01:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes tomorrow I will redo my schematic it makes sense not to cut corners there. I have managed to get everything working on my breadboard although I gave up on trying to use the chips USI features and just wrote the sequence out in code for pushing data out and controlling the 595s.

I'm not done trying to make it work though. Thanks for the help and suggestions. I'll post an updated schematic tomorrow along with the code I put together.

Last Edited: Wed. Jan 1, 2020 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just had a look at the hc595 datasheet. Output current per pin is 6mA. Absolute max for the device is 70mA - so you want to stay far away from this. Clock rate is 25MHz typ.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are higher power 'versions' of the 595, e.g. TPIC6B595 is good for 150mA drain but cannot source current. You should still be able to find thru-hole parts for breadboarding. I don't know if there are any gotchas which would prevent using it as a drop-in replacement for 'HC595. http://www.ti.com/product/TPIC6B595

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hexluthor wrote:
I will redo my schematic it makes sense not to cut corners

Speaking of not cutting corners, the first thing to do before the fine detail of a schematic is to have a high-level design of what you're trying to do.

 

eg, a block diagram.

 

https://www.avrfreaks.net/commen... - in the context of https://www.avrfreaks.net/commen...

 

See also: https://www.avrfreaks.net/commen...

 

And: https://www.avrfreaks.net/commen...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...