possible to synch digital out puts so they turn on or off at the same time?

[Gibson486]

Is it possible to sync the outputs of the stm32 so you can sync or delay the outputs so they turn on at one time? Or is my best bet to use I/O on one port and control each port by it's 32 bit (or is it 16) register and deal with the delay from one port to another?

[ataradov]

There is no way to synchronize them. The best you can do is minimize the delay by carefully optimizing the write code.

[eutectique]

Use ODR to output a data pattern.
Use BRR to set selective pins to zeros.
Use BSRR to set selective pins to ones.

Is it what you are after?

[ataradov]

No, he needs to synchronize multiple different ports (toggle 32 pins at the same time, for example).

[ledtester]

Would DMA be a possible solution?

[ataradov]

It would still have a delay. Two consecutive store instructions in the code would be faster than DMA.

No matter what, you will be accessing two different peripherals. It is not possible to do at the same time.

[tggzzz]

Is it possible to sync the outputs of the stm32 so you can sync or delay the outputs so they turn on at one time? Or is my best bet to use I/O on one port and control each port by it's 32 bit (or is it 16) register and deal with the delay from one port to another?

Replace adjectives with numbers, and the question might be answerable.

Are you thinking in terms of ms, µs, ns, ps, fs?

If you switch them all "at the same time", how much ground bounce will there be in your system?

Alternatively, design your system so that it is tolerant of different outputs changing at "different times".

[SiliconWizard]

Yeah, what do you define as "sync"?

If it's within say 1 µs, then it should be possible with care and disabling interrupts. Depending on the MCU, system clock and peripheral clock, you may manage to get down to 100 ns or less.
But otherwise, no go.

Just use the same port if that needs to be done. Still define what "sync" means to you, as there will still be a small delay between I/O of the same port, even if it looks tiny.

Alternatively, if you absolutely have to use I/Os that are on separate ports, you could use an external latch IC and control the output change with an additional GPIO as clock.

[ddrown]

Would a timer's output compare fit your needs? That would give you very precise control on the delay between two outputs

[DavidAlfa]

I'd say to simply avoid brainstorming until OP properly anwers to the first messages... So many threads end in smoke!

[Gibson486]

No, he needs to synchronize multiple different ports (toggle 32 pins at the same time, for example).

Correct, but it sounds like delays are gonna happen since you can only access one register/port at a time.

[Gibson486]

Would DMA be a possible solution?

Hmmm...I have never used DMA before...so I would need to look into that.

[Gibson486]

Yeah, what do you define as "sync"?

If it's within say 1 µs, then it should be possible with care and disabling interrupts. Depending on the MCU, system clock and peripheral clock, you may manage to get down to 100 ns or less.
But otherwise, no go.

Just use the same port if that needs to be done. Still define what "sync" means to you, as there will still be a small delay between I/O of the same port, even if it looks tiny.

Alternatively, if you absolutely have to use I/Os that are on separate ports, you could use an external latch IC and control the output change with an additional GPIO as clock.

Are you taking about shift registers? If so, I have done it with 8 bit shift registers and cascaded them, but they can be painful code wise (especially when you have to onboard people). I'd rather just code it from an IC than deal with shift registers.  Also, when things go wrong, debugging can be painful.

[ataradov]

DMA is using the same bus. Except in case of DMA you would need to use linked lists, and there would be an additional delay. Two consecutive store instructions is the fastest way of doing it. The delay would equal to one bus clock cycle.

[Gibson486]

Is it possible to sync the outputs of the stm32 so you can sync or delay the outputs so they turn on at one time? Or is my best bet to use I/O on one port and control each port by it's 32 bit (or is it 16) register and deal with the delay from one port to another?

Replace adjectives with numbers, and the question might be answerable.

Are you thinking in terms of ms, µs, ns, ps, fs?

If you switch them all "at the same time", how much ground bounce will there be in your system?

Alternatively, design your system so that it is tolerant of different outputs changing at "different times".

I was actually thinking at the same time. I was wondering if there was something that can latch the output until another register bit is set. Otherwise, as fast as possible would be nice (ns time). I was thinking of maybe using an IO expander type deal, but none have an input that allows you to delay the output update until you set a pin, or atleast I have not found one.

[Marco]

You would only use an IO expander if you also want to do serial to parallel at the same time.

Otherwise you could simply use D-type latch ICs from your favourite logic family.

[SiliconWizard]

Yeah, what do you define as "sync"?

If it's within say 1 µs, then it should be possible with care and disabling interrupts. Depending on the MCU, system clock and peripheral clock, you may manage to get down to 100 ns or less.
But otherwise, no go.

Just use the same port if that needs to be done. Still define what "sync" means to you, as there will still be a small delay between I/O of the same port, even if it looks tiny.

Alternatively, if you absolutely have to use I/Os that are on separate ports, you could use an external latch IC and control the output change with an additional GPIO as clock.

Are you taking about shift registers? If so, I have done it with 8 bit shift registers and cascaded them, but they can be painful code wise (especially when you have to onboard people). I'd rather just code it from an IC than deal with shift registers.  Also, when things go wrong, debugging can be painful.

No no, just a simple parallel register. N inputs, N outputs. 1 clock to latch the inputs to the outputs, so the outputs would all change in sync on the clock pulse.
From a programming POV, that wouldn't change anything except that an additional GPIO (for the clock input of the register) would trigger the change reflected on the outputs. A shift register wouldn't get you that behavior.
A typical reference would be a 74HC574.

[tggzzz]

Is it possible to sync the outputs of the stm32 so you can sync or delay the outputs so they turn on at one time? Or is my best bet to use I/O on one port and control each port by it's 32 bit (or is it 16) register and deal with the delay from one port to another?

