Electronics > Microcontrollers
possible to synch digital out puts so they turn on or off at the same time?
newbrain:
--- Quote from: Siwastaja on October 10, 2023, 07:00:37 am ---Having a full routing matrix on other peripherals, so that you can get all those UARTs and SPIs etc. out of the way instead of having them in fixed positions (or two-three choices only), pretty much solves this issue, and is hugely helpful in many other ways, too. This has proved an excellent feature in nRF52 and it can't be that expensive to implement. Peripherals with special analog requirements would still need fixed mappings, of course.
--- End quote ---
Another example is the PSoC family, with full routing of peripheral modules (and much more...).
But I also like what they did with the RP2040: one single 32 bit GPIO, with a full complement of set, clear, and xor registers, and a very liberal (and regular, easy to memorize!) mapping of SPI/I2C/UART, not 100% flexible but 99% sensible.
Nominal Animal:
--- Quote from: Siwastaja on October 10, 2023, 07:00:37 am ---But quite frankly, the most usual case why you have to do non-atomic modification in two or more steps is not because you are switching too many (say 17) pins at a time, but because you are switching maybe three or four pins which stupidly happen to reside in different ports.
--- End quote ---
I admit, because of the stuff I do –– using microcontrollers to interface to sensors and displays as extensions to Linux SBCs –– I spend a lot of time picking the pin sets using various spreadsheets before writing any code, so I don't usually get bitten by that.
I wonder how much silicon would be needed for a few full-matrix GPIO output buffer registers?
For example, let's say you have one or more 32-bit buffer registers, each with a full bit mask across all GPIO banks (128-bit mask if four 32-bit GPIO banks, for example), identifying the pins each bit affects. A write to such a register sets the corresponding pins in parallel, with conflicting bit masks (i.e. two different full bit masks having common bits set) yielding undefined/unpredictable/don't-care results? While the write would have no delay, the actual GPIO state change could be delayed by the typical cross-clock-domain delay, as long as all GPIO banks change state simultaneously, plus a constant number of subsystem clock cycles to generate the actual GPIO bank changes. (There are various ways to generate the needed bit masks and changesets in C/VHDL/hardware, the simplest being a shifter, leading to 32 cycle latency with 32-bit GPIO registers.)
If you wanted read support, it'd need to select a combinatoric logic –– OR, NOR, AND, XOR –– but otherwise be very similar. (Each output bit is the result of the combinatoric logic across the GPIO input data register bits corresponding to set bits in the full bit mask.) Note how the read trigger would be immediate, but the data only available after the aforementioned latency; a simple latch/FIFO mechanism (where reading causes the next read to latch on next clock cycle or so and starts propagating the new data, but returns previous latch contents) would probably be acceptable.
Note that this is not a crossbar-type situation, but a mask approach affecting all GPIO banks in parallel.
I haven't done FPGA stuff yet, but I see this as an added/optional subsystem with access to the GPIO port data registers in parallel (needing a mask-and-new-state write access to all GPIO banks in parallel). It'd be very interesting to test this with some real-world use cases on a soft-core, I think.
radiolistener:
two pins always have some phase difference. You're needs to be careful with PCB design. Keep electrical length of wires from your pins as close as possible, so they will have minimum phase difference. There is no way to add or remove some delay for some pin, like you can do on FPGA. The phase delay for each pin is fixed and depends on wire layout on die, so you can measure it and compensate with wires layout on your PCB.
But I suspect that jitter of stm32 don't allows you to be very precise with phase delay for all pins. It's better to use FPGA for that. It also has jitter, but it will better than for stm32.
Navigation
[0] Message Index
[*] Previous page
Go to full version