2011-12-30 09:07 AM
I've got a display that has 8 data bits and a write strobe input which needs to be 250ns (or more).
I was considering using a timer (One-pulse mode), but it looks complicated (I'm new to the STM32 :) )I need a solution which is software triggered but don't care which pin is the strobe as I've not connected it yet :)Any suggestions?2011-01-01 06:48 AM
FSMC? Oh dear, looks like I have some more reading to do :)
I was considering a for loop delay but it just feels nasty, especially considering all the lovely stuff built into the chip...2011-12-30 12:30 PM
With 18 cycles to burn at 72 MHz, I wouldn't bother with a timer or interrupts. The method would be to drive the GPIO pin directly, and count core cycles. You could I guess see if the FSMC could be suitably configured to write/strobe data directly.
2012-01-02 02:17 PM
I was considering a for loop delay but it just feels nasty, especially considering all the lovely stuff built into the chip...
But lets be realistic, the chip's timer could generate 250ns pulses, and could do so repetitively, but doing it once, and waiting for it to complete is going to take more cycles than using brute force. Figure writing an APB register is going to take at least 4 cycles each. If you're talking to one of those 16x2 LCD panels you'll need a host of other delays, and spin on busy loops. Yes, software delay loops are ugly, which is why I suggest counting core cycles rather than hard coding something, or using an empty for() loop. There are clearly better solutions for micro/milli second delays.
2012-01-03 01:54 AM
Cheers Clive, I think I'll go for the empty for(); loop.
I believe I'm running at 72MHz, but as you say, I shouldn't hard code the value. Problem is, there seems to be a lot of bits to check in RCC->CFGR. Or do I just cheat and use a const?The next part of my little project will be interfacing with a keypad matrix, I don't think I can steer clear of a timer for that one :)