matsalleh
Member
Hello,
I'd like to develop a driver for this LCD: http://www.sparkfun.com/datasheets/LCD/LCD-08335-1.pdf
One of the logic requirements is a 9MHz clock.
The period of this less than 1 microsecond, so I can't use:
digitalWrite();
delay;
How can I produce a 9MHz clock (without using assembly language)?
If I can't produce a clock signal, is there a way I can use an external clock and count the pulses?
Thanks,
Chris.
gbulmer
Moderator
matsalleh - It might help to explain your familiarity with microcontroller programming.
The STM32F103 microcontrollers are described in detail in the manual RM0008:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf
The Maple has 4 timers. Any one of them could generate the 9MHz signal you want.
They are autonomous hardware, so once setup, they will continue to generate the signal without any further software intervention.
The approach is to set the timer to count at a base frequency of 9MHz, which is 72MHz/9MHz = a count of 8
then set a timer 'channel' to drive a pin with a square wave, which will have a 9MHz frequency when the channel 'compares' a value of half the count.
Each timer has three or four pins which can output a signal.
This tells you which pins are connected to which timers:
http://leaflabs.com/docs/hardware/maple.html#timer-pin-map
This is the reference for the HardwareTimer:
http://leaflabs.com/docs/lang/api/hardwaretimer.html#lang-hardwaretimer
Assuming you know quite a lot about MCU programming:
set the prescaler to 1 so that it counts at 72MHz,
the overflow value to 8 so that it starts again after 8 72Mhz counts, and
the channel corresponding to the output pin to a compare value of 4, so it triggers half way through the cycle.
Set the mode of the channel to TIMER_OUTPUT_COMPARE.
You could set the timer mode TIMER_PWM, but the overflow count and compare values need to be halved as the effective frequency is halved.
Feed the pin corresponding to the timer channel to the thing that needs 9MHz.
matsalleh
Member
That's great, thanks!
Would I be able to actually count individual pulses though?
For example I need to pulse the LCD 10 times with vSync low to reset the scan position. However to write a line I need to pulse the LCD 41 times with hSync high.
Is this feasible?
I've done a fair bit of programming in C with arduino, and some stuff with uART on PICs, but that's about it.
Thanks,
Chris.
gbulmer
Moderator
Chris - Okay, so you have experience of how to program microcontrollers. I think that is enough to make this work.
You will likely need to read the RM0008 manual to understand and use all the features of the timers you need.
You might want to start by reading the libmaple code for the timers. Quite a lot of ideas are demonstrated in that code, and you can use some of it without change (e.g. setting pinMode, prescaler and reload values).
Would I be able to actually count individual pulses though?
What needs to be counted, and what is it you need to measure?
Every timer can operate in several modes.
An external signal can be used to drive the timers counter, so that can count pulses.
Or, an external signal can be used to trigger a copying of the timers counter, so that can time an external pulse.
For example I need to pulse the LCD 10 times with vSync low to reset the scan position. However to write a line I need to pulse the LCD 41 times with hSync high.
I'm not sure what rate is being used for the pulse, is it the 9MHz?
A common way to generate a fixed number of pulses is to use a short interrupt service routine which gets called every pulse. It counts down the number of pulses, subtracting one each time, until it reaches zero, when it triggers the code to carry out the final action. In this case, that might be nothing at all; let the main loop() code wait on the pulse count to reach zero, then it goes ahead and does whatever is necessary. The nice thing about this approach is it is very simple. The bad thing is it is too slow if you want to count 9MHz pulses. It is good enough for something around a Mhz or slower (it takes about 24 cycles to enter and return from an interrupt routine).
Timers can be 'chained' so the output of one timer (say generating a 9Mhz square wave) can be fed directly (inside the chip) into another timer to drive the 'slave' timer's counter.
Have a look at RM0008 section 15.3.15 "Timer synchronization"
So the second 'chained' timer would count at 9MHz, and a channel's compare value would be the number of pulses to count, in your example 10 or 41. I haven't thought enough about this, but the timers can operate in 'one shot' modes as well as 'continuous' modes, so you might be able to use the channel's output pin to drive the LCD signal directly.
I would be tempted to set up two extra timers, one to generate the Vsync, and the other the Hsync.
(Full disclosure: I am not a member of LeafLabs staff.)
matsalleh
Member
Okay, thanks for all your information, I'll dig through libmaple and the manual tonight.
What I need to count, is the rising edge of the pulse. Eg, after 10, I digitalWrite(VSYNC, HIGH); to reset the scan position, or after 41, I digitalWrite(HSYNC, HIGH); to write the line...
Yes, when I talk about 'the pulse', I'm talking about a 50% duty 9MHz signal.
Ideally, I'd like to be able to call a function that produces the correct amount of pulses:
void (unsigned int i){
for(; i >= 0; --i)
pulse;
}
But I expect that would take far too many clock cycles to start/return the function, like you said...
Could using an external clock work?
I think that VSYNC and HSYNC are low enough frequency that I can use digitalWrite(); Providing I can interrupt the clock to do the write...
What's your next suggestion?
Thanks,
Chris.
gbulmer
Moderator
Yes, when I talk about 'the pulse', I'm talking about a 50% duty 9MHz signal.
Okay - too fast for interrupts. Better to use hardware timers, or poll in a very carefully written, carefully tested, very tight loop.
You could probably use digitalWrite for the sync signals, but there is quite a lot of latency (i.e. it is slow), though IIRC, the latency is consistent (deterministic). You might want to get an idea how slow by timing:
'for (int i=0; i<1000000;i++) { digitalWrite(...); }`
I can't imagine why I would do that unless I'd run out of timers.
A downside of doing pulses with digitalWrite is the program will suffer interrupts, but it (really the LCD) might not be very tolerant to interrupts. This can be hard to debug.
Sensitivity to interrupts can be a bit of a pain in the nether-regions. For example to use USB for debug messages, their are likely to be interrupts, which might *cause* new bugs. So a technique you might use to debug your code, might trigger new bugs which are not there when you aren't debugging it (a kind of Heisenberg uncertainty principle w.r.t. bugs :-)
I think I'd use timers as much as I could.
If timers were in short supply (because they are being used for other things), I'd either get a RET6 (and get more timers:-) or use a timer for the faster sync, or reprogram a timer on the fly and use it for either sync.
Could using an external clock work?
What kind of external clock? What jobs is it doing? Is it just standing in for a lack of free timers on the MCU, or is it doing something more?
If there is a ready-made chip that drives the LCD, that would be good.
matsalleh
Member
Hello,
Sorry for the late reply.
I've not actually looked at the datasheet yet, but it sounds as though I'll have enough timers.
I read the maple guide on timers, and it's terribly written. I don't understand it at all.
Can you give me some example code?
Thanks,
Chris.
You must log in to post.