Add support for a serial console on UART1 for the Open1788 board
This commit is contained in:
parent
2a58da6eb8
commit
f6e731ad50
@ -1,9 +1,9 @@
|
||||
README.txt
|
||||
==========
|
||||
|
||||
This README file discusses the port of NuttX to the WaveShare Open1788 board:
|
||||
See http://wvshare.com/product/Open1788-Standard.htm. This board features the
|
||||
NXP LPC1788 MCU
|
||||
This README file discusses the port of NuttX to the WaveShare Open1788 board:
|
||||
See http://wvshare.com/product/Open1788-Standard.htm. This board features the
|
||||
NXP LPC1788 MCU
|
||||
|
||||
CONTENTS
|
||||
========
|
||||
@ -11,6 +11,7 @@ CONTENTS
|
||||
o LEDs
|
||||
o Buttons
|
||||
o FPU
|
||||
o Serial Console
|
||||
o Using OpenOCD with the Olimex ARM-USB-OCD
|
||||
o Loading Code with the ISP Board
|
||||
o Configuration
|
||||
@ -18,141 +19,179 @@ CONTENTS
|
||||
LEDs
|
||||
====
|
||||
|
||||
The Open1788 base board has four user LEDs
|
||||
The Open1788 base board has four user LEDs
|
||||
|
||||
LED1 : Connected to P1[14]
|
||||
LED2 : Connected to P0[16]
|
||||
LED3 : Connected to P1[13]
|
||||
LED4 : Connected to P4[27]
|
||||
LED1 : Connected to P1[14]
|
||||
LED2 : Connected to P0[16]
|
||||
LED3 : Connected to P1[13]
|
||||
LED4 : Connected to P4[27]
|
||||
|
||||
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in
|
||||
any way using the defitions provided in the board.h header file.
|
||||
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in
|
||||
any way using the defitions provided in the board.h header file.
|
||||
|
||||
If CONFIG_ARCH_LEDs is defined, then NuttX will control the 3 LEDs on the
|
||||
WaveShare Open1788K. The following definitions describe how NuttX controls
|
||||
the LEDs:
|
||||
LED1 LED2 LED3 LED4
|
||||
LED_STARTED OFF OFF OFF OFF
|
||||
LED_HEAPALLOCATE ON OFF OFF OFF
|
||||
LED_IRQSENABLED OFF ON OFF OFF
|
||||
LED_STACKCREATED ON ON OFF OFF
|
||||
LED_INIRQ LED3 glows, on while in interupt
|
||||
LED_SIGNAL LED3 glows, on while in signal handler
|
||||
LED_ASSERTION LED3 glows, on while in assertion
|
||||
LED_PANIC LED3 Flashes at 2Hz
|
||||
LED_IDLE LED glows: ON while active; OFF while sleeping
|
||||
If CONFIG_ARCH_LEDs is defined, then NuttX will control the 3 LEDs on the
|
||||
WaveShare Open1788K. The following definitions describe how NuttX controls
|
||||
the LEDs:
|
||||
LED1 LED2 LED3 LED4
|
||||
LED_STARTED OFF OFF OFF OFF
|
||||
LED_HEAPALLOCATE ON OFF OFF OFF
|
||||
LED_IRQSENABLED OFF ON OFF OFF
|
||||
LED_STACKCREATED ON ON OFF OFF
|
||||
LED_INIRQ LED3 glows, on while in interupt
|
||||
LED_SIGNAL LED3 glows, on while in signal handler
|
||||
LED_ASSERTION LED3 glows, on while in assertion
|
||||
LED_PANIC LED3 Flashes at 2Hz
|
||||
LED_IDLE LED glows: ON while active; OFF while sleeping
|
||||
|
||||
Buttons
|
||||
=======
|
||||
|
||||
The Open1788K supports several buttons:
|
||||
The Open1788K supports several buttons:
|
||||
|
||||
USER1 : Connected to P4[26]
|
||||
USER2 : Connected to P2[22]
|
||||
USER3 : Connected to P0[10]
|
||||
USER1 : Connected to P4[26]
|
||||
USER2 : Connected to P2[22]
|
||||
USER3 : Connected to P0[10]
|
||||
|
||||
And a Joystick
|
||||
And a Joystick
|
||||
|
||||
JOY_A : Connected to P2[25]
|
||||
JOY_B : Connected to P2[26]
|
||||
JOY_C : Connected to P2[23]
|
||||
JOY_D : Connected to P2[19]
|
||||
JOY_CTR : Connected to P0[14]
|
||||
JOY_A : Connected to P2[25]
|
||||
JOY_B : Connected to P2[26]
|
||||
JOY_C : Connected to P2[23]
|
||||
JOY_D : Connected to P2[19]
|
||||
JOY_CTR : Connected to P0[14]
|
||||
|
||||
These can be accessed using the definitions and interfaces defined in the
|
||||
board.h header file.
|
||||
These can be accessed using the definitions and interfaces defined in the
|
||||
board.h header file.
|
||||
|
||||
FPU
|
||||
===
|
||||
|
||||
FPU Configuration Options
|
||||
-------------------------
|
||||
FPU Configuration Options
|
||||
-------------------------
|
||||
|
||||
There are two version of the FPU support built into the LPC17xx port.
|
||||
There are two version of the FPU support built into the LPC17xx port.
|
||||
|
||||
1. Lazy Floating Point Register Save.
|
||||
1. Lazy Floating Point Register Save.
|
||||
|
||||
This is an untested implementation that saves and restores FPU registers
|
||||
only on context switches. This means: (1) floating point registers are
|
||||
not stored on each context switch and, hence, possibly better interrupt
|
||||
performance. But, (2) since floating point registers are not saved,
|
||||
you cannot use floating point operations within interrupt handlers.
|
||||
This is an untested implementation that saves and restores FPU registers
|
||||
only on context switches. This means: (1) floating point registers are
|
||||
not stored on each context switch and, hence, possibly better interrupt
|
||||
performance. But, (2) since floating point registers are not saved,
|
||||
you cannot use floating point operations within interrupt handlers.
|
||||
|
||||
This logic can be enabled by simply adding the following to your .config
|
||||
file:
|
||||
This logic can be enabled by simply adding the following to your .config
|
||||
file:
|
||||
|
||||
CONFIG_ARCH_FPU=y
|
||||
CONFIG_ARCH_FPU=y
|
||||
|
||||
2. Non-Lazy Floating Point Register Save
|
||||
2. Non-Lazy Floating Point Register Save
|
||||
|
||||
Mike Smith has contributed an extensive re-write of the ARMv7-M exception
|
||||
handling logic. This includes verified support for the FPU. These changes
|
||||
have not yet been incorporated into the mainline and are still considered
|
||||
experimental. These FPU logic can be enabled with:
|
||||
Mike Smith has contributed an extensive re-write of the ARMv7-M exception
|
||||
handling logic. This includes verified support for the FPU. These changes
|
||||
have not yet been incorporated into the mainline and are still considered
|
||||
experimental. These FPU logic can be enabled with:
|
||||
|
||||
CONFIG_ARCH_FPU=y
|
||||
CONFIG_ARMV7M_CMNVECTOR=y
|
||||
CONFIG_ARCH_FPU=y
|
||||
CONFIG_ARMV7M_CMNVECTOR=y
|
||||
|
||||
You will probably also changes to the ld.script in if this option is selected.
|
||||
This should work:
|
||||
You will probably also changes to the ld.script in if this option is selected.
|
||||
This should work:
|
||||
|
||||
-ENTRY(_stext)
|
||||
+ENTRY(__start) /* Treat __start as the anchor for dead code stripping */
|
||||
+EXTERN(_vectors) /* Force the vectors to be included in the output */
|
||||
-ENTRY(_stext)
|
||||
+ENTRY(__start) /* Treat __start as the anchor for dead code stripping */
|
||||
+EXTERN(_vectors) /* Force the vectors to be included in the output */
|
||||
|
||||
CFLAGS
|
||||
------
|
||||
CFLAGS
|
||||
------
|
||||
|
||||
Only the Atollic toolchain has built-in support for the Cortex-M4 FPU. You will see
|
||||
the following lines in each Make.defs file:
|
||||
Only the Atollic toolchain has built-in support for the Cortex-M4 FPU. You will see
|
||||
the following lines in each Make.defs file:
|
||||
|
||||
ifeq ($(CONFIG_STM32_ATOLLIC_LITE),y)
|
||||
# Atollic toolchain under Windows
|
||||
...
|
||||
ifeq ($(CONFIG_ARCH_FPU),y)
|
||||
ARCHCPUFLAGS = -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard
|
||||
else
|
||||
ARCHCPUFLAGS = -mcpu=cortex-m3 -mthumb -mfloat-abi=soft
|
||||
endif
|
||||
endif
|
||||
|
||||
If you are using a toolchain other than the Atollic toolchain, then to use the FPU
|
||||
you will also have to modify the CFLAGS to enable compiler support for the ARMv7-M
|
||||
FPU. As of this writing, there are not many GCC toolchains that will support the
|
||||
ARMv7-M FPU.
|
||||
|
||||
As a minimum you will need to add CFLAG options to (1) enable hardware floating point
|
||||
code generation, and to (2) select the FPU implementation. You might try the same
|
||||
options as used with the Atollic toolchain in the Make.defs file:
|
||||
|
||||
ifeq ($(CONFIG_STM32_ATOLLIC_LITE),y)
|
||||
# Atollic toolchain under Windows
|
||||
...
|
||||
ifeq ($(CONFIG_ARCH_FPU),y)
|
||||
ARCHCPUFLAGS = -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard
|
||||
else
|
||||
ARCHCPUFLAGS = -mcpu=cortex-m3 -mthumb -mfloat-abi=soft
|
||||
endif
|
||||
endif
|
||||
|
||||
If you are using a toolchain other than the Atollic toolchain, then to use the FPU
|
||||
you will also have to modify the CFLAGS to enable compiler support for the ARMv7-M
|
||||
FPU. As of this writing, there are not many GCC toolchains that will support the
|
||||
ARMv7-M FPU.
|
||||
Configuration Changes
|
||||
---------------------
|
||||
|
||||
As a minimum you will need to add CFLAG options to (1) enable hardware floating point
|
||||
code generation, and to (2) select the FPU implementation. You might try the same
|
||||
options as used with the Atollic toolchain in the Make.defs file:
|
||||
Below are all of the configuration changes that I had to make to configs/stm3240g-eval/nsh2
|
||||
in order to successfully build NuttX using the Atollic toolchain WITH FPU support:
|
||||
|
||||
ARCHCPUFLAGS = -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard
|
||||
-CONFIG_ARCH_FPU=n : Enable FPU support
|
||||
+CONFIG_ARCH_FPU=y
|
||||
|
||||
Configuration Changes
|
||||
---------------------
|
||||
-CONFIG_STM32_CODESOURCERYW=y : Disable the CodeSourcery toolchain
|
||||
+CONFIG_STM32_CODESOURCERYW=n
|
||||
|
||||
Below are all of the configuration changes that I had to make to configs/stm3240g-eval/nsh2
|
||||
in order to successfully build NuttX using the Atollic toolchain WITH FPU support:
|
||||
-CONFIG_STM32_ATOLLIC_LITE=n : Enable *one* the Atollic toolchains
|
||||
CONFIG_STM32_ATOLLIC_PRO=n
|
||||
-CONFIG_STM32_ATOLLIC_LITE=y : The "Lite" version
|
||||
CONFIG_STM32_ATOLLIC_PRO=n : The "Pro" version
|
||||
|
||||
-CONFIG_ARCH_FPU=n : Enable FPU support
|
||||
+CONFIG_ARCH_FPU=y
|
||||
-CONFIG_INTELHEX_BINARY=y : Suppress generation FLASH download formats
|
||||
+CONFIG_INTELHEX_BINARY=n : (Only necessary with the "Lite" version)
|
||||
|
||||
-CONFIG_STM32_CODESOURCERYW=y : Disable the CodeSourcery toolchain
|
||||
+CONFIG_STM32_CODESOURCERYW=n
|
||||
-CONFIG_HAVE_CXX=y : Suppress generation of C++ code
|
||||
+CONFIG_HAVE_CXX=n : (Only necessary with the "Lite" version)
|
||||
|
||||
-CONFIG_STM32_ATOLLIC_LITE=n : Enable *one* the Atollic toolchains
|
||||
CONFIG_STM32_ATOLLIC_PRO=n
|
||||
-CONFIG_STM32_ATOLLIC_LITE=y : The "Lite" version
|
||||
CONFIG_STM32_ATOLLIC_PRO=n : The "Pro" version
|
||||
See the section above on Toolchains, NOTE 2, for explanations for some of
|
||||
the configuration settings. Some of the usual settings are just not supported
|
||||
by the "Lite" version of the Atollic toolchain.
|
||||
|
||||
-CONFIG_INTELHEX_BINARY=y : Suppress generation FLASH download formats
|
||||
+CONFIG_INTELHEX_BINARY=n : (Only necessary with the "Lite" version)
|
||||
Serial Console
|
||||
==============
|
||||
|
||||
-CONFIG_HAVE_CXX=y : Suppress generation of C++ code
|
||||
+CONFIG_HAVE_CXX=n : (Only necessary with the "Lite" version)
|
||||
By Default, UART0 is used as the serial console in all configurations. This
|
||||
may be connected to your computer via an external RS-232 driver or via the
|
||||
WaveShare USB ISP/VCOM module.
|
||||
|
||||
See the section above on Toolchains, NOTE 2, for explanations for some of
|
||||
the configuration settings. Some of the usual settings are just not supported
|
||||
by the "Lite" version of the Atollic toolchain.
|
||||
As an option, UART1 can also be used for the serial console by reconfiguring
|
||||
as follows:
|
||||
|
||||
System Type:
|
||||
CONFIG_LPC17_UART0=n : Disable UART0 if it is no longer used
|
||||
CONFIG_LPC17_UART1=y : Enable UART1
|
||||
|
||||
Drivers:
|
||||
CONFIG_UART1_SERIAL_CONSOLE=y : Setup up the UART1 configuration
|
||||
CONFIG_UART1_RXBUFSIZE=256
|
||||
CONFIG_UART1_TXBUFSIZE=256
|
||||
CONFIG_UART1_BAUD=115200
|
||||
CONFIG_UART1_BITS=8
|
||||
CONFIG_UART1_PARITY=0
|
||||
CONFIG_UART1_2STOP=0
|
||||
|
||||
In this configuration using UART1, it is necessary to disable LED support
|
||||
on the board. That is because UART1 RXD is set for pin p0.16, but so it
|
||||
LED2. If you do not disable LED support then no incoming serial data will
|
||||
be recevied.
|
||||
|
||||
Common Board Options
|
||||
CONFIG_ARCH_LEDS=n : Disable LED support
|
||||
|
||||
You should also remove the LED2 jumper so that the RXD input does not
|
||||
attempt to drive LED2 as well (this this does not seem to interfere with
|
||||
data receipt).
|
||||
|
||||
NOTE: If you intend to use LEDs, then you might want to redesign some of
|
||||
the LED logic in the src/ subdirectory so that it does not use LED2.
|
||||
|
||||
Using OpenOCD with the Olimex ARM-USB-OCD
|
||||
=========================================
|
||||
|
@ -219,7 +219,7 @@
|
||||
* any way. The following definitions are used to access individual LEDs.
|
||||
*
|
||||
* LED1 -- Connected to P1[14]
|
||||
* LED2 -- Connected to P0[16]
|
||||
* LED2 -- Connected to P0[16] (shared with UART1 RXD)
|
||||
* LED3 -- Connected to P1[13]
|
||||
* LED4 -- Connected to P4[27]
|
||||
*
|
||||
@ -310,6 +310,30 @@
|
||||
#define GPIO_UART0_TXD GPIO_UART0_TXD_2
|
||||
#define GPIO_UART0_RXD GPIO_UART0_RXD_2
|
||||
|
||||
/* UART1:
|
||||
*
|
||||
* All pin options are controlled by older briges on the bottom of the board. There
|
||||
* are the default settings on my board as it came out of the box:
|
||||
*
|
||||
* RTS --- Connected to P0[22]
|
||||
* RI --- Connected to P0[21]
|
||||
* DSR --- Connected to P0[19]
|
||||
* DCD --- Connected to P0[18]
|
||||
* CTS --- Connected to P0[17]
|
||||
* DTR --- Connected to P0[20]
|
||||
* TXD --- Connected to P0[15]
|
||||
* RXD --- Connected to P0[16] (Shared with LED2)
|
||||
*/
|
||||
|
||||
#define GPIO_UART1_RTS GPIO_UART1_RTS_2
|
||||
#define GPIO_UART1_RI GPIO_UART1_RI_1
|
||||
#define GPIO_UART1_DSR GPIO_UART1_DSR_1
|
||||
#define GPIO_UART1_DCD GPIO_UART1_DCD_1
|
||||
#define GPIO_UART1_CTS GPIO_UART1_CTS_1
|
||||
#define GPIO_UART1_DTR GPIO_UART1_DTR_1
|
||||
#define GPIO_UART1_TXD GPIO_UART1_TXD_1
|
||||
#define GPIO_UART1_RXD GPIO_UART1_RXD_1
|
||||
|
||||
/* MCI-SDIO:
|
||||
*
|
||||
* D0 --- Connected to P1[6]
|
||||
@ -371,14 +395,14 @@
|
||||
|
||||
/* LCD B:
|
||||
*
|
||||
* VD16 --- Connected to P0[8]
|
||||
* VD17 --- Connected to P0[9]
|
||||
* VD18 --- Connected to P2[12]
|
||||
* VD19 --- Connected to P2[13]
|
||||
* VD20 --- Connected to P1[26]
|
||||
* VD21 --- Connected to P1[27]
|
||||
* VD22 --- Connected to P1[28]
|
||||
* VD23 --- Connected to P1[29]
|
||||
* VD16 --- Connected to P0[8]
|
||||
* VD17 --- Connected to P0[9]
|
||||
* VD18 --- Connected to P2[12]
|
||||
* VD19 --- Connected to P2[13]
|
||||
* VD20 --- Connected to P1[26]
|
||||
* VD21 --- Connected to P1[27]
|
||||
* VD22 --- Connected to P1[28]
|
||||
* VD23 --- Connected to P1[29]
|
||||
*
|
||||
* DCLK --- Connected to P2[2]
|
||||
* LP --- Connected to P2[5]
|
||||
|
@ -132,7 +132,6 @@
|
||||
* Pins are configured as floating because there are pullups on the module.
|
||||
*/
|
||||
|
||||
#define GPIO_TC_PEN (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN15)
|
||||
#define GPIO_TC_PENIRQ (GPIO_INTBOTH | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN15)
|
||||
#define GPIO_TC_BUSY (GPIO_INPUT | GPIO_FLOAT | GPIO_PORT2 | GPIO_PIN14)
|
||||
#define GPIO_TC_CS (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT1 | GPIO_PIN8)
|
||||
|
Loading…
Reference in New Issue
Block a user