SAMA5D4-EK LCDC: Change source clock to 2*Mck seems to solve stability issues

This commit is contained in:
Gregory Nutt 2014-07-12 09:45:05 -06:00
parent 253110bbf1
commit 8d1feb7a54
3 changed files with 100 additions and 62 deletions

View File

@ -2976,7 +2976,7 @@ int up_fbinitialize(void)
#if defined(BOARD_LCDC_ENABLE_DELAY) && BOARD_LCDC_ENABLE_DELAY > 0
/* Delay a bit after enabling the LDC. I presume that a delay of a few
* frame times allows some unstable clocking to synchronize before we
* tart thrashing the framebuffer? But I am not sure why this is
* start thrashing the framebuffer? But I am not sure why this is
* necessary and, in fact, is certainly not necessary in most LCDC
* configurations. Perhaps this delay would not be necessary if timings
* were more precise?

View File

@ -3836,17 +3836,9 @@ Configurations
SAMA5 ADC touchscreen controller and provides a more advance
graphics demo. It provides an interactive windowing experience.
This configuration is set up generally like the nsh configuration
except that:
NOTES:
- It boots into a graphic, window manage environment instead of
the serial console command line.
- The console command line is still available within NxConsole
windows.
- Obviously, the nx and touchscreen built in applications cannot
be supported.
The NxWM window manager is a tiny window manager tailored for use
1. The NxWM window manager is a tiny window manager tailored for use
with smaller LCDs but which is show here on the larger, SAMA5D4-EK
TM7000 LCD. It supports a toolchain, a start window, and
multiple application windows. However, to make the best use of
@ -3865,30 +3857,72 @@ Configurations
nuttx-git/NxWidgets/UnitTests/README.txt
Here is the quick summary of the build steps. These steps assume that
you have the entire NuttX GIT in some directory ~/nuttx-git. You may
have these components installed elsewhere. In that case, you will need
to adjust all of the paths in the following accordingly:
2. This configuration is set up generally like the nsh configuration
except that:
1. Install the nxwm configuration
- It boots into a graphic, window manage environment instead of
the serial console command line.
- The console command line is still available within NxConsole
windows.
- Obviously, the nx and touchscreen built in applications cannot
be supported.
3. NSH Console Access.
This configuration boots directly into a graphic, window manage
environment. There is no serial console. Some initial stdout
information will go to the USART3 serial output, but otherwise
the serial port will be silent.
Access to the NSH console is available in two ways:
a. The NxWM provides a graphics-based terminals (called NxConsoles);
The console command line is still available within NxConsole
windows once NxWM is up and running. The console input is still
via stdin (the host terminal window), but console output will go
to the NxConsole terminal.
NOTES:
i) Later I plan to integrate a USB keyboard so that the
console input will come from a keyboard attached to the
SAMA5D4-EK.
ii) It would also not be a difficult task to add a serial console
as part of the NxWM console. That is an option if a serial
console is really necessary but is not currently planned.
b. Telnet NSH sessions are still supported and this is, in general,
the convenient way to access the shell (and RAMLOG).
As with the NSH configuration, debug output will still go to the
circular RAMLOG buffer but cannot be accessed from a serial console.
Instead, you will need use the dmesg command from an NxConsole or
from a Telnet session to see the debug output
4. Here is the quick summary of the build steps. These steps assume
that you have the entire NuttX GIT in some directory ~/nuttx-git.
You may have these components installed elsewhere. In that case, you
will need to adjust all of the paths in the following accordingly:
a. Install the nxwm configuration
$ cd ~/nuttx-git/nuttx/tools
$ ./configure.sh sama5d4-ek/nxwm
2. Make the build context (only)
b. Make the build context (only)
$ cd ..
$ . ./setenv.sh
$ make context
...
NOTE: the use of the setenv.sh file is optional. All that it will
do is to adjust your PATH variable so that the build system can find
your tools. If you use it, you will most likely need to modify the
script so that it has the correct path to your tool binaries
directory.
NOTE: the use of the setenv.sh file is optional. All that it
will do is to adjust your PATH variable so that the build system
can find your tools. If you use it, you will most likely need to
modify the script so that it has the correct path to your tool
binary directory.
3. Install the nxwm unit test
c. Install the nxwm unit test
$ cd ~/nuttx-git/NxWidgets
$ tools/install.sh ~/nuttx-git/apps nxwm
@ -3896,29 +3930,31 @@ Configurations
- To ~/nuttx-git/NxWidgets/UnitTests/nxwm
- At ~/nuttx-git/apps/external
4. Build the NxWidgets library
d. Build the NxWidgets library
$ cd ~/nuttx-git/NxWidgets/libnxwidgets
$ make TOPDIR=~/nuttx-git/nuttx
...
5. Build the NxWM library
e. Build the NxWM library
$ cd ~/nuttx-git/NxWidgets/nxwm
$ make TOPDIR=~/nuttx-git/nuttx
...
6. Built NuttX with the installed unit test as the application
f. Built NuttX with the installed unit test as the application
$ cd ~/nuttx-git/nuttx
$ make
NOTE: The NxWM example was designed tiny displays. On this larger
800x480 display, the icons are too tiny to be usable. I have created
a larger 320x320 logo for the opening screen and added image scaling
to expand the images in the taskbar. The expanded images are not great.
The same problems exist in the application toolbar and in the start
window. These icons are not yet scaled.
5. The NxWM example was designed tiny displays. On this larger 800x480
display, the icons are too tiny to be usable. I have created a
larger 320x320 logo for the opening screen and added image scaling
to expand the images in the taskbar. The expanded images are not
great. The same problems exist in the application toolbar and in the
start window. These icons are not yet scaled.
I plan to correct these images in the very near future.
STATUS:
See the To-Do list below

View File

@ -183,7 +183,7 @@
#define BOARD_LCDC_OUTPUT_BPP 24 /* Output format to H/W is 24 bpp RGB888 */
#define BOARD_LCDC_WIDTH 800 /* Display width (pixels) */
#define BOARD_LCDC_HEIGHT 480 /* Display height (rows) */
#undef BOARD_LCDC_MCK_MUL2 /* Source clock is Mck (vs 2*Mck) */
#define BOARD_LCDC_MCK_MUL2 1 /* Source clock is 2*Mck (vs Mck) */
#define BOARD_LCDC_PIXCLK_INV 1 /* Invert pixel clock, use falling edge */
#define BOARD_LCDC_GUARDTIME 9 /* Guard time (frames) */
#define BOARD_LCDC_VSPW 2 /* Vertical pulse width (lines) */
@ -210,6 +210,8 @@
* necessary and, in fact, is certainly not necessary in other LCDC
* configurations. Perhaps the delay would not be necessary if timings were
* more precise?
*
* Delays are in units of microseconds.
*/
#define BOARD_LCDC_ENABLE_DELAY (50*1000)