Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Daisy Chain of Ic74HC595 can it control a LCD screen.


  • Please log in to reply
24 replies to this topic

#21 smarcus3

smarcus3

    Advanced Member

  • Members
  • PipPipPip
  • 134 posts

Posted 30 April 2012 - 04:27 AM

If I wanted to make a 595 control 8 leds, should I use the 595 or some other IC. If I used another how would it be used on the same ic chain? Thanks
Steve


My Other Hobby: Engineer Turned Baker

#22 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 30 April 2012 - 10:21 AM

If I wanted to make a 595 control 8 leds, should I use the 595 or some other IC. If I used another how would it be used on the same ic chain?

It's not possible with this code to mix up different chips. So the chain should be filled with just 595's.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#23 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 30 April 2012 - 11:36 AM

It's not possible with this code to mix up different chips. So the chain should be filled with just 595's.


@Stefan:
It would be possible if only you release the SPI once the command has been sent. I know I'm tedious, but the "monopolization" of the SPI is a great error, IMHO.
It's not you only, though: it's an issue still not fixed in the MF 4.2.


@Smarcus:
Please, also consider my library instead of the uLiquidCrystal. The hardware is roughly the same, but yields a much higher performance, and the ability to connected as many SPI-devices as you want.
http://highfieldtale...ss.com/tag/lcd/

Cheers
Biggest fault of Netduino? It runs by electricity.

#24 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 30 April 2012 - 01:38 PM

@Stefan:
It would be possible if only you release the SPI once the command has been sent. I know I'm tedious, but the "monopolization" of the SPI is a great error, IMHO.
It's not you only, though: it's an issue still not fixed in the MF 4.2.

I know the SPI object in .NETMF isn't perfect for multiple devices, hence my MultiSPI class. Perhaps not the most beautiful solution, but it works.
I don't know what you ment by "monopolization" though, the SPI object is wrapped and can be accessed by anyone.

Also, it will still be almost-impossible to chain different types of chips on a single latch pin, since they don't necessarily use the same daisy chain protocol. That's why I strongly recommend not chaining different chips in one chain.

Using different types of SPI chips on the same bus, yes, that's possible. But in the same chain can raise some problems.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#25 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 30 April 2012 - 01:58 PM

I know the SPI object in .NETMF isn't perfect for multiple devices, hence my MultiSPI class. Perhaps not the most beautiful solution, but it works.
I don't know what you ment by "monopolization" though, the SPI object is wrapped and can be accessed by anyone.

Also, it will still be almost-impossible to chain different types of chips on a single latch pin, since they don't necessarily use the same daisy chain protocol. That's why I strongly recommend not chaining different chips in one chain.

Using different types of SPI chips on the same bus, yes, that's possible. But in the same chain can raise some problems.


Two different problems:
1- the MF SPI has a flaw, IMHO, allowing the user to change the config without closing-then-reopening the port. For the serial port is mandatory, for the SPI is not. Let's forget the unfair different interface for two device similar, but the problem is that you can generate a memory leak. This is an evil bug, IMHO: an hole that should be filled.
Moreover, most of the users use the SPI just relying on that flaw: that's *really* evil!

2- About your MultiSPI, you should avoid to declare statically the SPI, nor keep the port possess "indefinitely". It's much like as the SPI was a network printer, and you only have the ability to print. What about your work mates asking for print?
Instead, you should either:
  • avoid any class-wide SPI (private) reference, and ask the user to specify it on every method invoke, or
  • keep a class-wide SPI (private) reference, but open the port as needed, then close it immediately after.
The first method would be preferable, because it allows the user to share without pain the SPI across threads. Using the 2nd method, this problem is left to your implementation.


The SPI itself, or -if you want the MF impl- has no problems with different chips. You can glue as many logic-chips as you want, as long you'll manage the chip-selects (SSEL) correctly. That's an hardware problem, however. I mean: if I connect an HC595 and an HC165, the software should allow me to drive them independently without problems.

Cheers
Biggest fault of Netduino? It runs by electricity.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.