Using an IO expander to retain pin values in deep sleep - Page 1
Forum section: electronics / projects

author: MrExpolre
author_rank: Newbie
timestamp: June 01, 2024, 12:46:30 pm
content: Hi all,First post here and I hope I'm posting in the right section.I use different microcontrollers for projects and I'm looking for a way to keep the state of outputs when going into deep sleep. I looking for a solution that is independent from the uc and programming. Would it be possible to use an IO expander like the MCP23008 (https://www.microchip.com/en-us/product/mcp23008) for this purpose?I'm hoping it could work like this:- uc is running and sets outputs on the expander over i2c- uc goes into deep sleep and thus 'forgets' the state of the outputs- since the expander has it's own power it will retain the output states when the uc is in deep sleep- uc wakes up and reads the output states from the expander over i2cDoes anyone know if this could work?Thanks in advance!

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 01, 2024, 01:29:29 pm
content: Sure, as long as the VCC voltage for the MCP23008 or whatever IC you use is still available in deep sleep.You can also use for example an octal latch like 74HC573 (CMOS) or 74HCT573 (TTL) to keep normal output pins' state, if you have an extra output pin to drive the LE pin (with a suitable pull-down resistor to ensure it will be low when the microcontroller is in deep sleep). When the LE pin is high, the output pin state will follow the input pin states; when the LE pin goes low, the output pin states remain in whatever state they were left as, as long as the /OE pin is low. (When /OE is high, the output pins will be high-Z, as if disconnected; the latch will still "remember" the pin states.)There are also serial-to-parallel latches like 74HC595 (CMOS), 74HCT595 (TTL), that you can use via SPI (clock and data out), and chain to get as many output pins as you want. The microcontroller provides a clock (SHCP), data (DS), and a separate latch (STCP, possibly with a pull-down resistor to ensure it is low when the MCU is in deep sleep). STCP is normally low. On each rising edge of SHCP, the internal shift register will move data one bit up, with the data shifted in. This does not affect the outputs. When all the data has been shifted in, you pull STCP high, so the '595 latches the current shift register contents to the actual outputs.Because they're so cheap and easy to use, '595 IC's are ubiquitous. For example, Mouser will sell you 100 NXP74HC595BQ,115for less than 14 €, which would give you 800 output pins. That particular one is also quite fast, as at 2V logic levels, you can clock in new states at 4 MHz; at 20 MHz at 4.5V. So, not only is it cheaper, but it can also change states much faster (because of 4× to 20× the clock frequency compared to I²C, plus no data overhead), if your microcontroller has a suitable SPI-like peripheral. Also, all the outputs change state simultaneously, not in sequence.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 01, 2024, 01:42:07 pm
content: There are many types of uC's and even more sleep modes in those uC's. With many sleep modes data in I/O registers is not lost, and thus there is no need to add extra hardware (which also uses some power).Using external hardware is of course also possible, from I2C, SPI, TTL IC's, shift registers etc. But you will have to be careful how you handle the connection between your uC and the rest of the hardware. If your uC can't remember an output level, you may trigger an active low reset, or mess up clock pulses or latches.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 01, 2024, 01:48:33 pm
content: I've never seen a MCU that doesn't hold output port values in sleep mode

author: Siwastaja
author_rank: Super Contributor
timestamp: June 01, 2024, 02:35:41 pm
content: And then you have just transitioned the power consumption to the IO expander. And have to research if some has sleep modes you need, and basically added one more dimension to the problem you already think is hard, and made it even harder.Instead, if low power matters, simply look at the microcontroller power management options before committing to a design. Choose a suitable microcontroller. Almost all offer sleep modes where GPIO output pin states are preserved. Then the question simply is whether they are low power enough or not. Adding another IC only adds more consumption.

author: MrExpolre
author_rank: Newbie
timestamp: June 01, 2024, 04:20:55 pm
content: Wow, thanks for the input all.A search led me from one thing to the next and I think I might want to go with a PCF8574I mainly work in micropython and using it seems pretty straightforward:https://github.com/mcauser/micropython-pcf8574/tree/masterhttps://github.com/xreef/PCF8574_micropython_libraryAnd yes, most (if not all) uc's have sleep modes where the output states are kept when sleeping but it requires specific code for each uc. Since I often switch when testing I'm looking for a solution that is not board specific. Completely planning ahead and selecting the right board for the job, let's say I tend to follow a different workflow.Adding additional components does shift power consumption but in case of the PCF8574 it seems to only need 10 uA in standby.Having pin state retention outside the uc would also give me the option to do a pre-emptive reset or do a reset on an unexpected error.In short, it would seriously make things easier for me.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 01, 2024, 04:38:51 pm
content: None of this makes any sense at all. You plan on playing around with many different dev/demo boards? I have bad news for you - most are not designed for low power at all.Since you are implying that every microamp matters, there is no generic way to do that with every demo board in existence using the same code. What's wrong in device-specific? That's how everybody else does it.Since this is a classic X-Y problem, now the question is, what are youactuallydoing?

author: hans
author_rank: Super Contributor
timestamp: June 01, 2024, 05:00:41 pm
content: Low-power design can be tricky as wanting low I/O power consumption may also require extra measures to be taken.For example, floating input pins can be problematic as a pin at half supply voltage that may partially open a push-pull structure of some internal digital logic gate, which will then leak significant current.To solve this, some MCU mfgrs recommend configuring the pin in an analog mode, which then disconnects the floating input pin from digital structures that cause leakage.However, other MCUs may actually recommend configuring the pin as output with the output fixed high or low, which will also solve this issue (and subsequently to any other devices the I/O signal is connected to, for example, a SPI bus with some devices connected).If you're talking about holding I/O state: then this is exactly what the MCU is doing in all these cases. Otherwise the aforementioned problem cannot be solved without tieing all external I/O on the board.Imo no need for external I/O expanders. For practical purposes, I view those chips also as MCUs with some ROM firmware. The MCP23008 even has a RESET pin..Low-power solutions often go against a jellybean design solution. Everything takes extra care to make sure it's configured in the right state/mode to do what you want. Off the shelf devboards are rarely properly optimized for this purpose, especially when they have lots of bells and whistles.edit:please don't take my post as "you should/can not do that". If you want to use I/O expander, then sure that will work just as well. I was just about explaining how it is not strictly necessary.

author: PlainName
author_rank: Super Contributor
timestamp: June 01, 2024, 05:28:35 pm
content: QuoteHe didn't say that. He said he switches micros - you can use them, and even switch a lot, without using a dev or demo board. And having off-micro I/O would make switching easier.QuoteHe gave an example where it doesn't: a processor reset. I could envision a system where the output would be needed to hold state whilst the processor code is updated, so that's another example.

author: MrExpolre
author_rank: Newbie
timestamp: June 01, 2024, 05:46:20 pm
content: OK people, thanks for all the (critical...) input and suggestions.I'm sorry that I'm not a (semi-) professional in electronics. I'm just trying to explore my options and experiment in this field.It seems the level on this forum is 'a bit' above my level.I'll go over the info and experiment some more.For now, let's just close this thread.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 01, 2024, 07:59:55 pm
content: Quote from: MrExpolre on June 01, 2024, 04:20:55 pmIO expanders are simple, and can also give level shifting too.Check the data, other parts are even better icc than pcf8574Keep in mind, any voltage not within ~500mV of the rails, will also increase icc, as will any external loads.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 02, 2024, 06:01:31 am
content: Quote from: PlainName on June 01, 2024, 05:28:35 pmThat's an interesting point because this is what I need in current project of mine. Luckily, in my case, the IO which needs to retain state through processor reset (basically, asserting internal MCU-wide reset signal by NVIC_SystemReset()), drives mechanical relays, so a low pulse of some microseconds is acceptable. I solved the problem by choosing a RAM region outside of what init code clears, retaining the content. Obviously, during power-on reset the contents of this RAM is random. Therefore for each relay, I chose randomly generated 32-bit magic values (one more paranoid about accidental triggering on power-up reset could use more bits), which is checked for very early in the bootloader code, and the relevant IO set to output high value. Since relay coils store energy, they retain their mechanical position well even if the pulse ends up being close to a millisecond, and most microcontrollers boot (from assertion of reset line, to execution of first dozen instructions) faster than that.But if instead of relays I had to interface with something that detects the edges, then I would need something different, for example:1) Don't do full software resets. That's entirely possible. You have other options, like deinit/reset peripherals separately, jump to reset vector...2) Use an external chip (latch, flipflop, IO expander, another MCU)... But then the question is, doesthatneed resetting, and if not, why not?And, I would choose 1. In my current example case, I do full software reset because I can afford doing it, and it's the simplest way; but I really don'thave to.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 02, 2024, 06:07:00 am
content: Quote from: MrExpolre on June 01, 2024, 05:46:20 pmTherefore, very generic advice: Keep It Simple, and avoid premature generalizations. Pick a microcontroller or a devboard and design your project around that. Worry about porting to another micro/board later. You might then want to rewrite the whole thing anyway, as you know more.Even well-resourced organizations and individuals keep struggling and failing with generic microcontroller programming layers. Generic compatibility across brands is extremely difficult and usually a huge time sink which has only serious compromises to offer. Even if you are finally able to make a cross-compatible project, it likely sucks in performance metrics such as power consumption.

author: jbb
author_rank: Super Contributor
timestamp: June 02, 2024, 09:03:37 am
content: I’ve used (as the electrical engineer) I2C IO expanders to manage IO during sleep modes. It works well, but does add some complexity.I’ve also used logic gates to make latches and that works OK. Basic logic gates may be the way to go if you need a guaranteed state on power up (e.g. needing to enable some power rails before the microcontroller can boot).You’ll need to read your CPU manual carefully to check what happens to pins in assorted sleep modes. Some micros just hold the IO how you set them (yay!) others do dumb stuff like making them high impedance (boo!). Some might even do annoying stuff like applying weak pull up. There may also be differences depending on the sleep modes you use.A word of advice; check your pull up resistors. Sometimes they can be responsible for quite a lot of power if some pin is held low during the sleep state.

author: tooki
author_rank: Super Contributor
timestamp: June 02, 2024, 03:45:37 pm
content: Quote from: MrExpolre on June 01, 2024, 05:46:20 pmDon’t get annoyed. It’s totally normal for alternatives to get suggested and debated.Quote from: MrExpolre on June 01, 2024, 05:46:20 pmNo, the other participants in the thread have the right to keep discussing it even if you decide to leave (which I don’t think you should do, but it’s your choice).Mods, please don’t close it. (Nor other uncontentious threads when people ask to have them closed.)

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 02, 2024, 10:31:30 pm
content: Quote from: MrExpolre on June 01, 2024, 05:46:20 pmI myself am only an old Uncle Bumblefuck (per AvE terminology), and an utter hobbyist in electronics.Quote from: MrExpolre on June 01, 2024, 05:46:20 pmNo, it is not.You might wish to read theWhy writing style and grammar matters in posts(a sticky in the Beginners forum). Although it isn'texactlyapt here, it gives you some important background about technical discussions.Simply put, you need to remember that this thread is NOT about you, and it does not criticize anything about you. Your person is not involved in any of this.The only thing we are discussing is your question and its implications, consequences, solutions, and so on. The two things being criticized by some were 1) trying to use different microcontrollers as if they were freely interchangeable, which they are not, and some find it very important to use an appropriate tool for the job, instead of shoe-horning every problem to be solvable by any tool (or worse, one's favourite tool –– the saying is, "when the only tool you have is a hammer, every problem will look like a nail"), and 2) not using a microcontroller for which such added complexity is not necessary in the first place.There is zero reason for you to feel offended.To mutually beneficially interact in technical questions, we all need to remember that our persons or personalities are not involved AT ALL, and that it is only about what we write and discuss. Having even a heated argument about one technical issue, problem, solution, or tool in one thread is perfectly okay, because it is about a technical issue:it is not personal. It is equally important to be able to have a friendly agreement in another technical issue in another thread, concurrently, when that happens to be the case.Because it is not personal.If it happens that you don't get the kind of responses that would be useful to you, you must understand it is not about you as a person, only about your output. And that output, its formatting and content, you can always adjust and modify to suit your needs, without violently trying to change yourself as a person. Which is why I wrote the Why... post I linked to above in the first place. I myself still feel the need to use a pseudonym here instead of my real name,only to remind myself of this! In other words, my pseudonym is my humorous crutch/tool helping me do this myself.What we all do need to remember is that unlike in most social media where emotions are the king, here we discuss technical details and problems and solutions, and emotions and subtext are secondary (if that). Many technical people are near-blind to social cues and emotional subtext anyway, so reading such in their posts is an error: all there is is accidental noise, nothing intended.My own biggest affliction is verbosity. Walls of text. I don't just spew this out unthinking; I spend at least twice the time editing my posts than I take writing them. Some members have to skip my posts here, because they're just too long, and I understand that. I'm trying to be more concise. That's why my own answer just affirmed that your scheme would work, then suggested other parts for related uses, as I²C is a bit limited. I, too,wastempted to suggest using a microcontroller with suitable sleep modes instead, but it was only relatively recently that I myself understood the wide use cases of e.g. 74-series '595 (serial to parallel with latch). And I too like to explore possibilities –– I've got a library of well over a thousand experiments/verifications of various software algorithms and implementations ––, so as a first response, I chose my answer as I did, knowing that others would follow it up, and I too would likely learn more from them. (Which is why I too am opposed to "closing" any threads here, unless it is due to trolling or looping in circles or becoming personal or nasty.)So, instead of being offended and feeling that others are criticising your person or skills, you MUST realize they are only criticising your question and implied solution (of working around mis-choice of MCU for that particular purpose using external components). Which is perfectly okay, because they didn't know you're just exploring and trying to expand your toolbox. (Even if they did, others will read this thread later, and remindingthemabout proper tool for the job would be very appropriate and useful.) This is the world of technical discussions, and it only works if we don't let our emotions rule.to everyone, especially the OP.