I just use serial to/from parallel shift registers with latches:- 74HCT595 for output, CD4021 for input. The 595 doesn't have high drive capability, but that is often not needed.
I think that the reason why the LEDs driven by the PCF8574 are so dim is that the PCF doesn't have classical push-pull output, but a weird one where it's either in low state (which can drive up to 25 mA typically, the 10 mA is minimum spec), or in high state, which has only a 100 uA current source. So if my guess is correct, you are driving the LEDs against ground, so you are driving them with 100 uA. See the datasheet, page 12.
Is it possible to use audio input (e.g. inmp441 i2s) or audio output (e.g. max98357A i2s) via these port expanders? If yes how is it done, especially the pin config? Thanks for any advice. I only got buttons, leds, encoders to work.
Florin , this might be a bit of but when do you think it is worth using these kinds of IC since at some point getting another MCU or larger package would be cheaper (and i assume better due to lower latency ) . Also in this case i assume you are using them as DC signals wouldn't some multiplexed flip plops be better? (maybe the IC is this inside , not sure). Also relating the LEDs , i saw your video but i am still not sure how to find high efficiency ones. Or rather what would be some good filters in order to find some or , lets say mouser/farnell . More cnd /mA is the goal BUT what would a good ratio be ? and/or what would be a good way to find them ?
There are multiple factors to consider so it's not a matter of which option is best in general but which option is best for your specific application: I have to consider cost, current drive capability, control gpio usage and firmware support. So for this application an I2C GPIO expander is the best solution.
This is a classic trap with the PCF8574 for which I have fallen my self. The chip has a high rated SINK current (IE current into the pin) where as it only has a 300uA SOURCE current (Current out of the pin). Which makes it not very good at driving loads.
I fell into this trap too with PCF8574 and its bigger brother 16-bit PCF8575. I solved the problem by adding Darlington drivers like the 8-bit ULN2803 which can sink approx. 60ma per channel, enough to drive mechanical relays.
Yes, the weak source ability of the 8574 surprised me as well. A 595 shift register does not have this problem. Another unexpected quality is the power consumption -- the 8574 can get quite hot.
trouble i am having is when i set them to input and apply +v, they show in the code a logic 1 and logic 0 with no volts, but the pin is drawing like 60ma!!! the only 'guess' I have is that the library is only setting them for input while doing the read then they are reverting to output or some other weird thing
@@lezbriddon You set a register mask for reading. There are really only two states though: High resistance with high voltage (read), and Low resistance with low voltage. I have been able to put a button and indicator LED safely on the same pin by rapidly polling. Tie one end of the LED high, through a resistor.
Hey Florin! I've used the MCP23017 (16 I/O) on a project of mine. On unexpected behavior I've had ocasionally intermittent issues where on first powerup, it will not react to the first command. Weird. maybe? a library issue. I should test again sometime, but seemed worrying at the time for my project. Also, do you have any chatroom where you chat outside of YT? maybe considered making a Discord channel?
I2C is a serial bus of course and any noise during power up / initialization can be seen as bit clocking. Once any bit is clocked you are now out of sequence with your intended framing. Send a reset command or two - be sure and wait for it to serialize - and you should be okay. Also if you are initializing for high speed mode be sure and delay before you send the first commands thereafter. These parts are very primitive (I2C dates back to the 1970's) and today's high end microcontrollers are way faster than the original microcontroller specs (2Mhz or below) supported. Code must be written to tolerate turnaround times and to prevent bashing a transaction in progress.
@@dennisfahey2379 Ah, thanks. That might be just it, that actually explains a lot tbh.. I'll keep that in mind when I go back to the project. Pretty sure it wasn't a hardware issue.
@@danedwards_ee - No problem. The thing you get into is if every IO is across that serial bus you are bashing it quite a lot. And of course it is by far the slowest thing in the system. So its imperative to have an I2C service routine that runs that interface intelligently. At the driver level it sort of needs to be abstracted like PCI-E. You post your command and watch for a driver flag that indicates it is completed and if a read cycle - data is available. (Semaphore) You don't want to have the processor waiting for each transaction to complete - doing nothing else. The driver can buffer the commands and handle the actual interface. A common error I've seen is when people add a ton of IO and add I2C muxes to flip between device "groups". The muxes, too, must be locked in state when a serialization and response occurs. Then they are in "IDLE" and free to change the mux and start a new command on an alternate group. Ideally the CPU should be watching a bulletin board in memory of transaction and state with the driver reconciling from the other side. Finally, IF you must for some reason support hot insertion/extraction of an I2C device - that driver better know to timeout and retry a transaction that get corrupted. Sadly I2C has no parity or error checking - whatever gets manifested by the corruption will be executed as a valid command. It was never intended for this mode.
pay extra for the 23008, the 8574 is a nightmare for input, and useless for (+) output as its limited to 100ua .this makes it fine for say keyboard scanning (theres a library/sketch for that) but for driving leds / 7 segment displays or switching transistors for relays i would avoid it
I just use serial to/from parallel shift registers with latches:-
74HCT595 for output, CD4021 for input.
The 595 doesn't have high drive capability, but that is often not needed.
Thanks for this help full tutorial. It's very good! Thanks for all your work!
Great walkthrough of the process 👍
Thanks for sharing your experience with all of us 👍😀
I think that the reason why the LEDs driven by the PCF8574 are so dim is that the PCF doesn't have classical push-pull output, but a weird one where it's either in low state (which can drive up to 25 mA typically, the 10 mA is minimum spec), or in high state, which has only a 100 uA current source. So if my guess is correct, you are driving the LEDs against ground, so you are driving them with 100 uA. See the datasheet, page 12.
Your guess is correct. It is indeed a trap for those like myself which don't read deep enough into the datasheet 😂
Is it possible to use audio input (e.g. inmp441 i2s) or audio output (e.g. max98357A i2s) via these port expanders? If yes how is it done, especially the pin config? Thanks for any advice. I only got buttons, leds, encoders to work.
how do you make those texts labels in kicad, i mean the inverted ones. dont know what they are called. shown at 4:25 on the left side of baord.
It's the KiBuzzard plugin for KiCad!
Florin , this might be a bit of but when do you think it is worth using these kinds of IC since at some point getting another MCU or larger package would be cheaper (and i assume better due to lower latency ) .
Also in this case i assume you are using them as DC signals wouldn't some multiplexed flip plops be better? (maybe the IC is this inside , not sure).
Also relating the LEDs , i saw your video but i am still not sure how to find high efficiency ones. Or rather what would be some good filters in order to find some or , lets say mouser/farnell . More cnd /mA is the goal BUT what would a good ratio be ? and/or what would be a good way to find them ?
There are multiple factors to consider so it's not a matter of which option is best in general but which option is best for your specific application: I have to consider cost, current drive capability, control gpio usage and firmware support. So for this application an I2C GPIO expander is the best solution.
@@voltlog THX , but that about the LEDs?
I prefer to use LEDs rated for ~500mcd @ 10mA.
This is a classic trap with the PCF8574 for which I have fallen my self. The chip has a high rated SINK current (IE current into the pin) where as it only has a 300uA SOURCE current (Current out of the pin). Which makes it not very good at driving loads.
I fell into this trap too with PCF8574 and its bigger brother 16-bit PCF8575. I solved the problem by adding Darlington drivers like the 8-bit ULN2803 which can sink approx. 60ma per channel, enough to drive mechanical relays.
It is indeed a trap for those like myself which don't read deep enough into the datasheet 😂
Yes, the weak source ability of the 8574 surprised me as well. A 595 shift register does not have this problem. Another unexpected quality is the power consumption -- the 8574 can get quite hot.
trouble i am having is when i set them to input and apply +v, they show in the code a logic 1 and logic 0 with no volts, but the pin is drawing like 60ma!!! the only 'guess' I have is that the library is only setting them for input while doing the read then they are reverting to output or some other weird thing
@@lezbriddon You set a register mask for reading. There are really only two states though: High resistance with high voltage (read), and Low resistance with low voltage. I have been able to put a button and indicator LED safely on the same pin by rapidly polling. Tie one end of the LED high, through a resistor.
Hey Florin! I've used the MCP23017 (16 I/O) on a project of mine. On unexpected behavior I've had ocasionally intermittent issues where on first powerup, it will not react to the first command. Weird. maybe? a library issue. I should test again sometime, but seemed worrying at the time for my project.
Also, do you have any chatroom where you chat outside of YT? maybe considered making a Discord channel?
I2C is a serial bus of course and any noise during power up / initialization can be seen as bit clocking. Once any bit is clocked you are now out of sequence with your intended framing. Send a reset command or two - be sure and wait for it to serialize - and you should be okay. Also if you are initializing for high speed mode be sure and delay before you send the first commands thereafter. These parts are very primitive (I2C dates back to the 1970's) and today's high end microcontrollers are way faster than the original microcontroller specs (2Mhz or below) supported. Code must be written to tolerate turnaround times and to prevent bashing a transaction in progress.
@@dennisfahey2379 Ah, thanks. That might be just it, that actually explains a lot tbh.. I'll keep that in mind when I go back to the project. Pretty sure it wasn't a hardware issue.
@@danedwards_ee - No problem. The thing you get into is if every IO is across that serial bus you are bashing it quite a lot. And of course it is by far the slowest thing in the system. So its imperative to have an I2C service routine that runs that interface intelligently. At the driver level it sort of needs to be abstracted like PCI-E. You post your command and watch for a driver flag that indicates it is completed and if a read cycle - data is available. (Semaphore) You don't want to have the processor waiting for each transaction to complete - doing nothing else. The driver can buffer the commands and handle the actual interface. A common error I've seen is when people add a ton of IO and add I2C muxes to flip between device "groups". The muxes, too, must be locked in state when a serialization and response occurs. Then they are in "IDLE" and free to change the mux and start a new command on an alternate group. Ideally the CPU should be watching a bulletin board in memory of transaction and state with the driver reconciling from the other side. Finally, IF you must for some reason support hot insertion/extraction of an I2C device - that driver better know to timeout and retry a transaction that get corrupted. Sadly I2C has no parity or error checking - whatever gets manifested by the corruption will be executed as a valid command. It was never intended for this mode.
Very interesting!
can you make web interface for those devices?
Checkout Tasmota.
pay extra for the 23008, the 8574 is a nightmare for input, and useless for (+) output as its limited to 100ua .this makes it fine for say keyboard scanning (theres a library/sketch for that) but for driving leds / 7 segment displays or switching transistors for relays i would avoid it
👍