6

I'm trying to use an unusual 16x2 LCD display with my Uno. As far as I know, it's an EA-X16027AR. It doesn't seem to be compatible with the HD44780 driver, which is typically used for Arduino LCD's.

According to the datasheet, the display's ENB (Enable) pin requires a clock input, described as follows:

Basical Clock to perform Instructions in Controller LSI. The Clock at the same timing as MPU are usually input.

The timing graphs elsewhere in the datasheet show it wants a speed of around 2 MHz.

Is it possible to get the internal clock signal from the Uno, scale it down to 2 MHz, and output it to a GPIO pin or similar? Alternatively, is it possible to emulate a clock signal at that speed on-board, without adding additional timing components?

Improve this question
1
  • 1
    I don't have time to write an answer, but you can use one of the timers and the output compare functionality to do anything from either full clock speed down or half clock speed down (can't recall which one). This requires bare metal usage of the timers though. – Cybergibbons Feb 21 '14 at 12:39
2

Rather than using microprocessor-specific low-level programming, I was able to get a suitable signal using the core tone() function:

tone(11, 2000000);

It can be used to generate a 50% duty cycle square wave of a custom frequency on any individual GPIO pin (I'm using 11 in this case). Given the name, it's obviously designed for producing simple audio output, and 2 MHz is way above the range of human hearing.

The documentation doesn't list any upper limit on the frequency though, and the code it's based on doesn't appear to introduce any limitations. With that said, it clearly can't run faster than the internal timer it's based on (which I think will typically be 8 or 16 MHz).

It seems reasonable to assume that it will be in-sync with the microprocessor's internal clock, although I haven't been able to confirm that empirically as I don't have suitable equipment at home. Similarly, I haven't been able to confirm that it's actually producing a 2 MHz signal, but the LCD display is working properly so it's likely to be in the right vicinity. I had previously tried running it from regular PWM, but that didn't work, so frequency is obviously important here.

The signal can be stopped by calling:

noTone(11);

There are a couple of caveats to be aware of when using tone(). First of all, it can only work on a single pin at a time, so you can't generate multiple signals with it. And secondly, it will prevent some PWM output from working properly (on pins 3 and 11, according to the documentation). This is because it has to reconfigure one of the internal timers which is normally used for PWM.

Improve this answer
4
  • The tone() command is using " microprocessor-specific low-level programming". It's just a wrapper that prevents you from learning how the MCU actually works. – Connor Wolf Feb 26 '14 at 7:01
  • @FakeName I'd argue that the core Arduino functions (like tone()) are an abstraction layer. In theory, they can be re-implemented under the surface to behave the same way on any microprocessor which supports the relevant features. By "low-level programming", I was referring more to things like directly manipulating special registers. That's definitely not portable, and is probably too advanced for a lot of the visitors we're likely to get here at Arduino.SE. – Peter Bloomfield Feb 26 '14 at 10:26
  • A wrapper is an abstraction layer. However, the Arduino abstraction layer tends to be dramatically slower, and is not much easier then dealing with the hardware directly. Personally (and this is IMHO), I think that while it's fine to use the arduino functions if you just want to throw something together, you should still read tha datasheet anyways. The hardware can do much more then is exposed by the abstraction layer, and you cannot really fully utilize it without dropping the intermediary entirely. – Connor Wolf Feb 26 '14 at 10:58
  • Basically, I look at the arduino wrappers like using GOTO, or any of a bunch of other programming structures that are easy to use, but lead to complex, hard-to-troubleshoot interactions as soon as you do anything complex. They're nice for hacking together small stuff, but poison for large or complex tasks, unless you understand in full what they're actually doing. – Connor Wolf Feb 26 '14 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.