Replace adjectives with numbers, and the question might be answerable.

Are you thinking in terms of ms, µs, ns, ps, fs?

If you switch them all "at the same time", how much ground bounce will there be in your system?

Alternatively, design your system so that it is tolerant of different outputs changing at "different times".

I was actually thinking at the same time. I was wondering if there was something that can latch the output until another register bit is set. Otherwise, as fast as possible would be nice (ns time). I was thinking of maybe using an IO expander type deal, but none have an input that allows you to delay the output update until you set a pin, or atleast I have not found one.

The basic strategy would be to have two stages of registers. The first stage is setup at leisure using as many write operations as convenient. The output of those registers would be the input to the second stage.

Then the processor would use a single operation to clock all the first stage outputs into the second stage registers.

Variants could include

• only having a single stage of registers, and using a single processor operation to enable the outputs
• using an FPGA

Such partitioning of functionality between pure hardware and pure software is a standard part of system design.

[DavidAlfa]

Still missing lots of details. How many different ports? Acceptable delay with numbers? STM32 speed?

Something like:

Code: [Select]

__attribute__((optimize("Ofast")))
void writePorts(uint32_t valA, uint32_t valB, uint32_t valC){
  GPIOA->ODR = valA;
  GPIOB->ODR = valB;
  GPIOC->ODR = valC;
}

Generates:

Code: [Select]

8000168: b430      push {r4, r5}
 800016a: 4b04      ldr r3, [pc, #16] ; (800017c <writePorts+0x14>)
 800016c: 4d04      ldr r5, [pc, #16] ; (8000180 <writePorts+0x18>)
 800016e: 4c05      ldr r4, [pc, #20] ; (8000184 <writePorts+0x1c>)
 8000170: 60e8      str r0, [r5, #12]
 8000172: 60e1      str r1, [r4, #12]
 8000174: 60da      str r2, [r3, #12]

Each port is updated with only 1 instruction from each other.
IIRC the STR instruction takes 2 cpu cycles in ARM, this would be ~40ns @ 50MHz.


Otherwise, use a latch.
You can daisy chain any number of 74HC595s, send a serial stream through SPI and sync the oututs with the latch clock (Pin 12).

[hans]

Several problems with that code:

STR in sequences is not guaranteed at all.

It will break on longer sequences because of register scheduling pressure (it can probably only find space for 5-6 values).

Nearly not all ARM chips have 2 cycles latency. On STM32H7, a store to GPIOs can take 10 clock cycles.

The best way IMO is to automate this procedure by hardware. A timer could work a handful of compare channels, but if its getting wider it gets increasingly more tricky to do on a MCU (especially at high frequencies)

[DavidAlfa]

It was just a simple example showing it can be done pretty close

He's not said anything about the device so what gives?
What's the true required accuracy for sync? No idea.
Is it 2 ports, 4 ports, 6 ports? Who knows.
STM32F0? F1? G0? Same thing.

Maybe it has a clock signal so all this could be ignored at all by simply updating that port last.

I'm seriously tired of seeing threads filled with hypothetical devices and conditions.
Maybe, perhabs, what if, I wonder...

Last message: It was for updating some leds! Damn!

[wek]

Using FSMC/FMC on a sufficiently large package could bring you closer to 50 simultaneously switching pins.

JW

[westfw]

The popular 74x595 shift register has a separately clocked output register.  You can shift in bits one at a time for essentially any number of cascaded bits, and then transfer all the bits to the output pins "at the same time."  Presumably it would be relatively easy to duplicate the logic using parallel loaded registers for the cpu-side.  As tggzzz described, I guess.  Essentially the same idea as a "master slave flip-flop."
It wouldn't be any faster than writing the bits to separate IO registers non-concurrently (I guess you could achieve equal speed, if the last data transfer automatically triggered the latch), but you could achieve simultaneous changes at the outputs.

[Gibson486]

The popular 74x595 shift register has a separately clocked output register.  You can shift in bits one at a time for essentially any number of cascaded bits, and then transfer all the bits to the output pins "at the same time."  Presumably it would be relatively easy to duplicate the logic using parallel loaded registers for the cpu-side.  As tggzzz described, I guess.  Essentially the same idea as a "master slave flip-flop."
It wouldn't be any faster than writing the bits to separate IO registers non-concurrently (I guess you could achieve equal speed, if the last data transfer automatically triggered the latch), but you could achieve simultaneous changes at the outputs.

That is what we do now. It works, but it is dreadfully painful to maintain. We have about 96 digital outs, so when issues happen, it becomes quite the adventure to debug.

To answer other questions, I did not specify which stm32, because it is fair game at this point. I have only used the F4 and to my knowledge, it does not have any special feature that allows this. Also, not sure why people think this is for LEDs.

Also, atleast for now, I am fine with ns timing, but obvioulsy same time would be the goal, but that does not seem possible with the MCU alone.

[DavidAlfa]

Managing 96pins with 595s shouldn't be that much of an issue.
If you're fine using the STM32 ports, you can add transparent latches like the 74HC573. Update the ports and finally issue a pulse to LE (Latch Enable) so they all sync together.
F4s easily run at 100MHz+. Have you tried to measure the actual delay between ports? Might be low enough.

You're the one knowing the details, we don't. You're still mising basically everything related to the timings.
What's the target receiving this data? Is the STM32 a master or a slave?
The only scenario I can think of requiring extremely tight timings is a data bus externally clocked, so you can't delay it more than the timing specifications.
But if you're the master, it should be doable somehow by calibrating the GPIO latency.