Daisy Chain of Ic74HC595 can it control a LCD screen.
#21
Posted 30 April 2012 - 04:27 AM
#22
Posted 30 April 2012 - 10:21 AM
It's not possible with this code to mix up different chips. So the chain should be filled with just 595's.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?
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#23
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
#24
Posted 30 April 2012 - 01:38 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.@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 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.
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#25
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 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
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users