gpio: gpio-74x164: add support for CDx4HC4094
Subsystems (2)
PATCH 1/2 gpio: gpio-74x164: add support for CDx4HC4094
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Add support for an optional strobe pin.
--- drivers/gpio/gpio-74x164.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/gpio/gpio-74x164.c +21 -0
@@ -21,6 +21,7 @@ struct gen_74x164_chip {struct gpio_chip gpio_chip;struct mutex lock;struct gpio_desc *gpiod_oe; +struct gpio_desc *gpiod_strobe;u32 registers;/* * Since the registers are chained, every byte sent will make
@@ -66,6 +67,10 @@ static void gen_74x164_set_value(struct gpio_chip *gc, chip->buffer[bank] &= ~(1 << pin);__gen_74x164_write_config (chip); + +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 );mutex_unlock (&chip->lock); }
@@ -87,6 +92,10 @@ static void gen_74x164_set_multiple(struct gpio_chip *gc, unsigned long *mask, chip->buffer[bank] |= bitmask; }__gen_74x164_write_config (chip); + +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 );mutex_unlock (&chip->lock); }
@@ -129,6 +138,12 @@ static int gen_74x164_probe(struct spi_device *spi)gpiod_set_value_cansleep (chip->gpiod_oe,1 ); + chip->gpiod_strobe =devm_gpiod_get_optional (&spi->dev,"strobe" , +GPIOD_OUT_LOW ); +if (IS_ERR (chip->gpiod_strobe)) +return PTR_ERR (chip->gpiod_strobe); + +spi_set_drvdata (spi, chip); chip->gpio_chip.label = spi->modalias;
@@ -153,6 +168,10 @@ static int gen_74x164_probe(struct spi_device *spi) goto exit_destroy; } +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 ); + ret =gpiochip_add_data (&chip->gpio_chip, chip);if (!ret)return 0 ;
@@ -182,6 +201,8 @@ MODULE_DEVICE_TABLE(spi, gen_74x164_spi_ids);static const struct of_device_id gen_74x164_dt_ids[] = { { .compatible ="fairchild,74hc595" }, { .compatible ="nxp,74lvc594" }, + { .compatible ="ti,cd54hc4094" }, + { .compatible ="ti,cd74hc4094" }, {}, };MODULE_DEVICE_TABLE (of, gen_74x164_dt_ids);
Signature · 1 line
2.36.1
PATCH 2/2 dt-bindings: gpio: fairchild,74hc595: add strobe-gpios property
Some shift registers (74hc4094 for example) has a strobe signal to latch data from the serial input to the parallel output.
Add an optional strobe-gpios property to support those chips.
--- .../devicetree/bindings/gpio/fairchild,74hc595.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml +6 -0
@@ -14,6 +14,8 @@ properties: enum: - fairchild,74hc595 - nxp,74lvc594 + - ti,cd54hc4094 + - ti,cd74hc4094 reg: maxItems: 1
@@ -33,6 +35,10 @@ properties: description: GPIO connected to the OE (Output Enable) pin. maxItems: 1 + strobe-gpios: + description: GPIO connected to the STROBE pin + maxItems: 1 + spi-max-frequency: true patternProperties:
Signature · 1 line
2.36.1
Re: [PATCH 2/2] dt-bindings: gpio: fairchild,74hc595: add strobe-gpios property
Quoted 24 lines · Marcus Folkesson
Some shift registers (74hc4094 for example) has a strobe signal to latch data from the serial input to the parallel output.
Add an optional strobe-gpios property to support those chips.
Signed-off-by Marcus Folkesson <[email protected]>--- .../devicetree/bindings/gpio/fairchild,74hc595.yaml | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml +2
-0@@ -14,6 +14,8 @@ properties: enum: - fairchild,74hc595 - nxp,74lvc594 + - ti,cd54hc4094 + - ti,cd74hc4094 reg: maxItems: 1
Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml properties: · line 40
Quoted 6 lines
Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml +3
-0@@ -33,6 +35,10 @@ properties: description: GPIO connected to the OE (Output Enable) pin. maxItems: 1 + strobe-gpios: + description: GPIO connected to the STROBE pin + maxItems: 1
This should be disallowed (in allOf:if:then) for variants which do not support it (or do not have even STROBE pin).
Best regards,
Krzysztof
Re: [PATCH 2/2] dt-bindings: gpio: fairchild,74hc595: add strobe-gpios property
In reply to Marcus FolkessonQuoted 6 lines · Marcus Folkesson
Some shift registers (74hc4094 for example) has a strobe signal to latch data from the serial input to the parallel output.
Add an optional strobe-gpios property to support those chips.
Signed-off-by Marcus Folkesson <[email protected]>
As pointed out in discussion with Andy, let's drop this and just use cs-gpios as-is.
Yours,
Linus Walleij
Hello Marcus,
Am Thu, Jul 21, 2022 at 11:34:21AM +0200 schrieb Marcus Folkesson:
Quoted 1 line
74hc4094 and 75hc4094 works similar to 74x164 but has an additional
^^
That 75 is probably a typo, isn't it?
Greets
Alex
Quoted 80 lines
storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Add support for an optional strobe pin.
Signed-off-by Marcus Folkesson <[email protected]>--- drivers/gpio/gpio-74x164.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)drivers/gpio/gpio-74x164.c +21
-0@@ -21,6 +21,7 @@ struct gen_74x164_chip {struct gpio_chip gpio_chip;struct mutex lock;struct gpio_desc *gpiod_oe; +struct gpio_desc *gpiod_strobe;u32 registers;/* * Since the registers are chained, every byte sent will make @@ -66,6 +67,10 @@ static void gen_74x164_set_value(struct gpio_chip *gc, chip->buffer[bank] &= ~(1 << pin);__gen_74x164_write_config (chip); + +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 );mutex_unlock (&chip->lock); }@@ -87,6 +92,10 @@ static void gen_74x164_set_multiple(struct gpio_chip *gc, unsigned long *mask, chip->buffer[bank] |= bitmask; }__gen_74x164_write_config (chip); + +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 );mutex_unlock (&chip->lock); }@@ -129,6 +138,12 @@ static int gen_74x164_probe(struct spi_device *spi)gpiod_set_value_cansleep (chip->gpiod_oe,1 ); + chip->gpiod_strobe =devm_gpiod_get_optional (&spi->dev,"strobe" , +GPIOD_OUT_LOW ); +if (IS_ERR (chip->gpiod_strobe)) +return PTR_ERR (chip->gpiod_strobe); + +spi_set_drvdata (spi, chip); chip->gpio_chip.label = spi->modalias;@@ -153,6 +168,10 @@ static int gen_74x164_probe(struct spi_device *spi) goto exit_destroy; } +/* Latch data to output pins*/ +gpiod_set_value_cansleep (chip->gpiod_strobe,1 ); +gpiod_set_value_cansleep (chip->gpiod_strobe,0 ); + ret =gpiochip_add_data (&chip->gpio_chip, chip);if (!ret)return 0 ;@@ -182,6 +201,8 @@ MODULE_DEVICE_TABLE(spi, gen_74x164_spi_ids);static const struct of_device_id gen_74x164_dt_ids[] = { { .compatible ="fairchild,74hc595" }, { .compatible ="nxp,74lvc594" }, + { .compatible ="ti,cd54hc4094" }, + { .compatible ="ti,cd74hc4094" }, {}, };MODULE_DEVICE_TABLE (of, gen_74x164_dt_ids);Signature · 1 line
2.36.1
Quoted 4 lines · Marcus Folkesson
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
parallel
Quoted 1 line
Add support for an optional strobe pin.
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 8 lines · Andy Shevchenko
Quoted 4 lines · Marcus Folkesson
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Quoted 6 lines
parallel
Quoted 1 line
Add support for an optional strobe pin.
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
I have a 595 register which also has a latch. What I expect to see in this series is just a compatible string addition (but again, why even that is needed?).
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
Quoted 4 lines · Marcus Folkesson
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Quoted 6 lines
parallel
Quoted 1 line
Add support for an optional strobe pin.
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
You're right, I didn't think of that CS could be used for this. The additional compatible strings is then superfluous, so I will skip those.
Quoted 5 lines
Signature · 3 lines
-- With Best Regards, Andy Shevchenko
Best regards
Marcus Folkesson
Quoted 7 lines · Andy Shevchenko
Quoted 4 lines · Marcus Folkesson
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Quoted 6 lines
parallel
Quoted 1 line
Add support for an optional strobe pin.
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS.
If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished.
If you first do the SPI transfer, then strobe after finished, this will not happen.
Then it should be a separate pin, so this doesn't happen, right?
Yours,
Linus Walleij
Quoted 38 lines · Linus Walleij
Quoted 7 lines · Andy Shevchenko
Quoted 4 lines · Marcus Folkesson
74hc4094 and 75hc4094 works similar to 74x164 but has an additional storage latch associated with each stage for strobing data from the serial input to parallell buffer tri-state output.
Quoted 6 lines
parallel
Quoted 1 line
Add support for an optional strobe pin.
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS.
If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished.
If you first do the SPI transfer, then strobe after finished, this will not happen.
Then it should be a separate pin, so this doesn't happen, right?
Yours,
Linus Walleij
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 4 lines · Linus Walleij
Quoted 2 lines · Andy Shevchenko
On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson
<[email protected]> wrote:
...
Quoted 7 lines
Quoted 2 lines
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS.
No, CS here is used exactly for what it is designed for ("tell that this message is *for me*"). Yes, hardware implementation here is a latch register. Because otherwise ALL messages are "for me" which is wrong. Is it wrong interpretation of the hardware and SPI?
Quoted 7 lines
If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished.
I'm not sure I understand the stabilization issue here. It's how SPI normally works and we have a lot of delays here and there related to the phase of the CS in comparison to clock and data. We have a lot of time to stabilize the outputs of the shift register before latching it. Did I miss anything?
Quoted 2 lines
If you first do the SPI transfer, then strobe after finished, this will not happen.
I have hardware, I have tested it and I understand what you mean by "stabilizing", but finishing transfer _is_ CS toggling for _this_ chip. No?
Quoted 2 lines
Then it should be a separate pin, so this doesn't happen, right?
I think no, you don't need it. I.o.w. either I'm missing something very interesting about both this kind of chips and SPI basics (shame on me in this case) or...?
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 16 lines · Andy Shevchenko
Quoted 4 lines · Linus Walleij
Quoted 2 lines · Andy Shevchenko
On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson
<[email protected]> wrote:...
Quoted 7 lines
Quoted 2 lines
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS.
Quoted 4 lines
No, CS here is used exactly for what it is designed for ("tell that this message is *for me*"). Yes, hardware implementation here is a latch register. Because otherwise ALL messages are "for me" which is wrong. Is it wrong interpretation of the hardware and SPI?
I was under the impression that the shift register has no idea if the message is "for me", and that there can only be one shift register on the bus if using ordinary SPI to control it.
I look at this data sheet:
https://www.farnell.com/datasheets/2030250.pdf
IIUC what you say is CS == STR?
Quoted 8 lines
Quoted 7 lines
If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished.
Quoted 5 lines
I'm not sure I understand the stabilization issue here. It's how SPI normally works and we have a lot of delays here and there related to the phase of the CS in comparison to clock and data. We have a lot of time to stabilize the outputs of the shift register before latching it. Did I miss anything?
STR (strobe) is latching out the data, and how is that happening when you connect it to CS? CS is asserted throughout the whole transaction...
STR is supposed to be used like in the patch: to be toggled after the transfer is complete. CS does not behave like this at all.
Quoted 6 lines
Quoted 2 lines
If you first do the SPI transfer, then strobe after finished, this will not happen.
I have hardware, I have tested it and I understand what you mean by "stabilizing", but finishing transfer _is_ CS toggling for _this_ chip. No?
Well it will work, because all values come out, however *during* the transfer, not *after* the transfer as intended with the STR signal.
Quoted 6 lines
Quoted 2 lines
Then it should be a separate pin, so this doesn't happen, right?
I think no, you don't need it. I.o.w. either I'm missing something very interesting about both this kind of chips and SPI basics (shame on me in this case) or...?
SPI will assert CS, then make the transfer i.e. toggle the clock a few times with new data on MOSI each clock cycle, then de-assert CS.
STR is supposed to be toggled after all this happened to latch out the data to the outputs, just like the patch does.
What happens if STR is connected to CS is that you will see the shift register contents change on the output. It will be fast so it will look fine if it is e.g. a LED. But if it is something more sensitive, there will be chaos.
At least how I see it ...?
Yours,
Linus Walleij
Quoted 19 lines · Linus Walleij
Quoted 16 lines · Andy Shevchenko
Quoted 4 lines · Linus Walleij
Quoted 2 lines · Andy Shevchenko
On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson
<[email protected]> wrote:...
Quoted 7 lines
Quoted 2 lines
Sorry for my absence of understanding, but why?
SPI has MOSI, CLK, CS, where the last one is exactly for that. No?Forgive me if I misunderstand, but if you use CS that way, the way that the SPI framework works is to assert CS then transfer a few chunks over SPI (MOSI/CLK) then de-assert CS.
Quoted 8 lines
Quoted 4 lines
No, CS here is used exactly for what it is designed for ("tell that this message is *for me*"). Yes, hardware implementation here is a latch register. Because otherwise ALL messages are "for me" which is wrong. Is it wrong interpretation of the hardware and SPI?
I was under the impression that the shift register has no idea if the message is "for me", and that there can only be one shift register on the bus if using ordinary SPI to control it.
Yes and no. Yes, the shift register in this HW is always 'for all'. No, there are as many shift registers as you have chip selects on the same bus.
Quoted 4 lines
I look at this data sheet:
https://www.farnell.com/datasheets/2030250.pdfIIUC what you say is CS == STR?
Yes.
Quoted 14 lines
Quoted 8 lines
Quoted 7 lines
If CS is used for strobe, it is constantly asserted during transfer and the sequence will be latched out immediately as you write the SPI transfers and the data is clocked through the register, making the whole train of zeroes and ones flash across the output pins before they stabilize after the SPI transfer is finished.
Quoted 5 lines
I'm not sure I understand the stabilization issue here. It's how SPI normally works and we have a lot of delays here and there related to the phase of the CS in comparison to clock and data. We have a lot of time to stabilize the outputs of the shift register before latching it. Did I miss anything?
Quoted 3 lines
STR (strobe) is latching out the data, and how is that happening when you connect it to CS? CS is asserted throughout the whole transaction...
Is it a problem? I consider it exactly what it's designed for, it tells the chip: "hey, there is something for you".
Quoted 2 lines
STR is supposed to be used like in the patch: to be toggled after the transfer is complete. CS does not behave like this at all.
How is CS different in this sense? Just longer? Who cares that it starts early and latches exactly at the time it must latch the data.
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
If you first do the SPI transfer, then strobe after finished, this will not happen.
I have hardware, I have tested it and I understand what you mean by "stabilizing", but finishing transfer _is_ CS toggling for _this_ chip. No?
Well it will work, because all values come out, however *during* the transfer, not *after* the transfer as intended with the STR signal.
No. I think you missed one little but crucial detail. The strobe is edge, not level, while you consider CS as a level signal (only).
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
Then it should be a separate pin, so this doesn't happen, right?
I think no, you don't need it. I.o.w. either I'm missing something very interesting about both this kind of chips and SPI basics (shame on me in this case) or...?
SPI will assert CS, then make the transfer i.e. toggle the clock a few times with new data on MOSI each clock cycle, then de-assert CS.
Right.
Quoted 2 lines
STR is supposed to be toggled after all this happened to latch out the data to the outputs, just like the patch does.
So...
Quoted 4 lines
What happens if STR is connected to CS is that you will see the shift register contents change on the output. It will be fast so it will look fine if it is e.g. a LED. But if it is something more sensitive, there will be chaos.
See Figure 7 and Table 9 in the datasheet you linked to. When STR is low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere
in a more clear table.
Quoted 1 line
At least how I see it ...?
If what you are saying is true, the hardware is totally broken and I wouldn't use it. I.o.w. if the strobe passes all data when it's at low level and latches at low-to-high, it's broken by definition in my point of view.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 1 line · Andy Shevchenko
On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <[email protected]> wrote:
...
Quoted 1 line
See Figure 7 and Table 9 in the datasheet you linked to. When STR is
Table 9 --> Figure 9
Quoted 3 lines
low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere
in a more clear table.
If you have hardware and an oscilloscope you may test it. We will know for sure :-)
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 4 lines · Andy Shevchenko
Quoted 1 line · Andy Shevchenko
On Tue, Jul 26, 2022 at 12:22 AM Linus Walleij <[email protected]> wrote:
...
Quoted 7 lines
Quoted 1 line
See Figure 7 and Table 9 in the datasheet you linked to. When STR is
Table 9 --> Figure 9
Quoted 3 lines
low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere
in a more clear table.
Ah, Table 3 shows that.
Quoted 2 lines
If you have hardware and an oscilloscope you may test it. We will know for sure :-)
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 8 lines · Andy Shevchenko
Quoted 3 lines · Linus Walleij
Well it will work, because all values come out, however *during* the transfer, not *after* the transfer as intended with the STR signal.
No. I think you missed one little but crucial detail. The strobe is edge, not level, while you consider CS as a level signal (only).
Aha! Then it works :)
Quoted 11 lines
See Figure 7 and Table 9 in the datasheet you linked to. When STR is low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere
in a more clear table.Quoted 1 line
At least how I see it ...?
If what you are saying is true, the hardware is totally broken and I wouldn't use it. I.o.w. if the strobe passes all data when it's at low level and latches at low-to-high, it's broken by definition in my point of view.
I have seen strobes that are level-active in my life, but if you say this one isn't then all is fine!
Yours,
Linus Walleij
Quoted 20 lines · Linus Walleij
Quoted 8 lines · Andy Shevchenko
Quoted 3 lines · Linus Walleij
Well it will work, because all values come out, however *during* the transfer, not *after* the transfer as intended with the STR signal.
No. I think you missed one little but crucial detail. The strobe is edge, not level, while you consider CS as a level signal (only).
Aha! Then it works :)
Quoted 7 lines
See Figure 7 and Table 9 in the datasheet you linked to. When STR is low, the data is not changed. Maybe it's not clear in this datasheet, I found somewhere
in a more clear table.Quoted 1 line
At least how I see it ...?
Quoted 7 lines
Quoted 4 lines
If what you are saying is true, the hardware is totally broken and I wouldn't use it. I.o.w. if the strobe passes all data when it's at low level and latches at low-to-high, it's broken by definition in my point of view.
I have seen strobes that are level-active in my life, but if you say this one isn't then all is fine!
It's rather my common sense, because we have a clock here to shift a register. It's kinda obvious *to me* that when we have a latch, that latch shouldn't pass data on a level. Yes, there are buffers with level strobe, but it's different. So, as I said, the oscilloscope can finish our discussion one way or the other, but I believe it will be my way ;) I will very (badly) surprised if it becomes your way. It will ruin my beliefs in humanity. Not less.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
It's rather my common sense, because we have a clock here to shift a register. It's kinda obvious *to me* that when we have a latch, that latch shouldn't pass data on a level. Yes, there are buffers with level strobe, but it's different. So, as I said, the oscilloscope can finish our discussion one way or the other, but I believe it will be my way ;) I will very (badly) surprised if it becomes your way. It will ruin my beliefs in humanity. Not less.
I think you are right Andy, I trust your judgement better than my own here for sure!
Yours,
Linus Walleij
Quoted 12 lines · Linus Walleij
Quoted 7 lines · Andy Shevchenko
It's rather my common sense, because we have a clock here to shift a register. It's kinda obvious *to me* that when we have a latch, that latch shouldn't pass data on a level. Yes, there are buffers with level strobe, but it's different. So, as I said, the oscilloscope can finish our discussion one way or the other, but I believe it will be my way ;) I will very (badly) surprised if it becomes your way. It will ruin my beliefs in humanity. Not less.
Quoted 2 lines
I think you are right Andy, I trust your judgement better than my own here for sure!
The true science when we put any statement in doubt and then go step-by-step to prove it again. If this will be done successfully the statement is correct. That said, thank you to put this in doubt, it's appreciated!
Signature · 2 lines
With Best Regards, Andy Shevchenko