Documentation: migrate STM32F4
This commit is contained in:
raiden00pl
Alan Carvalho de Assis
parent
0953d0cbb5
commit
00db279c00
@ -1,5 +1,6 @@
|
|||||||
README
|
=======
|
||||||
======
|
Axoloti
|
||||||
|
=======
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the
|
This README discusses issues unique to NuttX configurations for the
|
||||||
Axoloti open source synthesizer board featuring the STM32F427IGH6
|
Axoloti open source synthesizer board featuring the STM32F427IGH6
|
||||||
@ -1,5 +1,6 @@
|
|||||||
README
|
=====================
|
||||||
======
|
Mikroe Clicker2 STM32
|
||||||
|
=====================
|
||||||
|
|
||||||
This is the README file for the port of NuttX to the Mikroe Clicker2 STM32
|
This is the README file for the port of NuttX to the Mikroe Clicker2 STM32
|
||||||
board based on the STMicro STM32F407VGT6 MCU.
|
board based on the STMicro STM32F407VGT6 MCU.
|
||||||
@ -9,18 +10,18 @@ README
|
|||||||
Contents
|
Contents
|
||||||
========
|
========
|
||||||
|
|
||||||
o Serial Console
|
- Serial Console
|
||||||
o LEDs
|
- LEDs
|
||||||
o Buttons
|
- Buttons
|
||||||
o Using JTAG
|
- Using JTAG
|
||||||
o Configurations
|
- Configurations
|
||||||
|
|
||||||
Serial Console
|
Serial Console
|
||||||
==============
|
==============
|
||||||
|
|
||||||
The are no RS-232 drivers on-board. An RS-232 Click board is available:
|
The are no RS-232 drivers on-board. An RS-232 Click board is available:
|
||||||
https://shop.mikroe.com/click/interface/rs232 or you can cannot an off-
|
https://shop.mikroe.com/click/interface/rs232 or you can cannot an off-
|
||||||
board TTL-to-RS-232 converter as follows:
|
board TTL-to-RS-232 converter as follows::
|
||||||
|
|
||||||
USART2: mikroBUS1 PD6/RX and PD5/TX
|
USART2: mikroBUS1 PD6/RX and PD5/TX
|
||||||
USART3: mikroBUS2 PD9/RX and PD8TX
|
USART3: mikroBUS2 PD9/RX and PD8TX
|
||||||
@ -34,7 +35,7 @@ Serial Console
|
|||||||
LEDs
|
LEDs
|
||||||
====
|
====
|
||||||
|
|
||||||
The Mikroe Clicker2 STM32 has two user controllable LEDs:
|
The Mikroe Clicker2 STM32 has two user controllable LEDs::
|
||||||
|
|
||||||
LD1/PE12, Active high output illuminates
|
LD1/PE12, Active high output illuminates
|
||||||
LD2/PE15, Active high output illuminates
|
LD2/PE15, Active high output illuminates
|
||||||
@ -44,18 +45,19 @@ LEDs
|
|||||||
board the Clicker2 for STM32. The following definitions describe how NuttX
|
board the Clicker2 for STM32. The following definitions describe how NuttX
|
||||||
controls the LEDs:
|
controls the LEDs:
|
||||||
|
|
||||||
SYMBOL Meaning LED state
|
=================== ======================= ======== ========
|
||||||
LD1 LD2
|
SYMBOL Meaning LD1 LD2
|
||||||
------------------- ----------------------- -------- --------
|
=================== ======================= ======== ========
|
||||||
LED_STARTED NuttX has been started OFF OFF
|
LED_STARTED NuttX has been started OFF OFF
|
||||||
LED_HEAPALLOCATE Heap has been allocated OFF OFF
|
LED_HEAPALLOCATE Heap has been allocated OFF OFF
|
||||||
LED_IRQSENABLED Interrupts enabled OFF OFF
|
LED_IRQSENABLED Interrupts enabled OFF OFF
|
||||||
LED_STACKCREATED Idle stack created ON OFF
|
LED_STACKCREATED Idle stack created ON OFF
|
||||||
LED_INIRQ In an interrupt N/C ON
|
LED_INIRQ In an interrupt N/C ON
|
||||||
LED_SIGNAL In a signal handler No change
|
LED_SIGNAL In a signal handler N/C N/C
|
||||||
LED_ASSERTION An assertion failed No change
|
LED_ASSERTION An assertion failed N/C N/C
|
||||||
LED_PANIC The system has crashed OFF Blinking
|
LED_PANIC The system has crashed OFF Blinking
|
||||||
LED_IDLE STM32 is is sleep mode Not used
|
LED_IDLE STM32 is is sleep mode N/U N/U
|
||||||
|
=================== ======================= ======== ========
|
||||||
|
|
||||||
Thus is LD1 is illuminated, the Clicker2 has completed boot-up. IF LD2
|
Thus is LD1 is illuminated, the Clicker2 has completed boot-up. IF LD2
|
||||||
is glowly softly, then interrupts are being taken; the level of illumination
|
is glowly softly, then interrupts are being taken; the level of illumination
|
||||||
@ -65,7 +67,7 @@ LEDs
|
|||||||
Buttons
|
Buttons
|
||||||
=======
|
=======
|
||||||
|
|
||||||
The Mikroe Clicker2 STM32 has two buttons available to software:
|
The Mikroe Clicker2 STM32 has two buttons available to software::
|
||||||
|
|
||||||
T2/E0, Low sensed when pressed
|
T2/E0, Low sensed when pressed
|
||||||
T3/PA10, Low sensed when pressed
|
T3/PA10, Low sensed when pressed
|
||||||
@ -90,7 +92,7 @@ Using JTAG
|
|||||||
NOTE that the FLASH probably has read protection enabled locked. You may
|
NOTE that the FLASH probably has read protection enabled locked. You may
|
||||||
need to follow the instructions at the second link to unlock it. You can
|
need to follow the instructions at the second link to unlock it. You can
|
||||||
also use the STM32 ST-Link CLI tool on Windows to remove the read protection
|
also use the STM32 ST-Link CLI tool on Windows to remove the read protection
|
||||||
using the -OB command:
|
using the -OB command::
|
||||||
|
|
||||||
$ ./ST-LINK_CLI.exe -c SN=53FF6F064966545035320387 SWD LPM
|
$ ./ST-LINK_CLI.exe -c SN=53FF6F064966545035320387 SWD LPM
|
||||||
STM32 ST-LINK CLI v2.3.0
|
STM32 ST-LINK CLI v2.3.0
|
||||||
@ -122,14 +124,18 @@ Using JTAG
|
|||||||
Option bytes updated successfully.
|
Option bytes updated successfully.
|
||||||
|
|
||||||
NOTE:
|
NOTE:
|
||||||
|
|
||||||
1. You can get the ST-Link Utilities here:
|
1. You can get the ST-Link Utilities here:
|
||||||
http://www.st.com/en/embedded-software/stsw-link004.html
|
http://www.st.com/en/embedded-software/stsw-link004.html
|
||||||
|
|
||||||
2. The ST-LINK Utility command line interface is located at:
|
2. The ST-LINK Utility command line interface is located at:
|
||||||
[Install_Directory]\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
|
[Install_Directory]\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
|
||||||
|
|
||||||
3. You can get a summary of all of the command options by running
|
3. You can get a summary of all of the command options by running
|
||||||
ST-LINK_CLI.exe with no arguments.
|
ST-LINK_CLI.exe with no arguments.
|
||||||
|
|
||||||
4. You can get the serial number of the ST-Link when from the information
|
4. You can get the serial number of the ST-Link when from the information
|
||||||
window if you connect via the ST-Link Utility:
|
window if you connect via the ST-Link Utility::
|
||||||
|
|
||||||
11:04:28 : ST-LINK SN : 53FF6F064966545035320387
|
11:04:28 : ST-LINK SN : 53FF6F064966545035320387
|
||||||
11:04:28 : ST-LINK Firmware version : V2J24S4
|
11:04:28 : ST-LINK Firmware version : V2J24S4
|
||||||
@ -157,8 +163,9 @@ Configurations
|
|||||||
|
|
||||||
Information Common to All Configurations
|
Information Common to All Configurations
|
||||||
----------------------------------------
|
----------------------------------------
|
||||||
|
|
||||||
Each Clicker2 configuration is maintained in a sub-directory and can be
|
Each Clicker2 configuration is maintained in a sub-directory and can be
|
||||||
selected as follow:
|
selected as follow::
|
||||||
|
|
||||||
tools/configure.sh clicker2-stm32:<subdir>
|
tools/configure.sh clicker2-stm32:<subdir>
|
||||||
|
|
||||||
@ -166,7 +173,7 @@ Configurations
|
|||||||
correct path to the directory than holds your toolchain binaries.
|
correct path to the directory than holds your toolchain binaries.
|
||||||
|
|
||||||
And then build NuttX by simply typing the following. At the conclusion of
|
And then build NuttX by simply typing the following. At the conclusion of
|
||||||
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.
|
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.::
|
||||||
|
|
||||||
make oldconfig
|
make oldconfig
|
||||||
make
|
make
|
||||||
@ -187,7 +194,7 @@ Configurations
|
|||||||
|
|
||||||
2. Unless stated otherwise, all configurations generate console
|
2. Unless stated otherwise, all configurations generate console
|
||||||
output on USART3, channel 0) as described above under "Serial
|
output on USART3, channel 0) as described above under "Serial
|
||||||
Console". The relevant configuration settings are listed below:
|
Console". The relevant configuration settings are listed below::
|
||||||
|
|
||||||
CONFIG_STM32_USART3=y
|
CONFIG_STM32_USART3=y
|
||||||
CONFIG_STM32_USART3_SERIALDRIVER=y
|
CONFIG_STM32_USART3_SERIALDRIVER=y
|
||||||
@ -212,23 +219,26 @@ Configurations
|
|||||||
That toolchain selection can easily be reconfigured using
|
That toolchain selection can easily be reconfigured using
|
||||||
'make menuconfig'. Here are the relevant current settings:
|
'make menuconfig'. Here are the relevant current settings:
|
||||||
|
|
||||||
Build Setup:
|
Build Setup::
|
||||||
|
|
||||||
CONFIG_HOST_LINUX =y : Linux environment
|
CONFIG_HOST_LINUX =y : Linux environment
|
||||||
|
|
||||||
System Type -> Toolchain:
|
System Type -> Toolchain::
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU ARM EABI toolchain
|
||||||
|
|
||||||
Configuration sub-directories
|
Configuration sub-directories
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
knsh:
|
|
||||||
|
knsh
|
||||||
|
----
|
||||||
|
|
||||||
This is identical to the nsh configuration below except that NuttX
|
This is identical to the nsh configuration below except that NuttX
|
||||||
is built as a protected mode, monolithic module and the user applications
|
is built as a protected mode, monolithic module and the user applications
|
||||||
are built separately.
|
are built separately.
|
||||||
|
|
||||||
It is recommends to use a special make command; not just 'make' but make
|
It is recommends to use a special make command; not just 'make' but make
|
||||||
with the following two arguments:
|
with the following two arguments::
|
||||||
|
|
||||||
make pass1 pass2
|
make pass1 pass2
|
||||||
|
|
||||||
@ -243,12 +253,14 @@ Configurations
|
|||||||
1. At the end of the build, there will be several files in the top-level
|
1. At the end of the build, there will be several files in the top-level
|
||||||
NuttX build directory:
|
NuttX build directory:
|
||||||
|
|
||||||
PASS1:
|
PASS1::
|
||||||
|
|
||||||
nuttx_user.elf - The pass1 user-space ELF file
|
nuttx_user.elf - The pass1 user-space ELF file
|
||||||
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
||||||
User.map - Symbols in the user-space ELF file
|
User.map - Symbols in the user-space ELF file
|
||||||
|
|
||||||
PASS2:
|
PASS2::
|
||||||
|
|
||||||
nuttx - The pass2 kernel-space ELF file
|
nuttx - The pass2 kernel-space ELF file
|
||||||
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
||||||
System.map - Symbols in the kernel-space ELF file
|
System.map - Symbols in the kernel-space ELF file
|
||||||
@ -262,7 +274,7 @@ Configurations
|
|||||||
files into a single .hex file. Here is how you can do that.
|
files into a single .hex file. Here is how you can do that.
|
||||||
|
|
||||||
a. The 'tail' of the nuttx.hex file should look something like this
|
a. The 'tail' of the nuttx.hex file should look something like this
|
||||||
(with my comments added):
|
(with my comments added)::
|
||||||
|
|
||||||
$ tail nuttx.hex
|
$ tail nuttx.hex
|
||||||
# 00, data records
|
# 00, data records
|
||||||
@ -278,7 +290,7 @@ Configurations
|
|||||||
Use an editor such as vi to remove the 05 and 01 records.
|
Use an editor such as vi to remove the 05 and 01 records.
|
||||||
|
|
||||||
b. The 'head' of the nuttx_user.hex file should look something like
|
b. The 'head' of the nuttx_user.hex file should look something like
|
||||||
this (again with my comments added):
|
this (again with my comments added)::
|
||||||
|
|
||||||
$ head nuttx_user.hex
|
$ head nuttx_user.hex
|
||||||
# 04, Extended Linear Address Record
|
# 04, Extended Linear Address Record
|
||||||
@ -293,7 +305,7 @@ Configurations
|
|||||||
be fine.
|
be fine.
|
||||||
|
|
||||||
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
||||||
file to produce a single combined hex file:
|
file to produce a single combined hex file::
|
||||||
|
|
||||||
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
||||||
|
|
||||||
@ -302,6 +314,7 @@ Configurations
|
|||||||
to develop a tool to automate these steps.
|
to develop a tool to automate these steps.
|
||||||
|
|
||||||
mrf24j40-mac
|
mrf24j40-mac
|
||||||
|
------------
|
||||||
|
|
||||||
This is a version of nsh that was used for testing the MRF24J40 MAC be
|
This is a version of nsh that was used for testing the MRF24J40 MAC be
|
||||||
as a character device. The most important configuration differences are
|
as a character device. The most important configuration differences are
|
||||||
@ -368,6 +381,7 @@ Configurations
|
|||||||
nsh> i8 /dev/ieee0 assoc
|
nsh> i8 /dev/ieee0 assoc
|
||||||
|
|
||||||
mrf24j40-6lowpan
|
mrf24j40-6lowpan
|
||||||
|
----------------
|
||||||
|
|
||||||
This is another version of nsh that is very similar to the mrf24j40-mac
|
This is another version of nsh that is very similar to the mrf24j40-mac
|
||||||
configuration but is focused on testing the IEEE 802.15.4 MAC
|
configuration but is focused on testing the IEEE 802.15.4 MAC
|
||||||
@ -401,7 +415,7 @@ Configurations
|
|||||||
configuration supports logging of debug output to a circular
|
configuration supports logging of debug output to a circular
|
||||||
buffer in RAM. This feature is discussed fully in this Wiki page:
|
buffer in RAM. This feature is discussed fully in this Wiki page:
|
||||||
https://cwiki.apache.org/confluence/display/NUTTX/SYSLOG . Relevant
|
https://cwiki.apache.org/confluence/display/NUTTX/SYSLOG . Relevant
|
||||||
configuration settings are summarized below:
|
configuration settings are summarized below::
|
||||||
|
|
||||||
Device Drivers:
|
Device Drivers:
|
||||||
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
|
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
|
||||||
@ -433,20 +447,20 @@ Configurations
|
|||||||
interface name 'wpan0'. This tells the i8sak app to use a socket
|
interface name 'wpan0'. This tells the i8sak app to use a socket
|
||||||
instead of a character device to perform the IOCTL operations with the
|
instead of a character device to perform the IOCTL operations with the
|
||||||
MAC. Additionally, after the PAN has been configured with the i8sak
|
MAC. Additionally, after the PAN has been configured with the i8sak
|
||||||
utility, you must explicitly bring the network up on each node:
|
utility, you must explicitly bring the network up on each node::
|
||||||
|
|
||||||
nsh> ifup wpan0
|
nsh> ifup wpan0
|
||||||
|
|
||||||
7. examples/udp is enabled. This will allow two MRF24J40 nodes to
|
7. examples/udp is enabled. This will allow two MRF24J40 nodes to
|
||||||
exchange UDP packets. Basic instructions:
|
exchange UDP packets. Basic instructions:
|
||||||
|
|
||||||
On the server node:
|
On the server node::
|
||||||
|
|
||||||
nsh> ifconfig
|
nsh> ifconfig
|
||||||
nsh> udpserver &
|
nsh> udpserver &
|
||||||
|
|
||||||
The ifconfig command will show the IP address of the server. Then on
|
The ifconfig command will show the IP address of the server. Then on
|
||||||
the client node use this IP address to start the client:
|
the client node use this IP address to start the client::
|
||||||
|
|
||||||
nsh> udpclient <server-ip> &
|
nsh> udpclient <server-ip> &
|
||||||
|
|
||||||
@ -455,7 +469,7 @@ Configurations
|
|||||||
other than by resetting the board.
|
other than by resetting the board.
|
||||||
|
|
||||||
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
||||||
run the UDP test (C=Coordinator; E=Endpoint):
|
run the UDP test (C=Coordinator; E=Endpoint)::
|
||||||
|
|
||||||
C: nsh> i8 wpan0 startpan cd:ab
|
C: nsh> i8 wpan0 startpan cd:ab
|
||||||
C: nsh> i8 acceptassoc
|
C: nsh> i8 acceptassoc
|
||||||
@ -472,13 +486,13 @@ Configurations
|
|||||||
8. examples/nettest is enabled. This will allow two MRF24J40 nodes to
|
8. examples/nettest is enabled. This will allow two MRF24J40 nodes to
|
||||||
exchange TCP packets. Basic instructions:
|
exchange TCP packets. Basic instructions:
|
||||||
|
|
||||||
On the server node:
|
On the server node::
|
||||||
|
|
||||||
nsh> ifconfig
|
nsh> ifconfig
|
||||||
nsh> tcpserver &
|
nsh> tcpserver &
|
||||||
|
|
||||||
The ifconfig command will show the IP address of the server. Then on
|
The ifconfig command will show the IP address of the server. Then on
|
||||||
the client node use this IP address to start the client:
|
the client node use this IP address to start the client::
|
||||||
|
|
||||||
nsh> tcpclient <server-ip> &
|
nsh> tcpclient <server-ip> &
|
||||||
|
|
||||||
@ -487,7 +501,7 @@ Configurations
|
|||||||
automatically when the packet exchange is complete.
|
automatically when the packet exchange is complete.
|
||||||
|
|
||||||
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
||||||
run the TCP test (C=Coordinator; E=Endpoint):
|
run the TCP test (C=Coordinator; E=Endpoint)::
|
||||||
|
|
||||||
C: nsh> i8 wpan0 startpan cd:ab
|
C: nsh> i8 wpan0 startpan cd:ab
|
||||||
C: nsh> i8 acceptassoc
|
C: nsh> i8 acceptassoc
|
||||||
@ -505,7 +519,7 @@ Configurations
|
|||||||
started automatically. Rather, it must be started AFTER the network
|
started automatically. Rather, it must be started AFTER the network
|
||||||
has been brought up using the NSH 'telnetd' command. You would want
|
has been brought up using the NSH 'telnetd' command. You would want
|
||||||
to start the Telent daemon only if you want the node to serve Telent
|
to start the Telent daemon only if you want the node to serve Telent
|
||||||
connections to an NSH shell on the node.
|
connections to an NSH shell on the node.::
|
||||||
|
|
||||||
nsh> ifconfig
|
nsh> ifconfig
|
||||||
nsh> telnetd
|
nsh> telnetd
|
||||||
@ -516,18 +530,18 @@ Configurations
|
|||||||
|
|
||||||
10. This configuration also includes the Telnet client program. This
|
10. This configuration also includes the Telnet client program. This
|
||||||
will allow you to execute a NSH one a node from the command line on
|
will allow you to execute a NSH one a node from the command line on
|
||||||
a different node. Like:
|
a different node. Like::
|
||||||
|
|
||||||
nsh> telnet <server-ip>
|
nsh> telnet <server-ip>
|
||||||
|
|
||||||
Where <server-ip> is the IP address of the server that you got for
|
Where <server-ip> is the IP address of the server that you got for
|
||||||
the ifconfig comma on the remote node. Once the telnet session
|
the ifconfig comma on the remote node. Once the telnet session
|
||||||
has been started, you can end the session with:
|
has been started, you can end the session with::
|
||||||
|
|
||||||
nsh> exit
|
nsh> exit
|
||||||
|
|
||||||
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
Cheat Sheet. Here is a concise summary of all all the steps needed to
|
||||||
run the TCP test (C=Coordinator; E=Endpoint):
|
run the TCP test (C=Coordinator; E=Endpoint)::
|
||||||
|
|
||||||
C: nsh> i8 wpan0 startpan
|
C: nsh> i8 wpan0 startpan
|
||||||
C: nsh> i8 acceptassoc
|
C: nsh> i8 acceptassoc
|
||||||
@ -562,11 +576,11 @@ Configurations
|
|||||||
support, Telnet worked just fine.
|
support, Telnet worked just fine.
|
||||||
|
|
||||||
Test Matrix:
|
Test Matrix:
|
||||||
The following configurations have been tested:
|
The following configurations have been tested::
|
||||||
|
|
||||||
TEST DATE
|
=========== ========== ==== ====
|
||||||
COMPRESSION ADDRESSING UDP TCP
|
COMPRESSION ADDRESSING UDP TCP
|
||||||
----------- ---------- ---- ----
|
=========== ========== ==== ====
|
||||||
hc06 short 6/21 6/25
|
hc06 short 6/21 6/25
|
||||||
extended 6/22 6/26
|
extended 6/22 6/26
|
||||||
hc1 short 6/23 6/26
|
hc1 short 6/23 6/26
|
||||||
@ -575,6 +589,7 @@ Configurations
|
|||||||
extended --- ---
|
extended --- ---
|
||||||
telnet short N/A 6/27 (hc06)
|
telnet short N/A 6/27 (hc06)
|
||||||
extended N/A ---
|
extended N/A ---
|
||||||
|
=========== ========== ==== ====
|
||||||
|
|
||||||
Other configuration options have not been specifically addressed
|
Other configuration options have not been specifically addressed
|
||||||
(such non-compressable ports, non-MAC based IPv6 addresses, etc.)
|
(such non-compressable ports, non-MAC based IPv6 addresses, etc.)
|
||||||
@ -586,6 +601,7 @@ Configurations
|
|||||||
incorrectly in compatible way on both the client and server sides.
|
incorrectly in compatible way on both the client and server sides.
|
||||||
|
|
||||||
mrf24j40-starhub and mrf24j40-starpoint
|
mrf24j40-starhub and mrf24j40-starpoint
|
||||||
|
----------------------------------------
|
||||||
|
|
||||||
These two configurations implement hub and and star endpoint in a
|
These two configurations implement hub and and star endpoint in a
|
||||||
star topology. Both configurations derive from the mrf24j40-6lowpan
|
star topology. Both configurations derive from the mrf24j40-6lowpan
|
||||||
@ -629,7 +645,7 @@ Configurations
|
|||||||
|
|
||||||
The modified usage of the TCP test is show below with E1 E2
|
The modified usage of the TCP test is show below with E1 E2
|
||||||
representing the two star endpoints and C: representing the
|
representing the two star endpoints and C: representing the
|
||||||
coordinator/hub.
|
coordinator/hub.::
|
||||||
|
|
||||||
C: nsh> i8 wpan0 startpan cd:ab
|
C: nsh> i8 wpan0 startpan cd:ab
|
||||||
C: nsh> i8 acceptassoc
|
C: nsh> i8 acceptassoc
|
||||||
@ -647,7 +663,7 @@ Configurations
|
|||||||
|
|
||||||
Where <server-ip> is the IP address of the E1 endpoint.
|
Where <server-ip> is the IP address of the E1 endpoint.
|
||||||
|
|
||||||
Similarly for the UDP test:
|
Similarly for the UDP test:::
|
||||||
|
|
||||||
E1: nsh> udpserver &
|
E1: nsh> udpserver &
|
||||||
E2: nsh> udpclient <server-ip> &
|
E2: nsh> udpclient <server-ip> &
|
||||||
@ -656,7 +672,7 @@ Configurations
|
|||||||
any debug output that you have selected.
|
any debug output that you have selected.
|
||||||
|
|
||||||
Telenet sessions may be initiated only from the hub to a star
|
Telenet sessions may be initiated only from the hub to a star
|
||||||
endpoint:
|
endpoint::
|
||||||
|
|
||||||
C: nsh> telnet <server-ip> <-- Runs the Telnet client
|
C: nsh> telnet <server-ip> <-- Runs the Telnet client
|
||||||
|
|
||||||
@ -696,7 +712,8 @@ Configurations
|
|||||||
incoming streams. The design was extended to support multiple
|
incoming streams. The design was extended to support multiple
|
||||||
reassembly buffers but have not yet been verified on this platform.
|
reassembly buffers but have not yet been verified on this platform.
|
||||||
|
|
||||||
nsh:
|
nsh
|
||||||
|
----
|
||||||
|
|
||||||
Configures the NuttShell (nsh) located at examples/nsh. This
|
Configures the NuttShell (nsh) located at examples/nsh. This
|
||||||
configuration is focused on low level, command-line driver testing. It
|
configuration is focused on low level, command-line driver testing. It
|
||||||
@ -706,23 +723,26 @@ Configurations
|
|||||||
|
|
||||||
1. Support for NSH built-in applications is provided:
|
1. Support for NSH built-in applications is provided:
|
||||||
|
|
||||||
Binary Formats:
|
Binary Formats::
|
||||||
|
|
||||||
CONFIG_BUILTIN=y : Enable support for built-in programs
|
CONFIG_BUILTIN=y : Enable support for built-in programs
|
||||||
|
|
||||||
Application Configuration:
|
Application Configuration::
|
||||||
|
|
||||||
CONFIG_NSH_BUILTIN_APPS=y : Enable starting apps from NSH command line
|
CONFIG_NSH_BUILTIN_APPS=y : Enable starting apps from NSH command line
|
||||||
|
|
||||||
No built applications are enabled in the base configuration, however.
|
No built applications are enabled in the base configuration, however.
|
||||||
|
|
||||||
2. C++ support for applications is enabled:
|
2. C++ support for applications is enabled::
|
||||||
|
|
||||||
CONFIG_HAVE_CXX=y
|
CONFIG_HAVE_CXX=y
|
||||||
CONFIG_HAVE_CXXINITIALIZE=y
|
CONFIG_HAVE_CXXINITIALIZE=y
|
||||||
|
|
||||||
usbnsh:
|
usbnsh
|
||||||
|
------
|
||||||
|
|
||||||
This is another NSH example. If differs from other 'nsh' configurations
|
This is another NSH example. If differs from other 'nsh' configurations
|
||||||
in that this configurations uses a USB serial device for console I/O.
|
n that this configurations uses a USB serial device for console I/O.
|
||||||
Such a configuration is useful on the Clicker2 STM32 which has no
|
Such a configuration is useful on the Clicker2 STM32 which has no
|
||||||
builtin RS-232 drivers.
|
builtin RS-232 drivers.
|
||||||
|
|
||||||
@ -736,7 +756,7 @@ Configurations
|
|||||||
re-established USB serial connection.
|
re-established USB serial connection.
|
||||||
|
|
||||||
2. This configuration does have USART3 output enabled and set up as
|
2. This configuration does have USART3 output enabled and set up as
|
||||||
the system logging device:
|
the system logging device::
|
||||||
|
|
||||||
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
|
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
|
||||||
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : USART3 will be /dev/ttyS0
|
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : USART3 will be /dev/ttyS0
|
||||||
@ -749,7 +769,7 @@ Configurations
|
|||||||
device will save encoded trace output in in-memory buffer; if the
|
device will save encoded trace output in in-memory buffer; if the
|
||||||
USB monitor is enabled, that trace buffer will be periodically
|
USB monitor is enabled, that trace buffer will be periodically
|
||||||
emptied and dumped to the system logging device (USART3 in this
|
emptied and dumped to the system logging device (USART3 in this
|
||||||
configuration):
|
configuration)::
|
||||||
|
|
||||||
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
|
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
|
||||||
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
|
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
|
||||||
@ -768,8 +788,9 @@ Configurations
|
|||||||
|
|
||||||
Using the Prolifics PL2303 Emulation
|
Using the Prolifics PL2303 Emulation
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
|
||||||
You could also use the non-standard PL2303 serial device instead of
|
You could also use the non-standard PL2303 serial device instead of
|
||||||
the standard CDC/ACM serial device by changing:
|
the standard CDC/ACM serial device by changing::
|
||||||
|
|
||||||
CONFIG_CDCACM=n : Disable the CDC/ACM serial device class
|
CONFIG_CDCACM=n : Disable the CDC/ACM serial device class
|
||||||
CONFIG_CDCACM_CONSOLE=n : The CDC/ACM serial device is NOT the console
|
CONFIG_CDCACM_CONSOLE=n : The CDC/ACM serial device is NOT the console
|
||||||
@ -0,0 +1,372 @@
|
|||||||
|
==============
|
||||||
|
mikroe-stm32f4
|
||||||
|
==============
|
||||||
|
|
||||||
|
This README discusses issues unique to NuttX configurations for the
|
||||||
|
MikroElektronika Mikromedia for STM32F4 development board. This is
|
||||||
|
another board support by NuttX that uses the same STM32F407VGT6 MCU
|
||||||
|
as does the STM32F4-Discovery board. This board, however, has very
|
||||||
|
different on-board peripherals than does the STM32F4-Discovery:
|
||||||
|
|
||||||
|
- TFT display with touch panel,
|
||||||
|
- VS1053 stereo audio codec with headphone jack,
|
||||||
|
- SD card slot,
|
||||||
|
- Serial FLASH memory,
|
||||||
|
- USB OTG FS with micro-AB connector, and
|
||||||
|
- Battery connect and batter charger circuit.
|
||||||
|
|
||||||
|
See the http://www.mikroe.com/mikromedia/stm32-m4/ for more information
|
||||||
|
about this board.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
====
|
||||||
|
|
||||||
|
The Mikroe-STM32F4 board has no user accessible LEDs onboard, only a power
|
||||||
|
and "charging" LED. All visual user output must be performed through the TFT
|
||||||
|
display.
|
||||||
|
|
||||||
|
External LEDs could be added via the expansion headers on the side of the
|
||||||
|
board, but as this would be a custom configuration, LEDs are not supported
|
||||||
|
in this port.
|
||||||
|
|
||||||
|
PWM
|
||||||
|
===
|
||||||
|
|
||||||
|
The Mikroe-STM32F4 has no real on-board PWM devices, but it does have PWM
|
||||||
|
pins routed to the expansion I/O headers on the side of the board.
|
||||||
|
|
||||||
|
UARTs
|
||||||
|
=====
|
||||||
|
|
||||||
|
The Mikroe-STM32F4 board has no onboard RS-232 line driver, however the
|
||||||
|
expansion I/O header provides access to USART2 on pins PD5/PD6. The port
|
||||||
|
includes support for USART2 configured as /dev/ttyS0.
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
========== =====
|
||||||
|
UART/USART PINS
|
||||||
|
========== =====
|
||||||
|
RX PD6
|
||||||
|
TX PD5
|
||||||
|
========== =====
|
||||||
|
|
||||||
|
Default USART/UART Configuration
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
USART2 is enabled in all configurations (see \*/defconfig). RX and TX are
|
||||||
|
configured on pins PD6 and PD5, respectively (see include/board.h).
|
||||||
|
|
||||||
|
Timer Inputs/Outputs
|
||||||
|
====================
|
||||||
|
|
||||||
|
::
|
||||||
|
TIM1
|
||||||
|
CH1 PA8, PE9
|
||||||
|
CH2 PA9[1], PE11
|
||||||
|
CH3 PA10[1], PE13
|
||||||
|
CH4 PA11[1], PE14
|
||||||
|
TIM2
|
||||||
|
CH1 PA0[1], PA15, PA5[1]
|
||||||
|
CH2 PA1, PB3[1]
|
||||||
|
CH3 PA2, PB10[1]
|
||||||
|
CH4 PA3, PB11
|
||||||
|
TIM3
|
||||||
|
CH1 PA6[1], PB4, PC6
|
||||||
|
CH2 PA7[1], PB5, PC7[1]
|
||||||
|
CH3 PB0, PC8
|
||||||
|
CH4 PB1, PC9
|
||||||
|
TIM4
|
||||||
|
CH1 PB6[1], PD12[1]
|
||||||
|
CH2 PB7, PD13[1]
|
||||||
|
CH3 PB8, PD14[1]
|
||||||
|
CH4 PB9[1], PD15[1]
|
||||||
|
TIM5
|
||||||
|
CH1 PA0[1], PH10[2]
|
||||||
|
CH2 PA1, PH11[2]
|
||||||
|
CH3 PA2, PH12[2]
|
||||||
|
CH4 PA3, PI0
|
||||||
|
TIM8
|
||||||
|
CH1 PC6, PI5
|
||||||
|
CH2 PC7[1], PI6
|
||||||
|
CH3 PC8, PI7
|
||||||
|
CH4 PC9, PI2
|
||||||
|
TIM9
|
||||||
|
CH1 PA2, PE5
|
||||||
|
CH2 PA3, PE6
|
||||||
|
TIM10
|
||||||
|
CH1 PB8, PF6
|
||||||
|
TIM11
|
||||||
|
CH1 PB9[1], PF7
|
||||||
|
TIM12
|
||||||
|
CH1 PH6[2], PB14
|
||||||
|
CH2 PC15, PH9[2]
|
||||||
|
TIM13
|
||||||
|
CH1 PA6[1], PF8
|
||||||
|
TIM14
|
||||||
|
CH1 PA7[1], PF9
|
||||||
|
|
||||||
|
[1] Indicates pins that have other on-board functions and should be used only
|
||||||
|
with care (See table 5 in the Mikroe-STM32F4 User Guide). The rest are
|
||||||
|
free I/O pins.
|
||||||
|
[2] Port H pins are not supported by the MCU
|
||||||
|
|
||||||
|
MIO283QT-2/MIO283QT-9A
|
||||||
|
======================
|
||||||
|
|
||||||
|
The original Mikroe-SMT32F4 board as an on-board MIO283QT-2 TFT LCD that can
|
||||||
|
be configured and used. This is a 320x240 resolution display with color
|
||||||
|
capability to 262K colors, though the mio283qt-2 driver in NuttX only
|
||||||
|
supports 16-bit color depth, or 65K colors. Changes to both the
|
||||||
|
mio283qt-2 driver and the driver interface layer would need to be made
|
||||||
|
to support 24 BPP mode.
|
||||||
|
|
||||||
|
UPDATE: New boards now support a MIO283QT-9A TFT LCD that is not compatible
|
||||||
|
with the MIO283QT-2. It uses a different LCD controller. The default in
|
||||||
|
all of these configurations is the MIO283QT-2. But MIO283QT-9A is also
|
||||||
|
supported and you can switch from the MIO283QT-2 to the MIO283QT-9A by simply
|
||||||
|
modifying the NuttX configuration
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
Each Mikroe-STM32F4 configuration is maintained in a sub-directory and
|
||||||
|
can be selected as follow::
|
||||||
|
|
||||||
|
tools/configure.sh mikroe-stm32f4:<subdir>
|
||||||
|
|
||||||
|
If this is a Windows native build, then configure.bat should be used
|
||||||
|
instead of configure.sh::
|
||||||
|
|
||||||
|
configure.bat Mikroe-STM32F4\<subdir>
|
||||||
|
|
||||||
|
Where <subdir> is one of the following:
|
||||||
|
|
||||||
|
fulldemo
|
||||||
|
--------
|
||||||
|
|
||||||
|
This is an example that includes an NSH shell over USB that also
|
||||||
|
enables all features of the Mikroe-STM32F4 board including the LCD,
|
||||||
|
on-board 1M Flash with SMART filesystem, Aux RS-232 serial port on the
|
||||||
|
expansion header, etc. A couple of the NX graphics commands are made
|
||||||
|
available via the NSH prompt for performing LCD demonstrations, and the
|
||||||
|
nximage example is used as a splash-screen at startup.
|
||||||
|
|
||||||
|
kostest
|
||||||
|
-------
|
||||||
|
|
||||||
|
NOTE: This configuration compiles, but has not been fully tested
|
||||||
|
on the hardware yet.
|
||||||
|
|
||||||
|
This configuration directory, performs a simple OS test using
|
||||||
|
apps/examples/ostest with NuttX build as a kernel-mode monolithic
|
||||||
|
module and the user applications are built separately. Is
|
||||||
|
is recommended to use a special make command; not just 'make' but
|
||||||
|
make with the following two arguments::
|
||||||
|
|
||||||
|
make pass1 pass2
|
||||||
|
|
||||||
|
In the normal case (just 'make'), make will attempt to build both user-
|
||||||
|
and kernel-mode blobs more or less interleaved. This actual works!
|
||||||
|
However, for me it is very confusing so I prefer the above make command:
|
||||||
|
Make the user-space binaries first (pass1), then make the kernel-space
|
||||||
|
binaries (pass2)
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. This is the default platform/toolchain in the configuration::
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y : Windows
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
|
||||||
|
This is easily changed by modifying the configuration.
|
||||||
|
|
||||||
|
3. At the end of the build, there will be several files in the top-level
|
||||||
|
NuttX build directory::
|
||||||
|
|
||||||
|
PASS1:
|
||||||
|
nuttx_user.elf - The pass1 user-space ELF file
|
||||||
|
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
||||||
|
User.map - Symbols in the user-space ELF file
|
||||||
|
|
||||||
|
PASS2:
|
||||||
|
nuttx - The pass2 kernel-space ELF file
|
||||||
|
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
||||||
|
System.map - Symbols in the kernel-space ELF file
|
||||||
|
|
||||||
|
4. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
|
||||||
|
load the .hex files into FLASH, then you need to combine the two hex
|
||||||
|
files into a single .hex file. Here is how you can do that.
|
||||||
|
|
||||||
|
a. The 'tail' of the nuttx.hex file should look something like this
|
||||||
|
(with my comments added)::
|
||||||
|
|
||||||
|
$ tail nuttx.hex
|
||||||
|
# 00, data records
|
||||||
|
...
|
||||||
|
:10 9DC0 00 01000000000800006400020100001F0004
|
||||||
|
:10 9DD0 00 3B005A0078009700B500D400F300110151
|
||||||
|
:08 9DE0 00 30014E016D0100008D
|
||||||
|
# 05, Start Linear Address Record
|
||||||
|
:04 0000 05 0800 0419 D2
|
||||||
|
# 01, End Of File record
|
||||||
|
:00 0000 01 FF
|
||||||
|
|
||||||
|
Use an editor such as vi to remove the 05 and 01 records.
|
||||||
|
|
||||||
|
b. The 'head' of the nuttx_user.hex file should look something like
|
||||||
|
this (again with my comments added)::
|
||||||
|
|
||||||
|
$ head nuttx_user.hex
|
||||||
|
# 04, Extended Linear Address Record
|
||||||
|
:02 0000 04 0801 F1
|
||||||
|
# 00, data records
|
||||||
|
:10 8000 00 BD89 01084C800108C8110208D01102087E
|
||||||
|
:10 8010 00 0010 00201C1000201C1000203C16002026
|
||||||
|
:10 8020 00 4D80 01085D80010869800108ED83010829
|
||||||
|
...
|
||||||
|
|
||||||
|
Nothing needs to be done here. The nuttx_user.hex file should
|
||||||
|
be fine.
|
||||||
|
|
||||||
|
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
||||||
|
file to produce a single combined hex file::
|
||||||
|
|
||||||
|
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
||||||
|
|
||||||
|
Then use the combined.hex file with the STM32 ST-Link tool. If
|
||||||
|
you do this a lot, you will probably want to invest a little time
|
||||||
|
to develop a tool to automate these steps.
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
This is an NSH example that uses USART2 as the console. Note that
|
||||||
|
the Mikroe-STM32F4 board doesn't actually have onboard line drivers
|
||||||
|
or a connector for USART2, but it does route the USART2 signals to
|
||||||
|
the expansion header. To use this demo, you would need to connect
|
||||||
|
an external 3.3V RS-232 line driver to the USART's I/O lines on the
|
||||||
|
expansion header.
|
||||||
|
|
||||||
|
NOTE: This demo doesn't quite work yet. I can get output to the
|
||||||
|
USART, but so far, I have not gotten nsh to actually come up.
|
||||||
|
|
||||||
|
nx
|
||||||
|
--
|
||||||
|
|
||||||
|
An example using the NuttX graphics system (NX). This example
|
||||||
|
focuses on general window controls, movement, mouse and keyboard
|
||||||
|
input.::
|
||||||
|
|
||||||
|
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
|
||||||
|
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
|
||||||
|
|
||||||
|
You can the newer MIO283QT-9A by enabling it in the configuration.::
|
||||||
|
|
||||||
|
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
|
||||||
|
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
|
||||||
|
|
||||||
|
nxlines
|
||||||
|
-------
|
||||||
|
|
||||||
|
An example using the NuttX graphics system (NX). This example focuses on
|
||||||
|
placing lines on the background in various orientations using the
|
||||||
|
on-board TFT LCD.::
|
||||||
|
|
||||||
|
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
|
||||||
|
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
|
||||||
|
|
||||||
|
You can the newer MIO283QT-9A by enabling it in the configuration.::
|
||||||
|
|
||||||
|
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
|
||||||
|
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
|
||||||
|
|
||||||
|
nxtext
|
||||||
|
------
|
||||||
|
|
||||||
|
Another example using the NuttX graphics system (NX). This
|
||||||
|
example focuses on placing text on the background while pop-up
|
||||||
|
windows occur. Text should continue to update normally with
|
||||||
|
or without the popup windows present.
|
||||||
|
|
||||||
|
usbnsh
|
||||||
|
-------
|
||||||
|
|
||||||
|
This is another NSH example. If differs from other 'nsh' configurations
|
||||||
|
in that this configurations uses a USB serial device for console I/O.
|
||||||
|
Such a configuration is useful on the stm32f4discovery which has no
|
||||||
|
builtin RS-232 drivers.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. By default, this configuration uses the ARM EABI toolchain
|
||||||
|
for Windows and builds under Cygwin (or probably MSYS). That
|
||||||
|
can easily be reconfigured, of course.::
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y : Builds under Windows
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
|
||||||
|
3. This configuration does have UART2 output enabled and set up as
|
||||||
|
the system logging device::
|
||||||
|
|
||||||
|
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
|
||||||
|
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : UART2 will be /dev/ttyS0
|
||||||
|
|
||||||
|
However, there is nothing to generate SYSLOG output in the default
|
||||||
|
configuration so nothing should appear on UART2 unless you enable
|
||||||
|
some debug output or enable the USB monitor.
|
||||||
|
|
||||||
|
4. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
|
||||||
|
device will save encoded trace output in in-memory buffer; if the
|
||||||
|
USB monitor is enabled, that trace buffer will be periodically
|
||||||
|
emptied and dumped to the system logging device (UART2 in this
|
||||||
|
configuration)::
|
||||||
|
|
||||||
|
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
|
||||||
|
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
|
||||||
|
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
|
||||||
|
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
|
||||||
|
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
|
||||||
|
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
|
||||||
|
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
|
||||||
|
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
|
||||||
|
|
||||||
|
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
|
||||||
|
CONFIG_USBMONITOR_TRACECLASS=y
|
||||||
|
CONFIG_USBMONITOR_TRACETRANSFERS=y
|
||||||
|
CONFIG_USBMONITOR_TRACECONTROLLER=y
|
||||||
|
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
|
||||||
|
|
||||||
|
5. By default, this project assumes that you are *NOT* using the DFU bootloader.
|
||||||
|
|
||||||
|
Using the Prolifics PL2303 Emulation
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
You could also use the non-standard PL2303 serial device instead of
|
||||||
|
the standard CDC/ACM serial device by changing::
|
||||||
|
|
||||||
|
CONFIG_CDCACM=y : Disable the CDC/ACM serial device class
|
||||||
|
CONFIG_CDCACM_CONSOLE=y : The CDC/ACM serial device is NOT the console
|
||||||
|
CONFIG_PL2303=y : The Prolifics PL2303 emulation is enabled
|
||||||
|
CONFIG_PL2303_CONSOLE=y : The PL2303 serial device is the console
|
||||||
@ -0,0 +1,394 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F401RE
|
||||||
|
================
|
||||||
|
|
||||||
|
This page discusses issues unique to NuttX configurations for the ST
|
||||||
|
NucleoF401RE and NucleoF411RE boards from ST Micro. See
|
||||||
|
|
||||||
|
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
|
||||||
|
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
|
||||||
|
|
||||||
|
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
|
||||||
|
Line" parts but differing in the specific STM32 chip mounted on board. The
|
||||||
|
chips themselves are also very similar with the STM32F411RE having some
|
||||||
|
additional capability:
|
||||||
|
|
||||||
|
NucleoF401RE:
|
||||||
|
|
||||||
|
- Microprocessor: 32-bit ARM Cortex M4 at 84MHz STM32F104RE
|
||||||
|
- Memory: 512 KB Flash and 96 KB SRAM
|
||||||
|
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
||||||
|
- DMA: 16-stream DMA controllers with FIFOs and burst support
|
||||||
|
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
||||||
|
watchdog timers, and a SysTick timer
|
||||||
|
- GPIO: Up to 81 I/O ports with interrupt capability
|
||||||
|
- I2C: Up to 3 × I2C interfaces
|
||||||
|
- USARTs: Up to 3 USARTs
|
||||||
|
- SPIs: Up to 4 SPIs (2 I2S)
|
||||||
|
- SDIO interface
|
||||||
|
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
||||||
|
- CRC calculation unit
|
||||||
|
- RTC
|
||||||
|
|
||||||
|
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
|
||||||
|
|
||||||
|
Board features, however, are identical:
|
||||||
|
|
||||||
|
- Peripherals: 1 led, 1 push button
|
||||||
|
- Debug: Serial wire debug and JTAG interfaces
|
||||||
|
- Expansion I/F Ardino and Morpho Headers
|
||||||
|
|
||||||
|
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
||||||
|
OpenOcd FTDI function - USB to JTAG front-end.
|
||||||
|
|
||||||
|
See http://mbed.org/platforms/ST-Nucleo-F401RE and
|
||||||
|
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
|
||||||
|
information about these boards.
|
||||||
|
|
||||||
|
mbed
|
||||||
|
====
|
||||||
|
|
||||||
|
The Nucleo-F401RE includes boot loader from mbed:
|
||||||
|
|
||||||
|
https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
https://mbed.org/handbook/Homepage
|
||||||
|
|
||||||
|
Using the mbed loader:
|
||||||
|
|
||||||
|
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
|
||||||
|
2. A new file system will appear called NUCLEO; open it with Windows
|
||||||
|
Explorer (assuming that you are using Windows).
|
||||||
|
3. Drag and drop nuttx.bin into the MBED window. This will load the
|
||||||
|
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
|
||||||
|
close then re-open and the Nucleo-F4x1RE will be running the new code.
|
||||||
|
|
||||||
|
Hardware
|
||||||
|
========
|
||||||
|
|
||||||
|
GPIO
|
||||||
|
----
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
SERIAL_TX=PA_2 USER_BUTTON=PC_13
|
||||||
|
SERIAL_RX=PA_3 LED1 =PA_5
|
||||||
|
|
||||||
|
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
|
||||||
|
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
|
||||||
|
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
|
||||||
|
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
|
||||||
|
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
|
||||||
|
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
|
||||||
|
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
|
||||||
|
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
|
||||||
|
|
||||||
|
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
|
||||||
|
Buttons
|
||||||
|
-------
|
||||||
|
|
||||||
|
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
----
|
||||||
|
|
||||||
|
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
|
||||||
|
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
||||||
|
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
||||||
|
|
||||||
|
- When the I/O is HIGH value, the LED is on.
|
||||||
|
- When the I/O is LOW, the LED is off.
|
||||||
|
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows when the red LED (PE24) is available:
|
||||||
|
|
||||||
|
=================== ======================= ===========
|
||||||
|
SYMBOL Meaning LD2
|
||||||
|
=================== ======================= ===========
|
||||||
|
LED_STARTED NuttX has been started OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled OFF
|
||||||
|
LED_STACKCREATED Idle stack created ON
|
||||||
|
LED_INIRQ In an interrupt No change
|
||||||
|
LED_SIGNAL In a signal handler No change
|
||||||
|
LED_ASSERTION An assertion failed No change
|
||||||
|
LED_PANIC The system has crashed Blinking
|
||||||
|
LED_IDLE MCU is is sleep mode Not used
|
||||||
|
=================== ======================= ===========
|
||||||
|
|
||||||
|
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
||||||
|
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
||||||
|
has been detected and the system has halted.
|
||||||
|
|
||||||
|
Serial Consoles
|
||||||
|
===============
|
||||||
|
|
||||||
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA11 CN10 pin 14
|
||||||
|
PB7 CN7 pin 21
|
||||||
|
TXD: PA10 CN9 pin 3, CN10 pin 33
|
||||||
|
PB6 CN5 pin 3, CN10 pin 17
|
||||||
|
|
||||||
|
NOTE: You may need to edit the include/board.h to select different USART1
|
||||||
|
pin selections.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
To configure USART1 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART1=y
|
||||||
|
CONFIG_USART1_SERIALDRIVER=y
|
||||||
|
CONFIG_USART1_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART1_RXBUFSIZE=256
|
||||||
|
CONFIG_USART1_TXBUFSIZE=256
|
||||||
|
CONFIG_USART1_BAUD=115200
|
||||||
|
CONFIG_USART1_BITS=8
|
||||||
|
CONFIG_USART1_PARITY=0
|
||||||
|
CONFIG_USART1_2STOP=0
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
||||||
|
PD6
|
||||||
|
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
||||||
|
PD5
|
||||||
|
|
||||||
|
UART2 is the default in all of these configurations.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 2 PA2 USART2_TX some RS-232 converters
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
||||||
|
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
||||||
|
as USART signals. Thus SB13 and SB14 should be OFF.
|
||||||
|
|
||||||
|
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
disconnected to PA3 and PA2 on STM32 MCU.
|
||||||
|
|
||||||
|
To configure USART2 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART2=y
|
||||||
|
CONFIG_USART2_SERIALDRIVER=y
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART2_RXBUFSIZE=256
|
||||||
|
CONFIG_USART2_TXBUFSIZE=256
|
||||||
|
CONFIG_USART2_BAUD=115200
|
||||||
|
CONFIG_USART2_BITS=8
|
||||||
|
CONFIG_USART2_PARITY=0
|
||||||
|
CONFIG_USART2_2STOP=0
|
||||||
|
|
||||||
|
USART6
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PC7 CN5 pin2, CN10 pin 19
|
||||||
|
PA12 CN10, pin 12
|
||||||
|
TXD: PC6 CN10, pin 4
|
||||||
|
PA11 CN10, pin 14
|
||||||
|
|
||||||
|
To configure USART6 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART6=y
|
||||||
|
CONFIG_USART6_SERIALDRIVER=y
|
||||||
|
CONFIG_USART6_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART6_RXBUFSIZE=256
|
||||||
|
CONFIG_USART6_TXBUFSIZE=256
|
||||||
|
CONFIG_USART6_BAUD=115200
|
||||||
|
CONFIG_USART6_BITS=8
|
||||||
|
CONFIG_USART6_PARITY=0
|
||||||
|
CONFIG_USART6_2STOP=0
|
||||||
|
|
||||||
|
Virtual COM Port
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Yet another option is to use UART2 and the USB virtual COM port. This
|
||||||
|
option may be more convenient for long term development, but is painful
|
||||||
|
to use during board bring-up.
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
||||||
|
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
||||||
|
connector CN10.
|
||||||
|
|
||||||
|
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
||||||
|
between them. Thus SB61, SB62 and SB63 should be OFF.
|
||||||
|
|
||||||
|
Configuring USART2 is the same as given above.
|
||||||
|
|
||||||
|
Question: What BAUD should be configure to interface with the Virtual
|
||||||
|
COM port? 115200 8N1?
|
||||||
|
|
||||||
|
Default
|
||||||
|
-------
|
||||||
|
|
||||||
|
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
||||||
|
virtual COM port is enabled.
|
||||||
|
|
||||||
|
Shields
|
||||||
|
=======
|
||||||
|
|
||||||
|
RS-232 from Cutedigi.com
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Supports a single RS-232 connected via::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE Cutedigi
|
||||||
|
----------- ------------ --------
|
||||||
|
Pin 1 PA3 USART2_RX RXD
|
||||||
|
Pin 2 PA2 USART2_TX TXD
|
||||||
|
|
||||||
|
Support for this shield is enabled by selecting USART2 and configuring
|
||||||
|
SB13, 14, 62, and 63 as described above under "Serial Consoles"
|
||||||
|
|
||||||
|
Itead Joystick Shield
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
See http://imall.iteadstudio.com/im120417014.html for more information
|
||||||
|
about this joystick.
|
||||||
|
|
||||||
|
Itead Joystick Connection::
|
||||||
|
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
ARDUINO ITEAD NUCLEO-F4x1
|
||||||
|
PIN NAME SIGNAL SIGNAL
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
D3 Button E Output PB3
|
||||||
|
D4 Button D Output PB5
|
||||||
|
D5 Button C Output PB4
|
||||||
|
D6 Button B Output PB10
|
||||||
|
D7 Button A Output PA8
|
||||||
|
D8 Button F Output PA9
|
||||||
|
D9 Button G Output PC7
|
||||||
|
A0 Joystick Y Output PA0 ADC1_0
|
||||||
|
A1 Joystick X Output PA1 ADC1_1
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
|
||||||
|
All buttons are pulled on the shield. A sensed low value indicates
|
||||||
|
when the button is pressed.
|
||||||
|
|
||||||
|
NOTE: Button F cannot be used with the default USART1 configuration
|
||||||
|
because PA9 is configured for USART1_RX by default. Use select
|
||||||
|
different USART1 pins in the board.h file or select a different
|
||||||
|
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
|
||||||
|
eliminate all but buttons A, B, and C.
|
||||||
|
|
||||||
|
Itead Joystick Signal interpretation::
|
||||||
|
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
BUTTON TYPE NUTTX ALIAS
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
Button A Large button A JUMP/BUTTON 3
|
||||||
|
Button B Large button B FIRE/BUTTON 2
|
||||||
|
Button C Joystick select button SELECT/BUTTON 1
|
||||||
|
Button D Tiny Button D BUTTON 6
|
||||||
|
Button E Tiny Button E BUTTON 7
|
||||||
|
Button F Large Button F BUTTON 4
|
||||||
|
Button G Large Button G BUTTON 5
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
|
||||||
|
Itead Joystick configuration settings::
|
||||||
|
|
||||||
|
System Type -> STM32 Peripheral Support
|
||||||
|
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
|
||||||
|
|
||||||
|
Drivers
|
||||||
|
CONFIG_ANALOG=y : Should be automatically selected
|
||||||
|
CONFIG_ADC=y : Should be automatically selected
|
||||||
|
CONFIG_INPUT=y : Select input device support
|
||||||
|
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
|
||||||
|
|
||||||
|
There is nothing in the configuration that currently uses the joystick.
|
||||||
|
For testing, you can add the following configuration options to enable the
|
||||||
|
analog joystick example at apps/examples/ajoystick::
|
||||||
|
|
||||||
|
CONFIG_NSH_ARCHINIT=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
|
||||||
|
2014-12-04:
|
||||||
|
|
||||||
|
- Without ADC DMA support, it is not possible to sample both X and Y
|
||||||
|
with a single ADC. Right now, only one axis is being converted.
|
||||||
|
|
||||||
|
- There is conflicts with some of the Arduino data pins and the
|
||||||
|
default USART1 configuration. I am currently running with USART1
|
||||||
|
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
|
||||||
|
conflict.
|
||||||
|
|
||||||
|
- Current showstopper: I appear to be getting infinite interrupts as
|
||||||
|
soon as joystick button interrupts are enabled.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
f401-nsh:
|
||||||
|
---------
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
||||||
|
Nucleo-F401RE board. The Configuration enables the serial interfaces
|
||||||
|
on UART2. Support for builtin applications is enabled, but in the base
|
||||||
|
configuration no builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. By default, this configuration uses the ARM EABI toolchain
|
||||||
|
for Linux. That can easily be reconfigured, of course.:
|
||||||
|
|
||||||
|
CONFIG_HOST_LINUX=y : Builds under Linux
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
|
||||||
|
|
||||||
|
3. Although the default console is USART2 (which would correspond to
|
||||||
|
the Virtual COM port) I have done all testing with the console
|
||||||
|
device configured for USART1 (see instruction above under "Serial
|
||||||
|
Consoles). I have been using a TTL-to-RS-232 converter connected
|
||||||
|
as shown below::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
f411-nsh
|
||||||
|
--------
|
||||||
|
|
||||||
|
This configuration is the same as the f401-nsh configuration, except
|
||||||
|
that it is configured to support the Nucleo-F411RE.
|
||||||
@ -0,0 +1,223 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F410RB
|
||||||
|
================
|
||||||
|
|
||||||
|
This page discusses issues unique to NuttX configurations for the ST
|
||||||
|
Nucleo F410RB board from ST Micro. See
|
||||||
|
|
||||||
|
http://www.st.com/en/evaluation-tools/nucleo-f410rb.html
|
||||||
|
|
||||||
|
NucleoF410RB:
|
||||||
|
|
||||||
|
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F410RB
|
||||||
|
- Memory: 128 KB Flash and 32 KB SRAM
|
||||||
|
- ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
|
||||||
|
- DAC: 1x12-bit, 2.4 MSPS A/D converter: up to 1 channels
|
||||||
|
- DMA: 16-stream DMA controllers with FIFOs and burst support
|
||||||
|
- Timers: Up to 11 timers: up to 5 16-bit, 1 32-bit timers, two
|
||||||
|
watchdog timers, and a SysTick timer
|
||||||
|
- GPIO: Up to 81 I/O ports with interrupt capability
|
||||||
|
- I2C: Up to 3 I2C interfaces
|
||||||
|
- USARTs: Up to 3 USARTs
|
||||||
|
- SPIs: Up to 4 SPIs (2 I2S)
|
||||||
|
- CRC calculation unit
|
||||||
|
- RTC
|
||||||
|
|
||||||
|
- Peripherals: 1 led, 1 push button
|
||||||
|
- Debug: Serial wire debug and JTAG interfaces
|
||||||
|
- Expansion I/F Ardino and Morpho Headers
|
||||||
|
|
||||||
|
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
||||||
|
OpenOcd FTDI function - USB to JTAG front-end.
|
||||||
|
|
||||||
|
See https://os.mbed.com/platforms/ST-Nucleo-F410RB for more
|
||||||
|
information about this board.
|
||||||
|
|
||||||
|
Hardware
|
||||||
|
========
|
||||||
|
|
||||||
|
Buttons
|
||||||
|
-------
|
||||||
|
|
||||||
|
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
----
|
||||||
|
|
||||||
|
The Nucleo F410RB provide a single user LED, LD2. LD2
|
||||||
|
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
||||||
|
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
||||||
|
|
||||||
|
- When the I/O is HIGH value, the LED is on.
|
||||||
|
- When the I/O is LOW, the LED is off.
|
||||||
|
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows when the red LED (PE24) is available::
|
||||||
|
|
||||||
|
SYMBOL Meaning LD2
|
||||||
|
------------------- ----------------------- -----------
|
||||||
|
LED_STARTED NuttX has been started OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled OFF
|
||||||
|
LED_STACKCREATED Idle stack created ON
|
||||||
|
LED_INIRQ In an interrupt No change
|
||||||
|
LED_SIGNAL In a signal handler No change
|
||||||
|
LED_ASSERTION An assertion failed No change
|
||||||
|
LED_PANIC The system has crashed Blinking
|
||||||
|
LED_IDLE MCU is is sleep mode Not used
|
||||||
|
|
||||||
|
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
||||||
|
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
||||||
|
has been detected and the system has halted.
|
||||||
|
|
||||||
|
Serial Consoles
|
||||||
|
===============
|
||||||
|
|
||||||
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA11 CN10 pin 14
|
||||||
|
PB7 CN7 pin 21
|
||||||
|
TXD: PA10 CN9 pin 3, CN10 pin 33
|
||||||
|
PB6 CN5 pin 3, CN10 pin 17
|
||||||
|
|
||||||
|
NOTE: You may need to edit the include/board.h to select different USART1
|
||||||
|
pin selections.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F410RB
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
To configure USART1 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART1=y
|
||||||
|
CONFIG_USART1_SERIALDRIVER=y
|
||||||
|
CONFIG_USART1_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART1_RXBUFSIZE=256
|
||||||
|
CONFIG_USART1_TXBUFSIZE=256
|
||||||
|
CONFIG_USART1_BAUD=115200
|
||||||
|
CONFIG_USART1_BITS=8
|
||||||
|
CONFIG_USART1_PARITY=0
|
||||||
|
CONFIG_USART1_2STOP=0
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
||||||
|
PD6
|
||||||
|
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
||||||
|
PD5
|
||||||
|
|
||||||
|
UART2 is the default in all of these configurations.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F410RB
|
||||||
|
----------- ------------
|
||||||
|
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 2 PA2 USART2_TX some RS-232 converters
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
||||||
|
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
||||||
|
as USART signals. Thus SB13 and SB14 should be OFF.
|
||||||
|
|
||||||
|
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
disconnected to PA3 and PA2 on STM32 MCU.
|
||||||
|
|
||||||
|
To configure USART2 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART2=y
|
||||||
|
CONFIG_USART2_SERIALDRIVER=y
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART2_RXBUFSIZE=256
|
||||||
|
CONFIG_USART2_TXBUFSIZE=256
|
||||||
|
CONFIG_USART2_BAUD=115200
|
||||||
|
CONFIG_USART2_BITS=8
|
||||||
|
CONFIG_USART2_PARITY=0
|
||||||
|
CONFIG_USART2_2STOP=0
|
||||||
|
|
||||||
|
USART6
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PC7 CN5 pin2, CN10 pin 19
|
||||||
|
PA12 CN10, pin 12
|
||||||
|
TXD: PC6 CN10, pin 4
|
||||||
|
PA11 CN10, pin 14
|
||||||
|
|
||||||
|
To configure USART6 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART6=y
|
||||||
|
CONFIG_USART6_SERIALDRIVER=y
|
||||||
|
CONFIG_USART6_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART6_RXBUFSIZE=256
|
||||||
|
CONFIG_USART6_TXBUFSIZE=256
|
||||||
|
CONFIG_USART6_BAUD=115200
|
||||||
|
CONFIG_USART6_BITS=8
|
||||||
|
CONFIG_USART6_PARITY=0
|
||||||
|
CONFIG_USART6_2STOP=0
|
||||||
|
|
||||||
|
Virtual COM Port
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Yet another option is to use UART2 and the USB virtual COM port. This
|
||||||
|
option may be more convenient for long term development, but is painful
|
||||||
|
to use during board bring-up.
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
||||||
|
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
||||||
|
connector CN10.
|
||||||
|
|
||||||
|
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
||||||
|
between them. Thus SB61, SB62 and SB63 should be OFF.
|
||||||
|
|
||||||
|
Configuring USART2 is the same as given above.
|
||||||
|
|
||||||
|
Question: What BAUD should be configure to interface with the Virtual
|
||||||
|
COM port? 115200 8N1?
|
||||||
|
|
||||||
|
Default
|
||||||
|
-------
|
||||||
|
|
||||||
|
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
||||||
|
virtual COM port is enabled.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
||||||
|
Nucleo-F410RB board. The Configuration enables the serial interfaces
|
||||||
|
on UART2. Support for builtin applications is enabled, but in the base
|
||||||
|
configuration no builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
@ -0,0 +1,394 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F401RE
|
||||||
|
================
|
||||||
|
|
||||||
|
This README discusses issues unique to NuttX configurations for the ST
|
||||||
|
NucleoF401RE and NucleoF411RE boards from ST Micro. See
|
||||||
|
|
||||||
|
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
|
||||||
|
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
|
||||||
|
|
||||||
|
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
|
||||||
|
Line" parts but differing in the specific STM32 chip mounted on board. The
|
||||||
|
chips themselves are also very similar with the STM32F411RE having some
|
||||||
|
additional capability:
|
||||||
|
|
||||||
|
NucleoF411RE:
|
||||||
|
|
||||||
|
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F411RE
|
||||||
|
- Memory: 512 KB Flash and 128 KB SRAM
|
||||||
|
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
||||||
|
- DMA: 16-stream DMA controllers with FIFOs and burst support
|
||||||
|
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
||||||
|
watchdog timers, and a SysTick timer
|
||||||
|
- GPIO: Up to 81 I/O ports with interrupt capability
|
||||||
|
- I2C: Up to 3 × I2C interfaces
|
||||||
|
- USARTs: Up to 3 USARTs
|
||||||
|
- SPIs: Up to 4 SPIs (2 I2S)
|
||||||
|
- SDIO interface
|
||||||
|
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
||||||
|
- CRC calculation unit
|
||||||
|
- RTC
|
||||||
|
|
||||||
|
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
|
||||||
|
|
||||||
|
Board features, however, are identical:
|
||||||
|
|
||||||
|
- Peripherals: 1 led, 1 push button
|
||||||
|
- Debug: Serial wire debug and JTAG interfaces
|
||||||
|
- Expansion I/F Ardino and Morpho Headers
|
||||||
|
|
||||||
|
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
||||||
|
OpenOcd FTDI function - USB to JTAG front-end.
|
||||||
|
|
||||||
|
See http://mbed.org/platforms/ST-Nucleo-F401RE and
|
||||||
|
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
|
||||||
|
information about these boards.
|
||||||
|
|
||||||
|
mbed
|
||||||
|
====
|
||||||
|
|
||||||
|
The Nucleo-F411RE includes boot loader from mbed:
|
||||||
|
|
||||||
|
https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
https://mbed.org/handbook/Homepage
|
||||||
|
|
||||||
|
Using the mbed loader:
|
||||||
|
|
||||||
|
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
|
||||||
|
2. A new file system will appear called NUCLEO; open it with Windows
|
||||||
|
Explorer (assuming that you are using Windows).
|
||||||
|
3. Drag and drop nuttx.bin into the MBED window. This will load the
|
||||||
|
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
|
||||||
|
close then re-open and the Nucleo-F4x1RE will be running the new code.
|
||||||
|
|
||||||
|
Hardware
|
||||||
|
========
|
||||||
|
|
||||||
|
GPIO
|
||||||
|
----
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
SERIAL_TX=PA_2 USER_BUTTON=PC_13
|
||||||
|
SERIAL_RX=PA_3 LED1 =PA_5
|
||||||
|
|
||||||
|
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
|
||||||
|
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
|
||||||
|
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
|
||||||
|
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
|
||||||
|
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
|
||||||
|
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
|
||||||
|
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
|
||||||
|
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
|
||||||
|
|
||||||
|
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
|
||||||
|
Buttons
|
||||||
|
-------
|
||||||
|
|
||||||
|
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
----
|
||||||
|
|
||||||
|
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
|
||||||
|
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
||||||
|
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
||||||
|
|
||||||
|
- When the I/O is HIGH value, the LED is on.
|
||||||
|
- When the I/O is LOW, the LED is off.
|
||||||
|
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows when the red LED (PE24) is available:
|
||||||
|
|
||||||
|
=================== ======================= ===========
|
||||||
|
SYMBOL Meaning LD2
|
||||||
|
=================== ======================= ===========
|
||||||
|
LED_STARTED NuttX has been started OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled OFF
|
||||||
|
LED_STACKCREATED Idle stack created ON
|
||||||
|
LED_INIRQ In an interrupt No change
|
||||||
|
LED_SIGNAL In a signal handler No change
|
||||||
|
LED_ASSERTION An assertion failed No change
|
||||||
|
LED_PANIC The system has crashed Blinking
|
||||||
|
LED_IDLE MCU is is sleep mode Not used
|
||||||
|
=================== ======================= ===========
|
||||||
|
|
||||||
|
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
||||||
|
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
||||||
|
has been detected and the system has halted.
|
||||||
|
|
||||||
|
Serial Consoles
|
||||||
|
===============
|
||||||
|
|
||||||
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA11 CN10 pin 14
|
||||||
|
PB7 CN7 pin 21
|
||||||
|
TXD: PA10 CN9 pin 3, CN10 pin 33
|
||||||
|
PB6 CN5 pin 3, CN10 pin 17
|
||||||
|
|
||||||
|
NOTE: You may need to edit the include/board.h to select different USART1
|
||||||
|
pin selections.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
To configure USART1 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART1=y
|
||||||
|
CONFIG_USART1_SERIALDRIVER=y
|
||||||
|
CONFIG_USART1_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART1_RXBUFSIZE=256
|
||||||
|
CONFIG_USART1_TXBUFSIZE=256
|
||||||
|
CONFIG_USART1_BAUD=115200
|
||||||
|
CONFIG_USART1_BITS=8
|
||||||
|
CONFIG_USART1_PARITY=0
|
||||||
|
CONFIG_USART1_2STOP=0
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
||||||
|
PD6
|
||||||
|
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
||||||
|
PD5
|
||||||
|
|
||||||
|
UART2 is the default in all of these configurations.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 2 PA2 USART2_TX some RS-232 converters
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
||||||
|
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
||||||
|
as USART signals. Thus SB13 and SB14 should be OFF.
|
||||||
|
|
||||||
|
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
disconnected to PA3 and PA2 on STM32 MCU.
|
||||||
|
|
||||||
|
To configure USART2 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART2=y
|
||||||
|
CONFIG_USART2_SERIALDRIVER=y
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART2_RXBUFSIZE=256
|
||||||
|
CONFIG_USART2_TXBUFSIZE=256
|
||||||
|
CONFIG_USART2_BAUD=115200
|
||||||
|
CONFIG_USART2_BITS=8
|
||||||
|
CONFIG_USART2_PARITY=0
|
||||||
|
CONFIG_USART2_2STOP=0
|
||||||
|
|
||||||
|
USART6
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PC7 CN5 pin2, CN10 pin 19
|
||||||
|
PA12 CN10, pin 12
|
||||||
|
TXD: PC6 CN10, pin 4
|
||||||
|
PA11 CN10, pin 14
|
||||||
|
|
||||||
|
To configure USART6 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART6=y
|
||||||
|
CONFIG_USART6_SERIALDRIVER=y
|
||||||
|
CONFIG_USART6_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART6_RXBUFSIZE=256
|
||||||
|
CONFIG_USART6_TXBUFSIZE=256
|
||||||
|
CONFIG_USART6_BAUD=115200
|
||||||
|
CONFIG_USART6_BITS=8
|
||||||
|
CONFIG_USART6_PARITY=0
|
||||||
|
CONFIG_USART6_2STOP=0
|
||||||
|
|
||||||
|
Virtual COM Port
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Yet another option is to use UART2 and the USB virtual COM port. This
|
||||||
|
option may be more convenient for long term development, but is painful
|
||||||
|
to use during board bring-up.
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
||||||
|
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
||||||
|
connector CN10.
|
||||||
|
|
||||||
|
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
||||||
|
between them. Thus SB61, SB62 and SB63 should be OFF.
|
||||||
|
|
||||||
|
Configuring USART2 is the same as given above.
|
||||||
|
|
||||||
|
Question: What BAUD should be configure to interface with the Virtual
|
||||||
|
COM port? 115200 8N1?
|
||||||
|
|
||||||
|
Default
|
||||||
|
-------
|
||||||
|
|
||||||
|
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
||||||
|
virtual COM port is enabled.
|
||||||
|
|
||||||
|
Shields
|
||||||
|
=======
|
||||||
|
|
||||||
|
RS-232 from Cutedigi.com
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Supports a single RS-232 connected via::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE Cutedigi
|
||||||
|
----------- ------------ --------
|
||||||
|
Pin 1 PA3 USART2_RX RXD
|
||||||
|
Pin 2 PA2 USART2_TX TXD
|
||||||
|
|
||||||
|
Support for this shield is enabled by selecting USART2 and configuring
|
||||||
|
SB13, 14, 62, and 63 as described above under "Serial Consoles"
|
||||||
|
|
||||||
|
Itead Joystick Shield
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
See http://imall.iteadstudio.com/im120417014.html for more information
|
||||||
|
about this joystick.
|
||||||
|
|
||||||
|
Itead Joystick Connection::
|
||||||
|
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
ARDUINO ITEAD NUCLEO-F4x1
|
||||||
|
PIN NAME SIGNAL SIGNAL
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
D3 Button E Output PB3
|
||||||
|
D4 Button D Output PB5
|
||||||
|
D5 Button C Output PB4
|
||||||
|
D6 Button B Output PB10
|
||||||
|
D7 Button A Output PA8
|
||||||
|
D8 Button F Output PA9
|
||||||
|
D9 Button G Output PC7
|
||||||
|
A0 Joystick Y Output PA0 ADC1_0
|
||||||
|
A1 Joystick X Output PA1 ADC1_1
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
|
||||||
|
All buttons are pulled on the shield. A sensed low value indicates
|
||||||
|
when the button is pressed.
|
||||||
|
|
||||||
|
NOTE: Button F cannot be used with the default USART1 configuration
|
||||||
|
because PA9 is configured for USART1_RX by default. Use select
|
||||||
|
different USART1 pins in the board.h file or select a different
|
||||||
|
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
|
||||||
|
eliminate all but buttons A, B, and C.
|
||||||
|
|
||||||
|
Itead Joystick Signal interpretation::
|
||||||
|
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
BUTTON TYPE NUTTX ALIAS
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
Button A Large button A JUMP/BUTTON 3
|
||||||
|
Button B Large button B FIRE/BUTTON 2
|
||||||
|
Button C Joystick select button SELECT/BUTTON 1
|
||||||
|
Button D Tiny Button D BUTTON 6
|
||||||
|
Button E Tiny Button E BUTTON 7
|
||||||
|
Button F Large Button F BUTTON 4
|
||||||
|
Button G Large Button G BUTTON 5
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
|
||||||
|
Itead Joystick configuration settings::
|
||||||
|
|
||||||
|
System Type -> STM32 Peripheral Support
|
||||||
|
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
|
||||||
|
|
||||||
|
Drivers
|
||||||
|
CONFIG_ANALOG=y : Should be automatically selected
|
||||||
|
CONFIG_ADC=y : Should be automatically selected
|
||||||
|
CONFIG_INPUT=y : Select input device support
|
||||||
|
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
|
||||||
|
|
||||||
|
There is nothing in the configuration that currently uses the joystick.
|
||||||
|
For testing, you can add the following configuration options to enable the
|
||||||
|
analog joystick example at apps/examples/ajoystick::
|
||||||
|
|
||||||
|
CONFIG_NSH_ARCHINIT=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
|
||||||
|
2014-12-04:
|
||||||
|
|
||||||
|
- Without ADC DMA support, it is not possible to sample both X and Y
|
||||||
|
with a single ADC. Right now, only one axis is being converted.
|
||||||
|
|
||||||
|
- There is conflicts with some of the Arduino data pins and the
|
||||||
|
default USART1 configuration. I am currently running with USART1
|
||||||
|
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
|
||||||
|
conflict.
|
||||||
|
|
||||||
|
- Current showstopper: I appear to be getting infinite interrupts as
|
||||||
|
soon as joystick button interrupts are enabled.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
f401-nsh:
|
||||||
|
---------
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
||||||
|
Nucleo-F401RE board. The Configuration enables the serial interfaces
|
||||||
|
on UART2. Support for builtin applications is enabled, but in the base
|
||||||
|
configuration no builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. By default, this configuration uses the ARM EABI toolchain
|
||||||
|
for Linux. That can easily be reconfigured, of course.:
|
||||||
|
|
||||||
|
CONFIG_HOST_LINUX=y : Builds under Linux
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
|
||||||
|
|
||||||
|
3. Although the default console is USART2 (which would correspond to
|
||||||
|
the Virtual COM port) I have done all testing with the console
|
||||||
|
device configured for USART1 (see instruction above under "Serial
|
||||||
|
Consoles). I have been using a TTL-to-RS-232 converter connected
|
||||||
|
as shown below::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
f411-nsh
|
||||||
|
--------
|
||||||
|
|
||||||
|
This configuration is the same as the f401-nsh configuration, except
|
||||||
|
that it is configured to support the Nucleo-F411RE.
|
||||||
@ -0,0 +1,222 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F410RB
|
||||||
|
================
|
||||||
|
|
||||||
|
This page discusses issues unique to NuttX configurations for the ST
|
||||||
|
Nucleo F410RB board from ST Micro. See
|
||||||
|
|
||||||
|
http://www.st.com/en/evaluation-tools/nucleo-f412zg.html
|
||||||
|
|
||||||
|
NucleoF412ZG:
|
||||||
|
|
||||||
|
- Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F412ZG
|
||||||
|
- Memory: 1 MB Flash and 256 KB SRAM
|
||||||
|
- ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
|
||||||
|
- DMA: 2x8-stream DMA controllers with FIFOs and burst support
|
||||||
|
- Timers: Up to 17 timers: up to 12 16-bit, 2 32-bit timers, two
|
||||||
|
watchdog timers, and a SysTick timer
|
||||||
|
- GPIO: Up to 114 I/O ports with interrupt capability
|
||||||
|
- I2C: Up to 4 I2C interfaces
|
||||||
|
- USARTs: Up to 4 USARTs
|
||||||
|
- SPIs: Up to 5 SPIs (5 I2S)
|
||||||
|
- SDIO interface (SD/MMC/eMMC)
|
||||||
|
- Advanced connectivity: USB 2.0 full-speed device/host/OTG controller with PHY
|
||||||
|
- 2x CAN (2.0B Active)
|
||||||
|
- True random number generator
|
||||||
|
- CRC calculation unit
|
||||||
|
- 96-bit unique ID
|
||||||
|
- RTC
|
||||||
|
|
||||||
|
See:
|
||||||
|
https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
|
||||||
|
|
||||||
|
- Peripherals: 3 led, 2 push button
|
||||||
|
- Debug: Serial wire debug and JTAG interfaces
|
||||||
|
- Expansion I/F Ardino and Morpho Headers
|
||||||
|
|
||||||
|
Hardware
|
||||||
|
========
|
||||||
|
|
||||||
|
Buttons
|
||||||
|
-------
|
||||||
|
|
||||||
|
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
----
|
||||||
|
|
||||||
|
The Nucleo F410RB provide a single user LED, LD2. LD2
|
||||||
|
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
||||||
|
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
||||||
|
|
||||||
|
- When the I/O is HIGH value, the LED is on.
|
||||||
|
- When the I/O is LOW, the LED is off.
|
||||||
|
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows when the red LED (PE24) is available::
|
||||||
|
|
||||||
|
SYMBOL Meaning LD2
|
||||||
|
------------------- ----------------------- -----------
|
||||||
|
LED_STARTED NuttX has been started OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled OFF
|
||||||
|
LED_STACKCREATED Idle stack created ON
|
||||||
|
LED_INIRQ In an interrupt No change
|
||||||
|
LED_SIGNAL In a signal handler No change
|
||||||
|
LED_ASSERTION An assertion failed No change
|
||||||
|
LED_PANIC The system has crashed Blinking
|
||||||
|
LED_IDLE MCU is is sleep mode Not used
|
||||||
|
|
||||||
|
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
||||||
|
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
||||||
|
has been detected and the system has halted.
|
||||||
|
|
||||||
|
Serial Consoles
|
||||||
|
===============
|
||||||
|
|
||||||
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA11 CN10 pin 14
|
||||||
|
PB7 CN7 pin 21
|
||||||
|
TXD: PA10 CN9 pin 3, CN10 pin 33
|
||||||
|
PB6 CN5 pin 3, CN10 pin 17
|
||||||
|
|
||||||
|
NOTE: You may need to edit the include/board.h to select different USART1
|
||||||
|
pin selections.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F410RB
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
To configure USART1 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART1=y
|
||||||
|
CONFIG_USART1_SERIALDRIVER=y
|
||||||
|
CONFIG_USART1_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART1_RXBUFSIZE=256
|
||||||
|
CONFIG_USART1_TXBUFSIZE=256
|
||||||
|
CONFIG_USART1_BAUD=115200
|
||||||
|
CONFIG_USART1_BITS=8
|
||||||
|
CONFIG_USART1_PARITY=0
|
||||||
|
CONFIG_USART1_2STOP=0
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
||||||
|
PD6
|
||||||
|
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
||||||
|
PD5
|
||||||
|
|
||||||
|
UART2 is the default in all of these configurations.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F410RB
|
||||||
|
----------- ------------
|
||||||
|
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 2 PA2 USART2_TX some RS-232 converters
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
||||||
|
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
||||||
|
as USART signals. Thus SB13 and SB14 should be OFF.
|
||||||
|
|
||||||
|
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
disconnected to PA3 and PA2 on STM32 MCU.
|
||||||
|
|
||||||
|
To configure USART2 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART2=y
|
||||||
|
CONFIG_USART2_SERIALDRIVER=y
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART2_RXBUFSIZE=256
|
||||||
|
CONFIG_USART2_TXBUFSIZE=256
|
||||||
|
CONFIG_USART2_BAUD=115200
|
||||||
|
CONFIG_USART2_BITS=8
|
||||||
|
CONFIG_USART2_PARITY=0
|
||||||
|
CONFIG_USART2_2STOP=0
|
||||||
|
|
||||||
|
USART6
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PC7 CN5 pin2, CN10 pin 19
|
||||||
|
PA12 CN10, pin 12
|
||||||
|
TXD: PC6 CN10, pin 4
|
||||||
|
PA11 CN10, pin 14
|
||||||
|
|
||||||
|
To configure USART6 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART6=y
|
||||||
|
CONFIG_USART6_SERIALDRIVER=y
|
||||||
|
CONFIG_USART6_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART6_RXBUFSIZE=256
|
||||||
|
CONFIG_USART6_TXBUFSIZE=256
|
||||||
|
CONFIG_USART6_BAUD=115200
|
||||||
|
CONFIG_USART6_BITS=8
|
||||||
|
CONFIG_USART6_PARITY=0
|
||||||
|
CONFIG_USART6_2STOP=0
|
||||||
|
|
||||||
|
Virtual COM Port
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Yet another option is to use UART2 and the USB virtual COM port. This
|
||||||
|
option may be more convenient for long term development, but is painful
|
||||||
|
to use during board bring-up.
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
||||||
|
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
||||||
|
connector CN10.
|
||||||
|
|
||||||
|
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
||||||
|
between them. Thus SB61, SB62 and SB63 should be OFF.
|
||||||
|
|
||||||
|
Configuring USART2 is the same as given above.
|
||||||
|
|
||||||
|
Question: What BAUD should be configure to interface with the Virtual
|
||||||
|
COM port? 115200 8N1?
|
||||||
|
|
||||||
|
Default:
|
||||||
|
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
||||||
|
virtual COM port is enabled.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
||||||
|
Nucleo-F410RB board. The Configuration enables the serial interfaces
|
||||||
|
on UART2. Support for builtin applications is enabled, but in the base
|
||||||
|
configuration no builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
@ -0,0 +1,3 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F429ZI
|
||||||
|
================
|
||||||
@ -0,0 +1,494 @@
|
|||||||
|
================
|
||||||
|
ST Nucleo F446RE
|
||||||
|
================
|
||||||
|
|
||||||
|
This page discusses issues unique to NuttX configurations for the ST
|
||||||
|
NucleoF446RE boards from ST Micro. See
|
||||||
|
|
||||||
|
https://www.st.com/en/evaluation-tools/nucleo-f446re.html
|
||||||
|
|
||||||
|
NucleoF446RE:
|
||||||
|
|
||||||
|
- Microprocessor: 32-bit ARM Cortex M4 at 180MHz STM32F446RE
|
||||||
|
- Memory: 512 KB Flash and 128 KB SRAM
|
||||||
|
- ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
||||||
|
- DMA: 16-stream DMA controllers with FIFOs and burst support
|
||||||
|
- Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
||||||
|
watchdog timers, and a SysTick timer
|
||||||
|
- GPIO: Up to 81 I/O ports with interrupt capability
|
||||||
|
- I2C: Up to 3 × I2C interfaces
|
||||||
|
- USARTs: Up to 3 USARTs
|
||||||
|
- USARTs: Up to 3 USARTs
|
||||||
|
- SPIs: Up to 4 SPIs (2 I2S)
|
||||||
|
- SDIO interface
|
||||||
|
- USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
||||||
|
- CRC calculation unit
|
||||||
|
- RTC
|
||||||
|
|
||||||
|
The NucleoF446RE also has additional DMA and SPI peripheral capabilities.
|
||||||
|
|
||||||
|
Board features, however, are identical:
|
||||||
|
|
||||||
|
- Peripherals: 1 led, 1 push button
|
||||||
|
- Debug: Serial wire debug and JTAG interfaces
|
||||||
|
- Expansion I/F Ardino and Morpho Headers
|
||||||
|
|
||||||
|
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
||||||
|
OpenOcd FTDI function - USB to JTAG front-end.
|
||||||
|
|
||||||
|
See https://os.mbed.com/platforms/ST-Nucleo-F446RE/ for more
|
||||||
|
information about this board.
|
||||||
|
|
||||||
|
mbed
|
||||||
|
====
|
||||||
|
|
||||||
|
The Nucleo-F401RE includes boot loader from mbed:
|
||||||
|
|
||||||
|
https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
https://mbed.org/handbook/Homepage
|
||||||
|
|
||||||
|
Using the mbed loader:
|
||||||
|
|
||||||
|
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
|
||||||
|
2. A new file system will appear called NUCLEO; open it with Windows
|
||||||
|
Explorer (assuming that you are using Windows).
|
||||||
|
3. Drag and drop nuttx.bin into the MBED window. This will load the
|
||||||
|
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
|
||||||
|
close then re-open and the Nucleo-F4x1RE will be running the new code.
|
||||||
|
|
||||||
|
Hardware
|
||||||
|
========
|
||||||
|
|
||||||
|
..
|
||||||
|
GPIO
|
||||||
|
----
|
||||||
|
SERIAL_TX=PA_2 USER_BUTTON=PC_13
|
||||||
|
SERIAL_RX=PA_3 LED1 =PA_5
|
||||||
|
|
||||||
|
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
|
||||||
|
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
|
||||||
|
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
|
||||||
|
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
|
||||||
|
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
|
||||||
|
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
|
||||||
|
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
|
||||||
|
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
|
||||||
|
|
||||||
|
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
|
||||||
|
|
||||||
|
Buttons
|
||||||
|
-------
|
||||||
|
|
||||||
|
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
||||||
|
microcontroller.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
----
|
||||||
|
|
||||||
|
The Nucleo F446RE provides a single user LED, LD2. LD2
|
||||||
|
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
||||||
|
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
||||||
|
|
||||||
|
- When the I/O is HIGH value, the LED is on.
|
||||||
|
- When the I/O is LOW, the LED is off.
|
||||||
|
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows when the red LED (PE24) is available::
|
||||||
|
|
||||||
|
SYMBOL Meaning LD2
|
||||||
|
------------------- ----------------------- -----------
|
||||||
|
LED_STARTED NuttX has been started OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled OFF
|
||||||
|
LED_STACKCREATED Idle stack created ON
|
||||||
|
LED_INIRQ In an interrupt No change
|
||||||
|
LED_SIGNAL In a signal handler No change
|
||||||
|
LED_ASSERTION An assertion failed No change
|
||||||
|
LED_PANIC The system has crashed Blinking
|
||||||
|
LED_IDLE MCU is is sleep mode Not used
|
||||||
|
|
||||||
|
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
||||||
|
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
||||||
|
has been detected and the system has halted.
|
||||||
|
|
||||||
|
Serial Consoles
|
||||||
|
===============
|
||||||
|
|
||||||
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA11 CN10 pin 14
|
||||||
|
PB7 CN7 pin 21
|
||||||
|
TXD: PA10 CN9 pin 3, CN10 pin 33
|
||||||
|
PB6 CN5 pin 3, CN10 pin 17
|
||||||
|
|
||||||
|
NOTE: You may need to edit the include/board.h to select different USART1
|
||||||
|
pin selections.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
To configure USART1 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART1=y
|
||||||
|
CONFIG_USART1_SERIALDRIVER=y
|
||||||
|
CONFIG_USART1_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART1_RXBUFSIZE=256
|
||||||
|
CONFIG_USART1_TXBUFSIZE=256
|
||||||
|
CONFIG_USART1_BAUD=115200
|
||||||
|
CONFIG_USART1_BITS=8
|
||||||
|
CONFIG_USART1_PARITY=0
|
||||||
|
CONFIG_USART1_2STOP=0
|
||||||
|
|
||||||
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
||||||
|
PD6
|
||||||
|
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
||||||
|
PD5
|
||||||
|
|
||||||
|
UART2 is the default in all of these configurations.
|
||||||
|
|
||||||
|
TTL to RS-232 converter connection::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 2 PA2 USART2_TX some RS-232 converters
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
||||||
|
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
||||||
|
as USART signals. Thus SB13 and SB14 should be OFF.
|
||||||
|
|
||||||
|
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
disconnected to PA3 and PA2 on STM32 MCU.
|
||||||
|
|
||||||
|
To configure USART2 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART2=y
|
||||||
|
CONFIG_USART2_SERIALDRIVER=y
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART2_RXBUFSIZE=256
|
||||||
|
CONFIG_USART2_TXBUFSIZE=256
|
||||||
|
CONFIG_USART2_BAUD=115200
|
||||||
|
CONFIG_USART2_BITS=8
|
||||||
|
CONFIG_USART2_PARITY=0
|
||||||
|
CONFIG_USART2_2STOP=0
|
||||||
|
|
||||||
|
USART6
|
||||||
|
------
|
||||||
|
|
||||||
|
Pins and Connectors::
|
||||||
|
|
||||||
|
RXD: PC7 CN5 pin2, CN10 pin 19
|
||||||
|
PA12 CN10, pin 12
|
||||||
|
TXD: PC6 CN10, pin 4
|
||||||
|
PA11 CN10, pin 14
|
||||||
|
|
||||||
|
To configure USART6 as the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_USART6=y
|
||||||
|
CONFIG_USART6_SERIALDRIVER=y
|
||||||
|
CONFIG_USART6_SERIAL_CONSOLE=y
|
||||||
|
CONFIG_USART6_RXBUFSIZE=256
|
||||||
|
CONFIG_USART6_TXBUFSIZE=256
|
||||||
|
CONFIG_USART6_BAUD=115200
|
||||||
|
CONFIG_USART6_BITS=8
|
||||||
|
CONFIG_USART6_PARITY=0
|
||||||
|
CONFIG_USART6_2STOP=0
|
||||||
|
|
||||||
|
Virtual COM Port
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Yet another option is to use UART2 and the USB virtual COM port. This
|
||||||
|
option may be more convenient for long term development, but is painful
|
||||||
|
to use during board bring-up.
|
||||||
|
|
||||||
|
Solder Bridges. This configuration requires:
|
||||||
|
|
||||||
|
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
||||||
|
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
||||||
|
connector CN10.
|
||||||
|
|
||||||
|
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
||||||
|
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
||||||
|
between them. Thus SB61, SB62 and SB63 should be OFF.
|
||||||
|
|
||||||
|
Configuring USART2 is the same as given above.
|
||||||
|
|
||||||
|
Question: What BAUD should be configure to interface with the Virtual
|
||||||
|
COM port? 115200 8N1?
|
||||||
|
|
||||||
|
Default
|
||||||
|
-------
|
||||||
|
|
||||||
|
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
||||||
|
virtual COM port is enabled.
|
||||||
|
|
||||||
|
Shields
|
||||||
|
=======
|
||||||
|
|
||||||
|
RS-232 from Cutedigi.com
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Supports a single RS-232 connected via::
|
||||||
|
|
||||||
|
Nucleo CN9 STM32F4x1RE Cutedigi
|
||||||
|
----------- ------------ --------
|
||||||
|
Pin 1 PA3 USART2_RX RXD
|
||||||
|
Pin 2 PA2 USART2_TX TXD
|
||||||
|
|
||||||
|
Support for this shield is enabled by selecting USART2 and configuring
|
||||||
|
SB13, 14, 62, and 63 as described above under "Serial Consoles"
|
||||||
|
|
||||||
|
Itead Joystick Shield
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
See http://imall.iteadstudio.com/im120417014.html for more information
|
||||||
|
about this joystick.
|
||||||
|
|
||||||
|
Itead Joystick Connection::
|
||||||
|
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
ARDUINO ITEAD NUCLEO-F4x1
|
||||||
|
PIN NAME SIGNAL SIGNAL
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
D3 Button E Output PB3
|
||||||
|
D4 Button D Output PB5
|
||||||
|
D5 Button C Output PB4
|
||||||
|
D6 Button B Output PB10
|
||||||
|
D7 Button A Output PA8
|
||||||
|
D8 Button F Output PA9
|
||||||
|
D9 Button G Output PC7
|
||||||
|
A0 Joystick Y Output PA0 ADC1_0
|
||||||
|
A1 Joystick X Output PA1 ADC1_1
|
||||||
|
--------- ----------------- ---------------------------------
|
||||||
|
|
||||||
|
All buttons are pulled on the shield. A sensed low value indicates
|
||||||
|
when the button is pressed.
|
||||||
|
|
||||||
|
NOTE: Button F cannot be used with the default USART1 configuration
|
||||||
|
because PA9 is configured for USART1_RX by default. Use select
|
||||||
|
different USART1 pins in the board.h file or select a different
|
||||||
|
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
|
||||||
|
eliminate all but buttons A, B, and C.
|
||||||
|
|
||||||
|
Itead Joystick Signal interpretation::
|
||||||
|
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
BUTTON TYPE NUTTX ALIAS
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
Button A Large button A JUMP/BUTTON 3
|
||||||
|
Button B Large button B FIRE/BUTTON 2
|
||||||
|
Button C Joystick select button SELECT/BUTTON 1
|
||||||
|
Button D Tiny Button D BUTTON 6
|
||||||
|
Button E Tiny Button E BUTTON 7
|
||||||
|
Button F Large Button F BUTTON 4
|
||||||
|
Button G Large Button G BUTTON 5
|
||||||
|
--------- ----------------------- ---------------------------
|
||||||
|
|
||||||
|
Itead Joystick configuration settings::
|
||||||
|
|
||||||
|
System Type -> STM32 Peripheral Support
|
||||||
|
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
|
||||||
|
|
||||||
|
Drivers
|
||||||
|
CONFIG_ANALOG=y : Should be automatically selected
|
||||||
|
CONFIG_ADC=y : Should be automatically selected
|
||||||
|
CONFIG_INPUT=y : Select input device support
|
||||||
|
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
|
||||||
|
|
||||||
|
There is nothing in the configuration that currently uses the joystick.
|
||||||
|
For testing, you can add the following configuration options to enable the
|
||||||
|
analog joystick example at apps/examples/ajoystick::
|
||||||
|
|
||||||
|
CONFIG_NSH_ARCHINIT=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK=y
|
||||||
|
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2014-12-04:
|
||||||
|
|
||||||
|
- Without ADC DMA support, it is not possible to sample both X and Y
|
||||||
|
with a single ADC. Right now, only one axis is being converted.
|
||||||
|
|
||||||
|
- There is conflicts with some of the Arduino data pins and the
|
||||||
|
default USART1 configuration. I am currently running with USART1
|
||||||
|
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
|
||||||
|
conflict.
|
||||||
|
|
||||||
|
- Current showstopper: I appear to be getting infinite interrupts as
|
||||||
|
soon as joystick button interrupts are enabled.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
nsh:
|
||||||
|
----
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
||||||
|
Nucleo-F446RE board. The Configuration enables the serial interfaces
|
||||||
|
on UART2. Support for builtin applications is enabled, but in the base
|
||||||
|
configuration no builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. By default, this configuration uses the ARM EABI toolchain
|
||||||
|
for Linux. That can easily be reconfigured, of course.::
|
||||||
|
|
||||||
|
CONFIG_HOST_LINUX=y : Builds under Linux
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
|
||||||
|
|
||||||
|
3. Although the default console is USART2 (which would correspond to
|
||||||
|
the Virtual COM port) I have done all testing with the console
|
||||||
|
device configured for USART1 (see instruction above under "Serial
|
||||||
|
Consoles). I have been using a TTL-to-RS-232 converter connected
|
||||||
|
as shown below::
|
||||||
|
|
||||||
|
Nucleo CN10 STM32F446RE
|
||||||
|
----------- ------------
|
||||||
|
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
||||||
|
Pin 33 PA10 USART1_TX some RS-232 converters
|
||||||
|
Pin 20 GND
|
||||||
|
Pin 8 U5V
|
||||||
|
|
||||||
|
can
|
||||||
|
---
|
||||||
|
|
||||||
|
This is basically an nsh configuration (see above) with added support
|
||||||
|
for CAN driver. Both CAN 1 (RX: PB_8, TX: PB_9) and CAN 2 (RX: PB_5, TX: PB_6)
|
||||||
|
are turn on.
|
||||||
|
|
||||||
|
Functionality of CAN driver can be tested by calling application
|
||||||
|
"can" in NuttShell. This application sends 100 messages over CAN 1.
|
||||||
|
|
||||||
|
dac
|
||||||
|
---
|
||||||
|
|
||||||
|
This is an nsh configuration (see above) with added support
|
||||||
|
for digital analog converter driver.
|
||||||
|
|
||||||
|
Functionality of DAC driver can be tested by calling application
|
||||||
|
"dac" in NuttShell. GPIO_DAC1_OUT1 pin is set on PA_4.
|
||||||
|
|
||||||
|
gpio
|
||||||
|
----
|
||||||
|
|
||||||
|
This is an nsh configuration (see above) with added support for GPIO
|
||||||
|
driver and GPIO test application "gpio". Three pins are configured for
|
||||||
|
testing purposes::
|
||||||
|
|
||||||
|
PA_7 - GPIO_INPUT
|
||||||
|
PB_6 - GPIO_OUTPUT
|
||||||
|
PC_7 - GPIO_INPUT_INTERRUPT
|
||||||
|
|
||||||
|
ihm08m1_f32 and ihm08m1_b16
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
These examples are dedicated for the X-NUCLEO-IHM08M1 expansion board with
|
||||||
|
L6398 gate drivers and discrete transistors.
|
||||||
|
|
||||||
|
WARNING: L6398 gate drivers require channel 2 negative polarisation and
|
||||||
|
negative sign for the deadtime. Make sure that your gate drivers logic
|
||||||
|
is compatible with this configuration.
|
||||||
|
|
||||||
|
X-NUCLEO-IHM08M1 must be configured to work with FOC and 3-shunt
|
||||||
|
resistors. See ST documentation for details.
|
||||||
|
|
||||||
|
Pin configuration for the X-NUCLEO-IHM08M1 (TIM1 configuration)::
|
||||||
|
|
||||||
|
Board Function Chip Function Chip Pin Number
|
||||||
|
------------- ---------------- -----------------
|
||||||
|
Phase U high TIM1_CH1 PA8
|
||||||
|
Phase U low TIM1_CH1N PA7
|
||||||
|
Phase V high TIM1_CH2 PA9
|
||||||
|
Phase V low TIM1_CH2N PB0
|
||||||
|
Phase W high TIM1_CH3 PA10
|
||||||
|
Phase W low TIM1_CH3N PB1
|
||||||
|
Current U ADC1_IN0 PA0
|
||||||
|
Current V ADC1_IN11 PC1
|
||||||
|
Current W ADC1_IN10 PC0
|
||||||
|
Temperature ADC1_IN12 PC2
|
||||||
|
VBUS ADC1_IN1 PA1
|
||||||
|
BEMF1 (NU) PC3
|
||||||
|
BEMF2 (NU) PC4
|
||||||
|
BEMF3 (NU) PC5
|
||||||
|
LED GPIO_PB2 PB2
|
||||||
|
+3V3 (CN7_16)
|
||||||
|
GND (CN7_20)
|
||||||
|
GPIO_BEMF (NU) PC9
|
||||||
|
ENCO_A/HALL_H1 TIM2_CH1 PA15
|
||||||
|
ENCO_B/HALL_H2 TIM2_CH2 PB3
|
||||||
|
ENCO_Z/HALL_H3 TIM2_CH3 PB10
|
||||||
|
DAC (NU) PA5
|
||||||
|
GPIO3 (NU) PB13
|
||||||
|
CPOUT (NU) PA12
|
||||||
|
BKIN1 (NU) PA6
|
||||||
|
BKIN2 (NU) PA11
|
||||||
|
BKIN3 (NU) PB14
|
||||||
|
POT/DAC DAC1_CH1/ADC1_IN4 PA4
|
||||||
|
CURR_REF (NU) PB4
|
||||||
|
DEBUG0 GPIO PB12
|
||||||
|
DEBUG1 GPIO PB9
|
||||||
|
DEBUG2 GPIO PC6
|
||||||
|
DEBUG3 GPIO PB5
|
||||||
|
DEBUG4 GPIO PC8
|
||||||
|
|
||||||
|
Current shunt resistance = 0.01
|
||||||
|
Current sense gain = -5.18 (inverted current)
|
||||||
|
Vbus sense gain = 9.31k/(9.31k+169k) = 0.0522
|
||||||
|
Vbus min = 10V
|
||||||
|
Vbus max = 48V
|
||||||
|
Iout max = 15A RMS
|
||||||
|
|
||||||
|
IPHASE_RATIO = 1/(R_shunt*gain) = -19.3
|
||||||
|
VBUS_RATIO = 1/VBUS_gain = 19.152
|
||||||
|
|
||||||
|
For now only 3-shunt resistors configuration is supported.
|
||||||
|
|
||||||
|
lcd
|
||||||
|
---
|
||||||
|
|
||||||
|
This is basically an nsh configuration (see above) with added support
|
||||||
|
of ILI9225 176x220 TFT display and test framebuffer application.
|
||||||
|
|
||||||
|
Display connection is set to SPI 3 and pinout is following::
|
||||||
|
|
||||||
|
CS D8
|
||||||
|
RST D6
|
||||||
|
RS D7
|
||||||
|
SDA D4
|
||||||
|
CLK D3
|
||||||
|
|
||||||
|
Framebuffer application can be started from terminal by typing "fb".
|
||||||
|
|
||||||
|
pwm
|
||||||
|
---
|
||||||
|
|
||||||
|
This is an nsh configuration (see above) with added capability of pulse width
|
||||||
|
modulation. PWM output is on Timer 3 channel 1, which is pin PA_6 (D12) on
|
||||||
|
Nucleo board. Example program can be stared by "pwm" command.
|
||||||
@ -0,0 +1,210 @@
|
|||||||
|
=================
|
||||||
|
Olimex STM32-E407
|
||||||
|
=================
|
||||||
|
|
||||||
|
The Olimex STM32-E407 configuration is based on the configuration
|
||||||
|
olimex-stm32-h407 and stm32f4discovery.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
Instantiating Configurations
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
Each Olimex-STM32-E407 configuration is maintained in a sub-directory and
|
||||||
|
can be selected as follow::
|
||||||
|
|
||||||
|
tools/configure.sh [OPTIONS] olimex-stm32-e407:<subdir>
|
||||||
|
|
||||||
|
Typical options include -l for a Linux host platform or -c for Cygwin
|
||||||
|
host platform. See 'tools/configure.sh -h' for other options. And
|
||||||
|
<subdir> is one of the sub-directories listed below.
|
||||||
|
|
||||||
|
Compile Firmware
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Once you've set the proper configuration, you just need to execute the next
|
||||||
|
command::
|
||||||
|
|
||||||
|
make
|
||||||
|
|
||||||
|
If everything goes find, it should return the next two files::
|
||||||
|
|
||||||
|
nuttx.hex
|
||||||
|
nuttx.bin
|
||||||
|
|
||||||
|
You can return more kinds of files by setting on menuconfig.
|
||||||
|
|
||||||
|
Flashing the Board
|
||||||
|
------------------
|
||||||
|
|
||||||
|
You can flash this board in different ways, but the easiest way is using
|
||||||
|
ARM-USB-TINY-H JTAG flasher device.
|
||||||
|
Connect this device to the JTAG connector and type the next command::
|
||||||
|
|
||||||
|
openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
|
||||||
|
|
||||||
|
Configuration Directories
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
||||||
|
configuration enables a console on UART2. Support for
|
||||||
|
builtin applications is enabled, but in the base configuration no
|
||||||
|
builtin applications are selected.
|
||||||
|
|
||||||
|
usbnsh
|
||||||
|
------
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
||||||
|
configuration enables a console on USB_OTG1. Support for
|
||||||
|
builtin applications is enabled, but in the base configuration no
|
||||||
|
builtin applications are selected.
|
||||||
|
|
||||||
|
netnsh
|
||||||
|
------
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at examples/nsh. This
|
||||||
|
configuration is focused on network testing.
|
||||||
|
|
||||||
|
bmp180
|
||||||
|
------
|
||||||
|
|
||||||
|
This is a configuration example for the BMP180 barometer sensor. This
|
||||||
|
sensor works with I2C, you need to do the next connections::
|
||||||
|
|
||||||
|
BMP180 VIN -> Board 3.3V
|
||||||
|
BMP180 GND -> Board GND
|
||||||
|
BMP180 SCL -> Board PB6 (Arduino header D1)
|
||||||
|
BMP180 SDA -> Board PB7 (Arduino header D0)
|
||||||
|
|
||||||
|
This example is configured to work with the USBNSH instead of UART NSH, so
|
||||||
|
the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
On the console, type "ls /dev " and if the registration process goes fine,
|
||||||
|
you should see a device called "press0". Now execute the app
|
||||||
|
BMP180 to see the ambient pressure value.
|
||||||
|
|
||||||
|
dac
|
||||||
|
---
|
||||||
|
|
||||||
|
This is a configuration example to use the DAC1 of the board. The DAC1
|
||||||
|
is attached to the PA4 pin (Arduino header D10).
|
||||||
|
|
||||||
|
This example is configured to work with the USBNSH instead of UART NSH, so
|
||||||
|
the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
On the console, type "ls /dev " and if the registration process goes fine,
|
||||||
|
you should see a device called "dac0". Now execute the app
|
||||||
|
dac put a value at the output.
|
||||||
|
|
||||||
|
ina219
|
||||||
|
------
|
||||||
|
|
||||||
|
This is a configuration example for the INA219 DC current sensor. This
|
||||||
|
sensor works with I2C, you need to do the next connections::
|
||||||
|
|
||||||
|
INA219 VIN -> Board 3.3V
|
||||||
|
INA219 GND -> Board GND
|
||||||
|
INA219 SCL -> Board PB6 (Arduino header D1)
|
||||||
|
INA219 SDA -> Board PB7 (Arduino header D0)
|
||||||
|
|
||||||
|
This example is configured to work with the USBNSH instead of UART NSH, so
|
||||||
|
the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
On the console, type "ls /dev " and if the registration process goes fine,
|
||||||
|
you should see a device called "ina219". Now execute the app
|
||||||
|
ina219 to see the ambient pressure value.
|
||||||
|
|
||||||
|
timer
|
||||||
|
-----
|
||||||
|
|
||||||
|
This configuration set the proper configuration to use the timer1 of the
|
||||||
|
board. This example is configured to work with the USBNSH instead of
|
||||||
|
UART NSH, so the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
On the console, type "ls /dev " and if the registration process goes fine,
|
||||||
|
you should see a device called "timer1".
|
||||||
|
|
||||||
|
mrf24j40-mac
|
||||||
|
------------
|
||||||
|
|
||||||
|
This configuration set the proper configuration to set the 802.15.4
|
||||||
|
communication layer with the MRF24J40 radio. This radio works with
|
||||||
|
SPI, you need to do the next connections::
|
||||||
|
|
||||||
|
MRF24J40 VCC -> Board 3.3V
|
||||||
|
MRF24J40 GND -> Board GND
|
||||||
|
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
|
||||||
|
MRF24J40 MISO -> Board PA6 (Arduino header D12)
|
||||||
|
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
|
||||||
|
MRF24J40 CS -> Board PA4 (Arduino header D10)
|
||||||
|
MRF24J40 INT -> Board PG12 (Arduino header D8)
|
||||||
|
|
||||||
|
This example is configured to work with the USBNSH instead of UART NSH,
|
||||||
|
so the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
Once you're on the console, you need to check if the initialization
|
||||||
|
process was fine. To do so, you need to type "ls /dev" and you should
|
||||||
|
see a device call "ieee0". At this point we need to set-up the network,
|
||||||
|
follow the next steps::
|
||||||
|
|
||||||
|
This is an example of how to configure a coordinator:
|
||||||
|
i8sak /dev/ieee0 startpan cd:ab
|
||||||
|
i8sak set chan 11
|
||||||
|
i8sak set saddr 42:01
|
||||||
|
i8sak acceptassoc
|
||||||
|
|
||||||
|
This is an example of how to configure the endpoint:
|
||||||
|
i8sak /dev/ieee0
|
||||||
|
i8sak set chan 11
|
||||||
|
i8sak set panid cd:ab
|
||||||
|
i8sak set saddr 42:02
|
||||||
|
i8sak set ep_saddr 42:01
|
||||||
|
i8sak assoc
|
||||||
|
|
||||||
|
mrf24j40-6lowpan
|
||||||
|
----------------
|
||||||
|
|
||||||
|
This configuration set the proper configuration to use 6lowpan protocol with the MRF24J40
|
||||||
|
radio. This radio works with SPI, you need to do the next connections::
|
||||||
|
|
||||||
|
MRF24J40 VCC -> Board 3.3V
|
||||||
|
MRF24J40 GND -> Board GND
|
||||||
|
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
|
||||||
|
MRF24J40 MISO -> Board PA6 (Arduino header D12)
|
||||||
|
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
|
||||||
|
MRF24J40 CS -> Board PA4 (Arduino header D10)
|
||||||
|
MRF24J40 INT -> Board PG12 (Arduino header D8)
|
||||||
|
|
||||||
|
This example is configured to work with the USBNSH instead of UART NSH, so
|
||||||
|
the console will be shown over the USB_OTG1 connector.
|
||||||
|
|
||||||
|
Once you're on the console, you need to check if the initialization process
|
||||||
|
was fine. To do so, you need to type "ls /dev" and you should see a device
|
||||||
|
call "ieee0". At this point we need to set-up the network, follow the next steps::
|
||||||
|
|
||||||
|
This is an example of how to configure a coordinator:
|
||||||
|
i8sak wpan0 startpan cd:ab
|
||||||
|
i8sak set chan 11
|
||||||
|
i8sak set saddr 42:01
|
||||||
|
i8sak acceptassoc
|
||||||
|
|
||||||
|
When the association was complete, you need to bring-up the network:
|
||||||
|
ifup wpan0
|
||||||
|
|
||||||
|
This is an example of how to configure the endpoint:
|
||||||
|
i8sak wpan0
|
||||||
|
i8sak set chan 11
|
||||||
|
i8sak set panid cd:ab
|
||||||
|
i8sak set saddr 42:02
|
||||||
|
i8sak set ep_saddr 42:01
|
||||||
|
i8sak assoc
|
||||||
|
|
||||||
|
When the association was complete, you need to bring-up the network:
|
||||||
|
ifup wpan0
|
||||||
|
|
||||||
|
If you execute the command "ifconfig", you will be able to see the info of the WPAN0 interface
|
||||||
|
and see the assigned IP. This interface can be use with an UDP or TCP server/client application.
|
||||||
@ -1,5 +1,6 @@
|
|||||||
README
|
=================
|
||||||
======
|
Olimex STM32-P207
|
||||||
|
=================
|
||||||
|
|
||||||
The NuttX configuration for the Olimex STM32-H405 is based on the configuration
|
The NuttX configuration for the Olimex STM32-H405 is based on the configuration
|
||||||
Olimex STM32-P207.
|
Olimex STM32-P207.
|
||||||
@ -24,5 +25,4 @@ The following peripherals are enabled in this configuration.
|
|||||||
- USB-FS-OTG: The console is running on the virtual serial port. Note that you
|
- USB-FS-OTG: The console is running on the virtual serial port. Note that you
|
||||||
have to press enter three times until NSH appears.
|
have to press enter three times until NSH appears.
|
||||||
|
|
||||||
- CAN: Built in app 'can' is enabled but not tested, since no CAN transceiver
|
- CAN:Built in app 'can' is enabled but not tested, since no CAN transceiver is on board.
|
||||||
is on board.
|
|
||||||
@ -1,5 +1,6 @@
|
|||||||
README
|
=================
|
||||||
======
|
Olimex STM32-H407
|
||||||
|
=================
|
||||||
|
|
||||||
The Olimex STM32-H407 configuration is based on
|
The Olimex STM32-H407 configuration is based on
|
||||||
stm32Fdiscovery and Olimex STM32-H405.
|
stm32Fdiscovery and Olimex STM32-H405.
|
||||||
@ -10,13 +11,6 @@ This release provides baseline for H407 12MHZ clock in include/board.h
|
|||||||
nsh - Only basic shell response tested on USART2
|
nsh - Only basic shell response tested on USART2
|
||||||
nsh_uext - Basic shell response tested on USART6 (UEXT)
|
nsh_uext - Basic shell response tested on USART6 (UEXT)
|
||||||
|
|
||||||
Development Environment
|
|
||||||
=======================
|
|
||||||
|
|
||||||
Either Linux or Cygwin on Windows can be used for the development environment.
|
|
||||||
The source has been built only using the GNU toolchain (see below). Other
|
|
||||||
toolchains will likely cause problems.
|
|
||||||
|
|
||||||
LEDs
|
LEDs
|
||||||
====
|
====
|
||||||
|
|
||||||
@ -37,6 +31,3 @@ or you can use USART6 exposed via UEXT connector.
|
|||||||
|
|
||||||
Olimex offers MOD-RS232 voltage level converter for the UEXT so it can be
|
Olimex offers MOD-RS232 voltage level converter for the UEXT so it can be
|
||||||
attached to computer serial port.
|
attached to computer serial port.
|
||||||
|
|
||||||
STM32-H407-specific Configuration Options
|
|
||||||
===============================================
|
|
||||||
@ -0,0 +1,574 @@
|
|||||||
|
=================
|
||||||
|
Olimex STM32-P207
|
||||||
|
=================
|
||||||
|
|
||||||
|
The NuttX configuration for the Olimex STM32-P407 is derives more or less
|
||||||
|
directly from the Olimex STM32-P207 board support. The P207 and P407 seem
|
||||||
|
to share the same board design. Other code comes from the STM3240G board
|
||||||
|
support (which has the same crystal and clocking) and from the STM32 F4
|
||||||
|
Discovery (which has the same STM32 part)
|
||||||
|
|
||||||
|
Board Support
|
||||||
|
=============
|
||||||
|
|
||||||
|
The following peripherals are available in this configuration.
|
||||||
|
|
||||||
|
- LEDs: Show the system status
|
||||||
|
|
||||||
|
- Buttons: TAMPER-button, WKUP-button, J1-Joystick (consists of RIGHT-,
|
||||||
|
UP-, LEFT-, DOWN-, and CENTER-button).
|
||||||
|
|
||||||
|
- ADC: ADC1 samples the red trim potentiometer AN_TR
|
||||||
|
Built in app 'adc' works.
|
||||||
|
|
||||||
|
- USB-FS-OTG: There is a USB-A-connector (host) connected to the full
|
||||||
|
speed STM32 OTG inputs.
|
||||||
|
|
||||||
|
- USB-HS-OTG: The other connector (device) is connected to the high speed
|
||||||
|
STM32 OTG inputs.
|
||||||
|
|
||||||
|
- CAN: Built in app 'can' works, but apart from that not really tested.
|
||||||
|
|
||||||
|
- Ethernet: Ping to other station on the network works.
|
||||||
|
|
||||||
|
- microSD: Not fully functional. See below.
|
||||||
|
|
||||||
|
- LCD: Nokia 6610. This is similar the Nokia 6100 LCD used on other
|
||||||
|
Olimex boards. There is a driver for that LCD at
|
||||||
|
Obsoleted/nuttx/drivers/lcd/nokia6100.c, however, it was removed
|
||||||
|
because it was not properly integrated. It uses a 9-bit SPI
|
||||||
|
interface which is difficult to get working properly.
|
||||||
|
|
||||||
|
- External SRAM: Support is included for the onboard SRAM. It uses SRAM
|
||||||
|
settings from another board that might need to be tweaked.
|
||||||
|
Difficult to test because the SRAM conflicts with both
|
||||||
|
RS232 ports.
|
||||||
|
|
||||||
|
- Other: Buzzer, Camera, Temperature sensor, audio have not been tested.
|
||||||
|
|
||||||
|
If so, then it requires a 9-bit
|
||||||
|
|
||||||
|
microSD Card Interface
|
||||||
|
======================
|
||||||
|
|
||||||
|
microSD Connector
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
----------------- ----------------- ------------------------
|
||||||
|
SD/MMC CONNECTOR BOARD GPIO CONFIGURATION(s
|
||||||
|
PIN SIGNAL SIGNAL (no remapping)
|
||||||
|
--- ------------- ----------------- -------------------------
|
||||||
|
1 DAT2/RES SD_D2/USART3_TX/ PC10 GPIO_SDIO_D2
|
||||||
|
SPI3_SCK
|
||||||
|
2 CD/DAT3/CS SD_D3/USART3_RX/ PC11 GPIO_SDIO_D3
|
||||||
|
SPI3_MISO
|
||||||
|
3 CMD/DI SD_CMD PD2 GPIO_SDIO_CMD
|
||||||
|
4 VDD N/A N/A
|
||||||
|
5 CLK/SCLK SD_CLK/SPI3_MOSI PC12 GPIO_SDIO_CK
|
||||||
|
6 VSS N/A N/A
|
||||||
|
7 DAT0/D0 SD_D0/DCMI_D2 PC8 GPIO_SDIO_D0
|
||||||
|
8 DAT1/RES SD_D1/DCMI_D3 PC9 GPIO_SDIO_D1
|
||||||
|
--- ------------- ----------------- -------------------------
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
1. DAT4, DAT4, DAT6, and DAT7 not connected.
|
||||||
|
2. There are no alternative pin selections.
|
||||||
|
3. There is no card detect (CD) GPIO input so we will not
|
||||||
|
sense if there is a card in the SD slot or not. This will
|
||||||
|
make usage very awkward.
|
||||||
|
|
||||||
|
Configuration
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Enabling SDIO-based MMC/SD support:
|
||||||
|
|
||||||
|
System Type->STM32 Peripheral Support::
|
||||||
|
|
||||||
|
CONFIG_STM32_SDIO=y : Enable SDIO support
|
||||||
|
CONFIG_STM32_DMA2=y : DMA2 is needed by the driver
|
||||||
|
|
||||||
|
Device Drivers -> MMC/SD Driver Support::
|
||||||
|
|
||||||
|
CONFIG_MMCSD=y : Enable MMC/SD support
|
||||||
|
CONFIG_MMSCD_NSLOTS=1 : One slot per driver instance
|
||||||
|
# CONFIG_MMCSD_HAVE_CARDDETECT is not set : No card-detect GPIO
|
||||||
|
# CONFIG_MMCSD_MMCSUPPORT is not set : Interferes with some SD cards
|
||||||
|
# CONFIG_MMCSD_SPI is not set : No SPI-based MMC/SD support
|
||||||
|
CONFIG_MMCSD_SDIO=y : SDIO-based MMC/SD support
|
||||||
|
CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 : Disable to keep things simple
|
||||||
|
CONFIG_SDIO_DMA=y : Use SDIO DMA
|
||||||
|
# CONFIG_SDIO_BLOCKSETUP is not set : (not implemented)
|
||||||
|
|
||||||
|
Library Routines::
|
||||||
|
|
||||||
|
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
|
||||||
|
|
||||||
|
Application Configuration -> NSH Library::
|
||||||
|
|
||||||
|
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
|
||||||
|
|
||||||
|
Using the SD card
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
1. Since there is no CD GPIO pin, the firmware sill not know if there is
|
||||||
|
a card in the SD slot or not. It will assume that there is and attempt
|
||||||
|
to mount the SD card on power-up. If there is no SD card in the card
|
||||||
|
slot, there will be a long delay during initialization as the firmware
|
||||||
|
attempts to query the non-existent card, timeout, and retry.
|
||||||
|
|
||||||
|
2. After booting, an SDIO device will appear as /dev/mmcsd0
|
||||||
|
|
||||||
|
3. If you try mounting an SD card with nothing in the slot, the
|
||||||
|
mount will fail::
|
||||||
|
|
||||||
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
|
||||||
|
nsh: mount: mount failed: 19
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
-------
|
||||||
|
2017-01-28: There is no card communication. All commands to the SD card timeout.
|
||||||
|
|
||||||
|
OTGFS Host
|
||||||
|
==========
|
||||||
|
|
||||||
|
..
|
||||||
|
STM32 USB OTG FS Host Board Support
|
||||||
|
-----------------------------------
|
||||||
|
A USB-A-connector (host) is connected to the full speed STM32 inputs. These
|
||||||
|
are the pins supported by the STM32:
|
||||||
|
|
||||||
|
PIN SIGNAL DIRECTION
|
||||||
|
---- ----------- ----------
|
||||||
|
PA8 OTG_FS_SOF SOF clock output
|
||||||
|
PA9 OTG_FS_VBUS VBUS input for device, Driven by external regulator by
|
||||||
|
host (not an alternate function)
|
||||||
|
PA10 OTG_FS_ID OTG ID pin (only needed in Dual mode)
|
||||||
|
PA11 OTG_FS_DM D- I/O
|
||||||
|
PA12 OTG_FS_DP D+ I/O
|
||||||
|
|
||||||
|
These are the signals available on-board:
|
||||||
|
|
||||||
|
OTG_FS_VBUS Used host VBUS sensing (device input only)
|
||||||
|
OTG_FS_DM Data minus
|
||||||
|
OTG_FS_DP Dta plus
|
||||||
|
|
||||||
|
NOTE: PA10 is currently used for DCMI_D1. The USB OTGFS host will
|
||||||
|
configure this as the ID input.
|
||||||
|
|
||||||
|
VBUS power is provided via an LM3526 and driven by USB_FS_VBUSON:
|
||||||
|
|
||||||
|
USB_FS_VBUSON PC2 power on output to LM3526 #ENA
|
||||||
|
USB_FS_FAULT PB10 overcurrent input from LM3526 FLAG_A.
|
||||||
|
|
||||||
|
STM32 USB OTG FS Host Driver Configuration
|
||||||
|
------------------------------------------
|
||||||
|
Pre-requisites
|
||||||
|
|
||||||
|
CONFIG_USBDEV - Enable USB device support
|
||||||
|
CONFIG_USBHOST - Enable USB host support
|
||||||
|
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
|
||||||
|
CONFIG_STM32_SYSCFG - Needed
|
||||||
|
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
|
||||||
|
|
||||||
|
STM32 Options:
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
|
||||||
|
Default 128 (512 bytes)
|
||||||
|
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
|
||||||
|
in 32-bit words. Default 96 (384 bytes)
|
||||||
|
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
|
||||||
|
words. Default 96 (384 bytes)
|
||||||
|
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
|
||||||
|
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
|
||||||
|
want to do that?
|
||||||
|
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
|
||||||
|
debug. Depends on CONFIG_DEBUG_FEATURES.
|
||||||
|
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
|
||||||
|
packets. Depends on CONFIG_DEBUG_FEATURES.
|
||||||
|
|
||||||
|
Olimex STM32 P407 Configuration:
|
||||||
|
|
||||||
|
CONFIG_STM32F_OLIMEXP407_PRIO - Priority of the USB host watier
|
||||||
|
thread (default 100).
|
||||||
|
CONFIG_STM32_OLIMEXP407_STACKSIZE - Stacksize of the USB host
|
||||||
|
waiter thread (default 1024)
|
||||||
|
|
||||||
|
Class Driver Configuration
|
||||||
|
--------------------------
|
||||||
|
Individual class drivers have additional configuration requirements. The
|
||||||
|
USB mass storage class, for example, requires FAT file system support.
|
||||||
|
|
||||||
|
CONFIG_USBHOST_MSC=y
|
||||||
|
|
||||||
|
CONFIG_FS_FAT=y
|
||||||
|
CONFIG_FAT_LCNAMES=y
|
||||||
|
CONFIG_FAT_LFN=y
|
||||||
|
CONFIG_FAT_MAXFNAME=32
|
||||||
|
|
||||||
|
This will enable USB HID keyboard support:
|
||||||
|
|
||||||
|
CONFIG_USBHOST_HIDKBD=y
|
||||||
|
CONFIG_HIDKBD_BUFSIZE=64
|
||||||
|
CONFIG_HIDKBD_DEFPRIO=50
|
||||||
|
CONFIG_HIDKBD_POLLUSEC=100000
|
||||||
|
CONFIG_HIDKBD_STACKSIZE=1024
|
||||||
|
|
||||||
|
And this will enable the USB keyboard example:
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_HIDKBD=y
|
||||||
|
CONFIG_EXAMPLES_HIDKBD_DEFPRIO=50
|
||||||
|
CONFIG_EXAMPLES_HIDKBD_DEVNAME="/dev/kbda"
|
||||||
|
CONFIG_EXAMPLES_HIDKBD_STACKSIZE=1024
|
||||||
|
|
||||||
|
STATUS: The MSC configurations seems fully functional. The HIDKBD seems rather
|
||||||
|
flaky. Sometimes the LEDs become very bright (indicating that it is being
|
||||||
|
swamped with interrupts). Data input is not clean with apps/examples/hidkbd:
|
||||||
|
There are missing characters and sometimes duplicated characters. This implies
|
||||||
|
some logic issues, probably in drivers/usbhost/usbhost_hidkbd.c, with polling
|
||||||
|
and data filtering.
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
Information Common to All Configurations
|
||||||
|
----------------------------------------
|
||||||
|
|
||||||
|
Each Olimex STM32-P407 configuration is maintained in a sub-directory and can be
|
||||||
|
selected as follow::
|
||||||
|
|
||||||
|
tools/configure.sh olimex-stm32-p407:<subdir>
|
||||||
|
|
||||||
|
Where <subdir> is one of the configuration sub-directories listed in the
|
||||||
|
following section.
|
||||||
|
|
||||||
|
Before building, make sure the PATH environment variable includes the
|
||||||
|
correct path to the directory than holds your toolchain binaries.
|
||||||
|
|
||||||
|
And then build NuttX by simply typing the following. At the conclusion of
|
||||||
|
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.::
|
||||||
|
|
||||||
|
make oldconfig
|
||||||
|
make
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. Serial Output
|
||||||
|
|
||||||
|
This configuraiont produces all of its test output on the serial
|
||||||
|
console. This configuration has USART3 enabled as a serial console.
|
||||||
|
This is the connector labeled RS232_2. This can easily be changed
|
||||||
|
by reconfiguring with 'make menuconfig'.
|
||||||
|
|
||||||
|
3. Toolchain
|
||||||
|
|
||||||
|
By default, the host platform is set to be Linux using the NuttX
|
||||||
|
buildroot toolchain. The host and/or toolchain selection can easily
|
||||||
|
be changed with 'make menuconfig'.
|
||||||
|
|
||||||
|
4. Note that CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG is enabled so
|
||||||
|
that the JTAG connection is not disconnected by the idle loop.
|
||||||
|
|
||||||
|
Configuration sub-directories
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
The <subdir> that is provided above as an argument to the tools/configure.sh
|
||||||
|
must be is one of the following.
|
||||||
|
|
||||||
|
dhtxx
|
||||||
|
-----
|
||||||
|
|
||||||
|
Configuration added by Abdelatif Guettouche for testing the the DHTxx
|
||||||
|
sensor. This configuration expects this setup::
|
||||||
|
|
||||||
|
DHTXX_PIN_OUTPUT PG9
|
||||||
|
DHTXX_PIN_INPUT PG9
|
||||||
|
|
||||||
|
The STM32 free-running timer is also required.
|
||||||
|
|
||||||
|
hidkbd
|
||||||
|
------
|
||||||
|
|
||||||
|
This is another NSH configuration that supports a USB HID Keyboard
|
||||||
|
device and the HID keyboard example at apps/examples/hidkbd.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2018-10-07: Not all keyboards will connect successfully. I have not
|
||||||
|
looked into the details but it may be that those keyboards are not
|
||||||
|
compatible with the driver (which only accepts "boot" keyboards).
|
||||||
|
Also, when typing input into the HID keyboard, characters are often
|
||||||
|
missing and sometimes duplicated. This is like some issue with the
|
||||||
|
read logic of drivers/usbhost_hidkbc.c.
|
||||||
|
|
||||||
|
kelf
|
||||||
|
----
|
||||||
|
|
||||||
|
This is a protected mode version of the apps/examples/elf test of
|
||||||
|
loadable ELF programs. This version is unique because the ELF programs
|
||||||
|
are loaded into user space.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. See build recommendations and instructions for combining the .hex
|
||||||
|
files under the section entitled "Protected Mode Build" above.
|
||||||
|
|
||||||
|
2. Unlike other versions of apps/examples/elf configurations, the test
|
||||||
|
ELF programs are not provided internally on a ROMFS or CROMFS file
|
||||||
|
system. This is due to the fact that those file systems are built in
|
||||||
|
user space and there is no mechanism in the build system to easily
|
||||||
|
get them into the kernel space.
|
||||||
|
|
||||||
|
Instead, the programs must be copied to a USB FLASH drive from your
|
||||||
|
host PC. The programs can be found at apps/examples/elf/tests/romfs.
|
||||||
|
All of those files should be copied to the USB FLASH drive. The
|
||||||
|
apps/example/elf will wait on power up until the USB FLASH drive
|
||||||
|
has been inserted and initialized.
|
||||||
|
|
||||||
|
kmodule
|
||||||
|
-------
|
||||||
|
|
||||||
|
This is a protected mode version of the apps/examples/module test of
|
||||||
|
loadable ELF kernel modules. This version is unique because the ELF
|
||||||
|
programs are loaded into the protected kernel space.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. See build recommendations and instructions for combining the .hex
|
||||||
|
files under the section entitled "Protected Mode Build" above.
|
||||||
|
|
||||||
|
2. Unlike other versions of apps/examples/module configurations, the test
|
||||||
|
ELF modules are not provided internally on a ROMFS or CROMFS file
|
||||||
|
system. This is due to the fact that those file systems are built in
|
||||||
|
user space and there is no mechanism in the build system to easily
|
||||||
|
get them into the kernel space.
|
||||||
|
|
||||||
|
Instead, the module(s) must be copied to a USB FLASH drive from your
|
||||||
|
host PC. The module(s) can be found at apps/examples/module/driver/fsroot.
|
||||||
|
All of those file(s) should be copied to the USB FLASH drive. Like the
|
||||||
|
kelf configuration, the logic in apps/example/module will wait on power
|
||||||
|
up until the USB FLASH drive has been inserted and initialized.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2018-08-07: After some struggle, the configuration appears to be
|
||||||
|
working correctly.
|
||||||
|
|
||||||
|
knsh
|
||||||
|
----
|
||||||
|
|
||||||
|
This is identical to the nsh configuration below except that NuttX
|
||||||
|
is built as a PROTECTED mode, monolithic module and the user applications
|
||||||
|
are built separately.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. See build recommendations and instructions for combining the .hex
|
||||||
|
files under the section entitled "Protected Mode Build" above.
|
||||||
|
|
||||||
|
module
|
||||||
|
------
|
||||||
|
|
||||||
|
A simple stripped down NSH configuration that was used for testing NuttX
|
||||||
|
OS modules using the test at apps/examples/module. Key difference from
|
||||||
|
the nsh configuration include these additions to the configuration file::
|
||||||
|
|
||||||
|
CONFIG_BOARDCTL_OS_SYMTAB=y
|
||||||
|
CONFIG_EXAMPLES_MODULE=y
|
||||||
|
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
|
||||||
|
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
|
||||||
|
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
|
||||||
|
CONFIG_FS_ROMFS=y
|
||||||
|
CONFIG_LIBC_ARCH_ELF=y
|
||||||
|
CONFIG_MODULE=y
|
||||||
|
CONFIG_LIBC_MODLIB=y
|
||||||
|
CONFIG_MODLIB_MAXDEPEND=2
|
||||||
|
CONFIG_MODLIB_ALIGN_LOG2=2
|
||||||
|
CONFIG_MODLIB_BUFFERSIZE=128
|
||||||
|
CONFIG_MODLIB_BUFFERINCR=32
|
||||||
|
|
||||||
|
The could be followed may be added for testing shared libraries in the
|
||||||
|
FLAT build using apps/examples/sotest (assuming that you also have SD
|
||||||
|
card support enabled and that the SD card is mount at /mnt/sdcard)::
|
||||||
|
|
||||||
|
CONFIG_LIBC_DLFCN=y
|
||||||
|
CONFIG_EXAMPLES_SOTEST=y
|
||||||
|
CONFIG_EXAMPLES_SOTEST_BINDIR="/mnt/sdcard"
|
||||||
|
|
||||||
|
NOTE: You must always have::
|
||||||
|
|
||||||
|
CONFIG_STM32_CCMEXCLUDE=y
|
||||||
|
|
||||||
|
because code cannot be executed from CCM memory.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2018-06-01: Configuration added. Works perfectly.
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
This is the NuttShell (NSH) using the NSH startup logic at
|
||||||
|
apps/examples/nsh
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. USB host support for USB FLASH sticks is enabled. See the notes
|
||||||
|
above under "OTGFS Host".
|
||||||
|
|
||||||
|
STATUS: I have seen this work with some FLASH sticks but not with
|
||||||
|
others. I have not studied the failure case carefully. They seem
|
||||||
|
to fail because the request is NAKed. That is not a failure, however,
|
||||||
|
that is normal behavior when the FLASH is not ready.
|
||||||
|
|
||||||
|
There have been other cases like this with the STM32 host drivers:
|
||||||
|
in the event of NAKs, other drivers retry and wait for the data. The
|
||||||
|
STM32 does not but returns the NAK failure immediately. My guess is
|
||||||
|
that there needs to be be some retry logic to the driver 100%
|
||||||
|
reliable.
|
||||||
|
|
||||||
|
2. Kernel Modules / Shared Libraries
|
||||||
|
|
||||||
|
I used this configuration for testing NuttX kernel modules in the
|
||||||
|
FLAT build with the following configuration additions to the
|
||||||
|
configuration file::
|
||||||
|
|
||||||
|
CONFIG_BOARDCTL_OS_SYMTAB=y
|
||||||
|
CONFIG_EXAMPLES_MODULE=y
|
||||||
|
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
|
||||||
|
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
|
||||||
|
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
|
||||||
|
CONFIG_FS_ROMFS=y
|
||||||
|
CONFIG_LIBC_ARCH_ELF=y
|
||||||
|
CONFIG_MODULE=y
|
||||||
|
CONFIG_LIBC_MODLIB=y
|
||||||
|
CONFIG_MODLIB_ALIGN_LOG2=2
|
||||||
|
CONFIG_MODLIB_BUFFERINCR=32
|
||||||
|
CONFIG_MODLIB_BUFFERSIZE=128
|
||||||
|
|
||||||
|
Add the following for testing shared libraries in the FLAT
|
||||||
|
build::
|
||||||
|
|
||||||
|
CONFIG_LIBC_DLFCN=y
|
||||||
|
CONFIG_EXAMPLES_SOTEST=y
|
||||||
|
CONFIG_EXAMPLES_SOTEST_BUILTINFS=y
|
||||||
|
CONFIG_EXAMPLES_SOTEST_DEVMINOR=1
|
||||||
|
CONFIG_EXAMPLES_SOTEST_DEVPATH="/dev/ram1"
|
||||||
|
|
||||||
|
zmodem
|
||||||
|
------
|
||||||
|
|
||||||
|
This configuration was used to test the zmodem utilities at
|
||||||
|
apps/system/zmodem. Two serial ports are used in this configuration:
|
||||||
|
|
||||||
|
1. USART6 (RS232_1) is the serial console (because it does not support
|
||||||
|
hardware flow control). It is configured 115200 8N1.
|
||||||
|
2. USART3 (RS232_2) is the zmodem port and does require that hardware
|
||||||
|
flow control be enabled for use. It is configured 9600 8N1.
|
||||||
|
|
||||||
|
On the target these will correspond to /dev/ttyS0 and /dev/ttyS1,
|
||||||
|
respectively.
|
||||||
|
|
||||||
|
It is possible to configure a system without hardware flow control and
|
||||||
|
using the same USART for both the serial console and for zmodem.
|
||||||
|
However, you would have to take extreme care with buffering and data
|
||||||
|
throughput considerations to assure that there is no Rx data overrun.
|
||||||
|
|
||||||
|
General usage instructions:
|
||||||
|
|
||||||
|
1. Common Setup::
|
||||||
|
|
||||||
|
[on target]
|
||||||
|
nsh> mount -t vfat /dev/sda /mnt
|
||||||
|
|
||||||
|
[on Linux host]
|
||||||
|
$ sudo stty -F /dev/ttyS0 9600
|
||||||
|
$ sudo stty -F /dev/ttyS0 crtscts *
|
||||||
|
$ sudo stty -F /dev/ttyS0 raw
|
||||||
|
$ sudo stty -F /dev/ttyS0
|
||||||
|
|
||||||
|
* Because hardware flow control will be enabled on the target side
|
||||||
|
in this configuration.
|
||||||
|
|
||||||
|
2. Host-to-Target File Transfer::
|
||||||
|
|
||||||
|
[on target]
|
||||||
|
nsh> rz
|
||||||
|
|
||||||
|
[on host]
|
||||||
|
$ sudo sz <filename> [-l nnnn] </dev/ttyS0 >/dev/ttyS0
|
||||||
|
|
||||||
|
Where <filename> is the file that you want to transfer. If -l nnnn is
|
||||||
|
not specified, then there will likely be packet buffer overflow errors.
|
||||||
|
nnnn should be set to a strictly less than CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE.
|
||||||
|
All testing was performed with -l 512.
|
||||||
|
|
||||||
|
If you are using the NuttX implementation of rz and sz on the Linux host,
|
||||||
|
then the last command simplifies to just::
|
||||||
|
|
||||||
|
[on host]
|
||||||
|
$ cp README.txt /tmp/.
|
||||||
|
$ sudo ./sz -d /dev/ttyS1 README.txt
|
||||||
|
|
||||||
|
Assuming that /dev/ttyS0 is the serial and /dev/ttyS1 is the zmodem port
|
||||||
|
on the Linux host as well. NOTE: By default, files will be transferred
|
||||||
|
to and from the /tmp directory only.
|
||||||
|
|
||||||
|
Refer to the README file at apps/examples/zmodem for detailed information
|
||||||
|
about building rz/sz for the host and about zmodem usage in general.
|
||||||
|
|
||||||
|
3. Target-to-Host File Transfer::
|
||||||
|
|
||||||
|
[on host]
|
||||||
|
$ rz </dev/ttyS0 >/dev/ttyS0
|
||||||
|
|
||||||
|
The transferred file will end up in the current directory.
|
||||||
|
|
||||||
|
If you are using the NuttX implementation of rz and sz on the Linux host,
|
||||||
|
then the last command simplifies to just::
|
||||||
|
|
||||||
|
[on host]
|
||||||
|
$ ./rz
|
||||||
|
|
||||||
|
The transferred file will lie in the /tmp directory.
|
||||||
|
|
||||||
|
Then on the target side::
|
||||||
|
|
||||||
|
[on target]
|
||||||
|
nsh sz <filename>
|
||||||
|
|
||||||
|
Where <filename> is the file that you want to transfer.
|
||||||
|
|
||||||
|
STATUS
|
||||||
|
======
|
||||||
|
|
||||||
|
2016-12-21: This board configuration was ported from the Olimex STM32 P207
|
||||||
|
port. Note that none of the above features have been verified. USB, CAN,
|
||||||
|
ADC, and Ethernet are disabled in the base NSH configuration until they
|
||||||
|
can be verified. These features should be functional but may required
|
||||||
|
some tweaks due to the different clock configurations. The Olimex STM32
|
||||||
|
P207 nsh/defconfig would be a good starting place for restoring these
|
||||||
|
feature configurations.
|
||||||
|
|
||||||
|
CCM memory is not included in the heap (CONFIG_STM32_CCMEXCLUDE=y) because
|
||||||
|
it does not support DMA, leaving only 128KiB for program usage.
|
||||||
|
|
||||||
|
2017-01-23: Added the knsh configuration and support for the PROTECTED
|
||||||
|
build mode.
|
||||||
|
|
||||||
|
2018-05-27: Added the zmodem configuration. Verified correct operation
|
||||||
|
with host-to-target transfers (using Linux sz command). There appears
|
||||||
|
to be a problem using the NuttX sz command running on the host???
|
||||||
|
|
||||||
|
2018-05-28: Verified correct operation with target-to-host transfers (using
|
||||||
|
Linux rz command). There appears to be a problem using the NuttX rz
|
||||||
|
command running on the host???
|
||||||
|
|
||||||
|
2018-06-01: Added the module configuration. Works perfectly.
|
||||||
@ -0,0 +1,82 @@
|
|||||||
|
=========
|
||||||
|
OMNIBUSF4
|
||||||
|
=========
|
||||||
|
|
||||||
|
"OmnibusF4" is not a product name per se, but rather a design spec
|
||||||
|
that many product vendors within the drone flight management unit
|
||||||
|
(FMU) community adhere to. The spec defines the major components, and
|
||||||
|
how those components are wired into the STM32F405RGT6 microcontroller.
|
||||||
|
|
||||||
|
Airbot is one such vendor, and they publish a schematic here:
|
||||||
|
|
||||||
|
http://bit.ly/obf4pro
|
||||||
|
|
||||||
|
Other software that supports the OmnibusF4 family include Betaflight,
|
||||||
|
iNAV, and many others. PX4 recently added support as well. No code
|
||||||
|
from any of those sources is included in this port.
|
||||||
|
|
||||||
|
Since OmnibusF4 is a drone FMU, most of its IO is already allocated to
|
||||||
|
FMU-specific tasks. As such, we don't need to make the board support
|
||||||
|
package as flexible as, say, an STM32F4 Discovery board.
|
||||||
|
|
||||||
|
..
|
||||||
|
The following are some of the committed IO pins. Most of the pins not
|
||||||
|
mentioned here are inaccessible, the details vary by board vendor:
|
||||||
|
|
||||||
|
io peripheral signal notes
|
||||||
|
==================================
|
||||||
|
XIN 8MHz crystal oscillator
|
||||||
|
|
||||||
|
PB0 TIM3 CH3 S1_OUT motor 1 PWM output
|
||||||
|
PB1 TIM3 CH4 S2_OUT motor 2 PWM output
|
||||||
|
PA3 TIM2 CH4 S3_OUT motor 3 PWM output
|
||||||
|
PA2 TIM2 CH3 S4_OUT motor 4 PWM output
|
||||||
|
PA1 TIM2 CH2 S5_OUT motor 5 PWM output
|
||||||
|
PA8 TIM1 CH4 S6_OUT motor 6 PWM output
|
||||||
|
|
||||||
|
PA4 SPI1 SPI1_NSS mpu6000
|
||||||
|
PA5 SPI1 SPI1_SCL
|
||||||
|
PA6 SPI1 SPI1_MISO
|
||||||
|
PA7 SPI1 SPI1_MOSI
|
||||||
|
|
||||||
|
PC4 GPIO GYRO_INT mpu6000 EXTI
|
||||||
|
|
||||||
|
PB10 UART3/I2C UART3_TX ttl UART tx or i2c_scl (used as console)
|
||||||
|
PB11 UART3/I2C UART3_RX ttl UART rx or i2c_sda (used as console)
|
||||||
|
|
||||||
|
PB9 RC_CH2 (rx pwm input)
|
||||||
|
PB8 RC_CH1 (rx pwm input)
|
||||||
|
PC9 RC_CH6 (rx pwm input)
|
||||||
|
PC8 RC_CH5 (rx pwm input)
|
||||||
|
PC7 RC_CH4 or USART6_RX (ttl)
|
||||||
|
PC6 RC_CH3 or USART6_TX (ttl)
|
||||||
|
|
||||||
|
PB7 GPIO SD_DET SD card detection pin (low when card inserted)
|
||||||
|
PB5 GPIO STAT LED output (active low)
|
||||||
|
PB4 GPIO BUZZER buzzer output (active low)
|
||||||
|
|
||||||
|
PD2 GPIO LED_STRIP one-wire interface for LED strips
|
||||||
|
|
||||||
|
PC12 SPI3 SPI3_MOSI bmp280 barometer (if populated) and/or max7456 OSD
|
||||||
|
PC11 SPI3 SPI3_MISO
|
||||||
|
PC10 SPI3 SPI3_SCL
|
||||||
|
PA15 GPIO SPI3_NSS OSD NSS
|
||||||
|
PB3 GPIO BARO_CS bmp280 NSS (if populated)
|
||||||
|
|
||||||
|
PA12 OTG USB_DP
|
||||||
|
PA11 OTG USB_DN
|
||||||
|
|
||||||
|
PA10 UART1 USART1_RX SBUS_IN (through inverter) or PPM
|
||||||
|
PA9 UART1 USART1_TX
|
||||||
|
|
||||||
|
PB15 SPI2 SPI2_MOSI sd/mmc card interface
|
||||||
|
PB14 SPI2 SPI2_MISO
|
||||||
|
PB13 SPI2 SPI2_SCLK
|
||||||
|
PB12 SPI2 SPI2_NSS
|
||||||
|
|
||||||
|
Build Instructions
|
||||||
|
==================
|
||||||
|
|
||||||
|
The boards/arm/stm32/omnibusf4/nsh/defconfig file creates a basic setup, and
|
||||||
|
includes drivers for all supported onboard chips. The console and
|
||||||
|
command prompt are sent to USART3.
|
||||||
@ -0,0 +1,842 @@
|
|||||||
|
=================
|
||||||
|
ST STM32140G-EVAL
|
||||||
|
=================
|
||||||
|
|
||||||
|
This page discusses issues unique to NuttX configurations for the
|
||||||
|
STMicro STM32140G-EVAL development board.
|
||||||
|
|
||||||
|
Ethernet
|
||||||
|
========
|
||||||
|
|
||||||
|
The Ethernet driver is configured to use the MII interface:
|
||||||
|
|
||||||
|
Board Jumper Settings::
|
||||||
|
|
||||||
|
Jumper Description
|
||||||
|
JP8 To enable MII, JP8 should not be fitted.
|
||||||
|
JP6 2-3: Enable MII interface mode
|
||||||
|
JP5 2-3: Provide 25 MHz clock for MII or 50 MHz clock for RMII by MCO at PA8
|
||||||
|
SB1 Not used with MII
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
====
|
||||||
|
|
||||||
|
The STM3240G-EVAL board has four LEDs labeled LD1, LD2, LD3 and LD4 on the
|
||||||
|
board.. These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/up_leds.c. The LEDs are used to encode OS-related\
|
||||||
|
events as follows::
|
||||||
|
|
||||||
|
SYMBOL Meaning LED1[1] LED2 LED3 LED4
|
||||||
|
------------------- ----------------------- ------- ------- ------- ------
|
||||||
|
LED_STARTED NuttX has been started ON OFF OFF OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF ON OFF OFF
|
||||||
|
LED_IRQSENABLED Interrupts enabled ON ON OFF OFF
|
||||||
|
LED_STACKCREATED Idle stack created OFF OFF ON OFF
|
||||||
|
LED_INIRQ In an interrupt[2] ON N/C N/C OFF
|
||||||
|
LED_SIGNAL In a signal handler[3] N/C ON N/C OFF
|
||||||
|
LED_ASSERTION An assertion failed ON ON N/C OFF
|
||||||
|
LED_PANIC The system has crashed N/C N/C N/C ON
|
||||||
|
LED_IDLE STM32 is is sleep mode (Optional, not used)
|
||||||
|
|
||||||
|
[1] If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot
|
||||||
|
and these LEDs will give you some indication of where the failure was
|
||||||
|
|
||||||
|
[2] The normal state is LED3 ON and LED1 faintly glowing. This faint glow
|
||||||
|
is because of timer interrupts that result in the LED being illuminated
|
||||||
|
on a small proportion of the time.
|
||||||
|
|
||||||
|
[3] LED2 may also flicker normally if signals are processed.
|
||||||
|
|
||||||
|
PWM
|
||||||
|
===
|
||||||
|
|
||||||
|
The STM3240G-Eval has no real on-board PWM devices, but the board can be
|
||||||
|
configured to output a pulse train using timer output pins. The following
|
||||||
|
pins have been use to generate PWM output (see board.h for some other
|
||||||
|
candidates):
|
||||||
|
|
||||||
|
TIM4 CH2. Pin PD13 is used by the FSMC (FSMC_A18) and is also connected
|
||||||
|
to the Motor Control Connector (CN5) just for this purpose. If FSMC is
|
||||||
|
not enabled, then FSMC_A18 will not be used (and will be tri-stated from
|
||||||
|
the LCD).
|
||||||
|
|
||||||
|
CONFIGURATION::
|
||||||
|
|
||||||
|
CONFIG_STM32_TIM4=y
|
||||||
|
CONFIG_PWM=n
|
||||||
|
CONFIG_PWM_PULSECOUNT=n
|
||||||
|
CONFIG_STM32_TIM4_PWM=y
|
||||||
|
CONFIG_STM32_TIM4_CHANNEL=2
|
||||||
|
|
||||||
|
ACCESS::
|
||||||
|
|
||||||
|
Daughter board Extension Connector, CN3, pin 32
|
||||||
|
Ground is available on CN3, pin1
|
||||||
|
|
||||||
|
NOTE: TIM4 hardware will not support pulse counting.
|
||||||
|
|
||||||
|
TIM8 CH4: Pin PC9 is used by the microSD card (MicroSDCard_D1) and I2S
|
||||||
|
(I2S_CKIN) but can be completely disconnected from both by opening JP16.
|
||||||
|
|
||||||
|
CONFIGURATION::
|
||||||
|
|
||||||
|
CONFIG_STM32_TIM8=y
|
||||||
|
CONFIG_PWM=n
|
||||||
|
CONFIG_PWM_PULSECOUNT=y
|
||||||
|
CONFIG_STM32_TIM8_PWM=y
|
||||||
|
CONFIG_STM32_TIM8_CHANNEL=4
|
||||||
|
|
||||||
|
ACCESS::
|
||||||
|
|
||||||
|
Daughterboard Extension Connector, CN3, pin 17
|
||||||
|
Ground is available on CN3, pin1
|
||||||
|
|
||||||
|
CAN
|
||||||
|
===
|
||||||
|
|
||||||
|
Connector 10 (CN10) is DB-9 male connector that can be used with CAN1 or CAN2.::
|
||||||
|
|
||||||
|
JP10 connects CAN1_RX or CAN2_RX to the CAN transceiver
|
||||||
|
JP3 connects CAN1_TX or CAN2_TX to the CAN transceiver
|
||||||
|
|
||||||
|
CAN signals are then available on CN10 pins:::
|
||||||
|
|
||||||
|
CN10 Pin 7 = CANH
|
||||||
|
CN10 Pin 2 = CANL
|
||||||
|
|
||||||
|
Mapping to STM32 GPIO pins::
|
||||||
|
|
||||||
|
PD0 = FSMC_D2 & CAN1_RX
|
||||||
|
PD1 = FSMC_D3 & CAN1_TX
|
||||||
|
PB13 = ULPI_D6 & CAN2_TX
|
||||||
|
PB5 = ULPI_D7 & CAN2_RX
|
||||||
|
|
||||||
|
FSMC SRAM
|
||||||
|
=========
|
||||||
|
|
||||||
|
On-board SRAM
|
||||||
|
-------------
|
||||||
|
|
||||||
|
A 16 Mbit SRAM is connected to the STM32F407IGH6 FSMC bus which shares the same
|
||||||
|
I/Os with the CAN1 bus. Jumper settings::
|
||||||
|
|
||||||
|
JP1: Connect PE4 to SRAM as A20
|
||||||
|
JP2: onnect PE3 to SRAM as A19
|
||||||
|
|
||||||
|
JP3 and JP10 must not be fitted for SRAM and LCD application. JP3 and JP10
|
||||||
|
select CAN1 or CAN2 if fitted; neither if not fitted.
|
||||||
|
|
||||||
|
The on-board SRAM can be configured by setting::
|
||||||
|
|
||||||
|
CONFIG_STM32_FSMC=y
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM=y
|
||||||
|
CONFIG_HEAP2_BASE=0x64000000
|
||||||
|
CONFIG_HEAP2_SIZE=2097152
|
||||||
|
CONFIG_MM_REGIONS=2 (or =3, see below)
|
||||||
|
|
||||||
|
Configuration Options
|
||||||
|
---------------------
|
||||||
|
Internal SRAM is available in all members of the STM32 family. The F4 family
|
||||||
|
also contains internal CCM SRAM. This SRAM is different because it cannot
|
||||||
|
be used for DMA. So if DMA needed, then the following should be defined
|
||||||
|
to exclude CCM SRAM from the heap::
|
||||||
|
|
||||||
|
CONFIG_STM32_CCMEXCLUDE : Exclude CCM SRAM from the HEAP
|
||||||
|
|
||||||
|
In addition to internal SRAM, SRAM may also be available through the FSMC.
|
||||||
|
In order to use FSMC SRAM, the following additional things need to be
|
||||||
|
present in the NuttX configuration file::
|
||||||
|
|
||||||
|
CONFIG_STM32_FSMC=y : Enables the FSMC
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM=y : Indicates that SRAM is available via the
|
||||||
|
FSMC (as opposed to an LCD or FLASH).
|
||||||
|
CONFIG_HEAP2_BASE : The base address of the SRAM in the FSMC
|
||||||
|
address space
|
||||||
|
CONFIG_HEAP2_SIZE : The size of the SRAM in the FSMC
|
||||||
|
address space
|
||||||
|
CONFIG_MM_REGIONS : Must be set to a large enough value to
|
||||||
|
include the FSMC SRAM
|
||||||
|
|
||||||
|
SRAM Configurations
|
||||||
|
-------------------
|
||||||
|
There are 4 possible SRAM configurations::
|
||||||
|
|
||||||
|
Configuration 1. System SRAM (only)
|
||||||
|
CONFIG_MM_REGIONS == 1
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM NOT defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE defined
|
||||||
|
Configuration 2. System SRAM and CCM SRAM
|
||||||
|
CONFIG_MM_REGIONS == 2
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM NOT defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE NOT defined
|
||||||
|
Configuration 3. System SRAM and FSMC SRAM
|
||||||
|
CONFIG_MM_REGIONS == 2
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE defined
|
||||||
|
Configuration 4. System SRAM, CCM SRAM, and FSMC SRAM
|
||||||
|
CONFIG_MM_REGIONS == 3
|
||||||
|
CONFIG_STM32_ETXERNAL_RAM defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE NOT defined
|
||||||
|
|
||||||
|
I/O Expanders
|
||||||
|
=============
|
||||||
|
|
||||||
|
The STM3240G-EVAL has two STMPE811QTR I/O expanders on board both connected to
|
||||||
|
the STM32 via I2C1. They share a common interrupt line: PI2.
|
||||||
|
|
||||||
|
STMPE811 U24, I2C address 0x41 (7-bit)
|
||||||
|
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
STPE11 PIN BOARD SIGNAL BOARD CONNECTION
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
Y- TouchScreen_Y- LCD Connector XL
|
||||||
|
X- TouchScreen_X- LCD Connector XR
|
||||||
|
Y+ TouchScreen_Y+ LCD Connector XD
|
||||||
|
X+ TouchScreen_X+ LCD Connector XU
|
||||||
|
IN3 EXP_IO9
|
||||||
|
IN2 EXP_IO10
|
||||||
|
IN1 EXP_IO11
|
||||||
|
IN0 EXP_IO12
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
|
||||||
|
STMPE811 U29, I2C address 0x44 (7-bit)
|
||||||
|
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
STPE11 PIN BOARD SIGNAL BOARD CONNECTION
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
Y- EXP_IO1
|
||||||
|
X- EXP_IO2
|
||||||
|
Y+ EXP_IO3
|
||||||
|
X+ EXP_IO4
|
||||||
|
IN3 EXP_IO5
|
||||||
|
IN2 EXP_IO6
|
||||||
|
IN1 EXP_IO7
|
||||||
|
IN0 EXP_IO8
|
||||||
|
====== ==== ================ ============================================
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
Each STM3240G-EVAL configuration is maintained in a sub-directory and
|
||||||
|
can be selected as follow::
|
||||||
|
|
||||||
|
tools/configure.sh stm3240g-eval:<subdir>
|
||||||
|
|
||||||
|
Where <subdir> is one of the following:
|
||||||
|
|
||||||
|
dhcpd
|
||||||
|
-----
|
||||||
|
|
||||||
|
This builds the DHCP server using the apps/examples/dhcpd application
|
||||||
|
(for execution from FLASH.) See apps/examples/README.txt for information
|
||||||
|
about the dhcpd example.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. The server address is 10.0.0.1 and it serves IP addresses in the range
|
||||||
|
10.0.0.2 through 10.0.0.17 (all of which, of course, are configurable).
|
||||||
|
|
||||||
|
3. Default build environment (also easily reconfigured)::
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y
|
||||||
|
|
||||||
|
discover
|
||||||
|
--------
|
||||||
|
|
||||||
|
This configuration exercises netutils/discover utility using
|
||||||
|
apps/examples/discover. This example initializes and starts the UDP
|
||||||
|
discover daemon. This daemon is useful for discovering devices in
|
||||||
|
local networks, especially with DHCP configured devices. It listens
|
||||||
|
for UDP broadcasts which also can include a device class so that
|
||||||
|
groups of devices can be discovered. It is also possible to address all
|
||||||
|
classes with a kind of broadcast discover.
|
||||||
|
|
||||||
|
Configuration settings that you may need to change for your
|
||||||
|
environment::
|
||||||
|
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y - GNU EABI toolchain for Linux
|
||||||
|
CONFIG_EXAMPLES_DISCOVER_DHCPC=y - DHCP Client
|
||||||
|
CONFIG_EXAMPLES_DISCOVER_IPADDR - (not defined)
|
||||||
|
CONFIG_EXAMPLES_DISCOVER_DRIPADDR - Router IP address
|
||||||
|
|
||||||
|
NOTE: This configuration uses to the kconfig-mconf configuration tool to
|
||||||
|
control the configuration. See the section entitled "NuttX Configuration
|
||||||
|
Tool" in the top-level README.txt file.
|
||||||
|
|
||||||
|
fb
|
||||||
|
--
|
||||||
|
|
||||||
|
A simple NSH configuration used for some basic (non-graphic) debug of
|
||||||
|
the framebuffer character driver at drivers/video/fb.c. NOTE that
|
||||||
|
the STM3240G-EVAL LCD driver does not support a framebuffer! It
|
||||||
|
interfaces with the LCD through a parallel FSMC interface. This
|
||||||
|
configuration uses the LCD framebuffer front end at
|
||||||
|
drivers/lcd/lcd_framebuffer to convert the LCD interface into a
|
||||||
|
compatible framebuffer interface.
|
||||||
|
|
||||||
|
This examples supports the framebuffer test at apps/examples/fb. That
|
||||||
|
test simply draws a pattern into the framebuffer and updates the LCD.
|
||||||
|
|
||||||
|
This example also supports the pdcurses library at apps/graphics/pdcurses
|
||||||
|
and the demo programs at apps/examples/pdcurses. This is a good test of
|
||||||
|
the use of the framebuffer driver in an application. Many of the
|
||||||
|
pdcurses demos requires user interaction via a mouse, keyboard, or
|
||||||
|
joystick. No input devices are currently present in the configuration
|
||||||
|
so no such interaction is possible.
|
||||||
|
|
||||||
|
The STM3240G-EVAL does provide a on-board discrete joystick (djoystick)
|
||||||
|
that could be used for this interaction. However, those discrete inputs
|
||||||
|
do not go directly to the STM32 but rather go indirectly through an I/O
|
||||||
|
expander. I just have not had the motivation to deal with that yet.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2017-09-17: This configuration appears to be fully functional.
|
||||||
|
2017-11-25: Non-interactive pdcurses examples added.
|
||||||
|
|
||||||
|
knxwm
|
||||||
|
-----
|
||||||
|
|
||||||
|
This is identical to the nxwm configuration below except that NuttX
|
||||||
|
is built as a kernel-mode, monolithic module and the user applications
|
||||||
|
are built separately. Is is recommended to use a special make command;
|
||||||
|
not just 'make' but make with the following two arguments::
|
||||||
|
|
||||||
|
make pass1 pass2
|
||||||
|
|
||||||
|
In the normal case (just 'make'), make will attempt to build both user-
|
||||||
|
and kernel-mode blobs more or less interleaved. This actual works!
|
||||||
|
However, for me it is very confusing so I prefer the above make command:
|
||||||
|
Make the user-space binaries first (pass1), then make the kernel-space
|
||||||
|
binaries (pass2)
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. This is the default platform/toolchain in the configuration:
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y : Windows
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
|
||||||
|
CONFIG_ARM_TOOLCHAIN_BUILDROOT=y : NuttX EABI buildroot toolchain
|
||||||
|
CONFIG_ARCH_SIZET_LONG=y : size_t is long (maybe?)
|
||||||
|
|
||||||
|
This is easily changed by modifying the configuration.
|
||||||
|
|
||||||
|
3. In addition to the protected mode build, this NxWM configuration
|
||||||
|
differences from the nxwm configuration in that:
|
||||||
|
|
||||||
|
a. Networking is disabled. There are issues with some of the network-
|
||||||
|
related NSH commands and with Telnet in the protected build (see the
|
||||||
|
top-level TODO file). Without these NSH commands, there is no use
|
||||||
|
for networking in this configuration.
|
||||||
|
|
||||||
|
b. The NxTerm windows are disabled. There are also issues with the
|
||||||
|
NxTerm build now.
|
||||||
|
|
||||||
|
NOTE: Those issues have been resolved. However, this configuration
|
||||||
|
has not yet be re-verified with NxTerm enabled.
|
||||||
|
|
||||||
|
c. The initialization sequence is quite different: NX and the
|
||||||
|
touchscreen are initialized in kernel mode by logic in this src/
|
||||||
|
directory before the NxWM application is started.
|
||||||
|
|
||||||
|
4. At the end of the build, there will be several files in the top-level
|
||||||
|
NuttX build directory:
|
||||||
|
|
||||||
|
PASS1:
|
||||||
|
nuttx_user.elf - The pass1 user-space ELF file
|
||||||
|
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
||||||
|
User.map - Symbols in the user-space ELF file
|
||||||
|
|
||||||
|
PASS2:
|
||||||
|
nuttx - The pass2 kernel-space ELF file
|
||||||
|
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
||||||
|
System.map - Symbols in the kernel-space ELF file
|
||||||
|
|
||||||
|
5. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
|
||||||
|
load the .hex files into FLASH, then you need to combine the two hex
|
||||||
|
files into a single .hex file. Here is how you can do that.
|
||||||
|
|
||||||
|
a. The 'tail' of the nuttx.hex file should look something like this
|
||||||
|
(with my comments added):
|
||||||
|
|
||||||
|
$ tail nuttx.hex
|
||||||
|
# 00, data records
|
||||||
|
...
|
||||||
|
:10 9DC0 00 01000000000800006400020100001F0004
|
||||||
|
:10 9DD0 00 3B005A0078009700B500D400F300110151
|
||||||
|
:08 9DE0 00 30014E016D0100008D
|
||||||
|
# 05, Start Linear Address Record
|
||||||
|
:04 0000 05 0800 0419 D2
|
||||||
|
# 01, End Of File record
|
||||||
|
:00 0000 01 FF
|
||||||
|
|
||||||
|
Use an editor such as vi to remove the 05 and 01 records.
|
||||||
|
|
||||||
|
b. The 'head' of the nuttx_user.hex file should look something like
|
||||||
|
this (again with my comments added):
|
||||||
|
|
||||||
|
$ head nuttx_user.hex
|
||||||
|
# 04, Extended Linear Address Record
|
||||||
|
:02 0000 04 0801 F1
|
||||||
|
# 00, data records
|
||||||
|
:10 8000 00 BD89 01084C800108C8110208D01102087E
|
||||||
|
:10 8010 00 0010 00201C1000201C1000203C16002026
|
||||||
|
:10 8020 00 4D80 01085D80010869800108ED83010829
|
||||||
|
...
|
||||||
|
|
||||||
|
Nothing needs to be done here. The nuttx_user.hex file should
|
||||||
|
be fine.
|
||||||
|
|
||||||
|
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
||||||
|
file to produce a single combined hex file:
|
||||||
|
|
||||||
|
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
||||||
|
|
||||||
|
Then use the combined.hex file with the STM32 ST-Link tool. If
|
||||||
|
you do this a lot, you will probably want to invest a little time
|
||||||
|
to develop a tool to automate these steps.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2014-10-11: This worked at one time, but today I am getting a
|
||||||
|
failure inside of the GCC library. This occurred with the
|
||||||
|
computations at the end of touchscreen calibration. The
|
||||||
|
NuttX code seems to be working correctly, but there is some
|
||||||
|
problem with how the GCC integer math is hooked in??? I did
|
||||||
|
not dig into this very deeply.
|
||||||
|
|
||||||
|
nettest
|
||||||
|
-------
|
||||||
|
|
||||||
|
This configuration directory may be used to verify networking performance
|
||||||
|
using the STM32's Ethernet controller. It uses apps/examples/nettest to exercise the
|
||||||
|
TCP/IP network.::
|
||||||
|
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
CONFIG_EXAMPLES_NETTEST_SERVER=n : Target is configured as the client
|
||||||
|
CONFIG_EXAMPLES_NETTEST_PERFORMANCE=y : Only network performance is verified.
|
||||||
|
CONFIG_EXAMPLES_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2) : Target side is IP: 10.0.0.2
|
||||||
|
CONFIG_EXAMPLES_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host side is IP: 10.0.0.1
|
||||||
|
CONFIG_EXAMPLES_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) : Server address used by which ever is client.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh. The
|
||||||
|
Configuration enables both the serial and telnet NSH interfaces.::
|
||||||
|
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
CONFIG_NSH_DHCPC=n : DHCP is disabled
|
||||||
|
CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2) : Target IP address 10.0.0.2
|
||||||
|
CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host IP address 10.0.0.1
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. This example assumes that a network is connected. During its
|
||||||
|
initialization, it will try to negotiate the link speed. If you have
|
||||||
|
no network connected when you reset the board, there will be a long
|
||||||
|
delay (maybe 30 seconds?) before anything happens. That is the timeout
|
||||||
|
before the networking finally gives up and decides that no network is
|
||||||
|
available.
|
||||||
|
|
||||||
|
3. This example supports the ADC test (apps/examples/adc) but this must
|
||||||
|
be manually enabled by selecting::
|
||||||
|
|
||||||
|
CONFIG_ADC=y : Enable the generic ADC infrastructure
|
||||||
|
CONFIG_STM32_ADC3=y : Enable ADC3
|
||||||
|
CONFIG_STM32_TIM1=y : Enable Timer 1
|
||||||
|
CONFIG_STM32_TIM1_ADC=y : Indicate that timer 1 will be used to trigger an ADC
|
||||||
|
CONFIG_STM32_TIM1_ADC3=y : Assign timer 1 to drive ADC3 sampling
|
||||||
|
CONFIG_STM32_ADC3_SAMPLE_FREQUENCY=100 : Select a sampling frequency
|
||||||
|
|
||||||
|
See also apps/examples/README.txt
|
||||||
|
|
||||||
|
General debug for analog devices (ADC/DAC):
|
||||||
|
|
||||||
|
CONFIG_DEBUG_ANALOG
|
||||||
|
|
||||||
|
4. This example supports the PWM test (apps/examples/pwm) but this must
|
||||||
|
be manually enabled by selecting eeither::
|
||||||
|
|
||||||
|
CONFIG_PWM=y : Enable the generic PWM infrastructure
|
||||||
|
CONFIG_PWM_PULSECOUNT=n : Disable to support for TIM1/8 pulse counts
|
||||||
|
CONFIG_STM32_TIM4=y : Enable TIM4
|
||||||
|
CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output
|
||||||
|
CONFIG_STM32_TIM4_CHANNEL=2 : Select output on TIM4, channel 2
|
||||||
|
|
||||||
|
If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 32.
|
||||||
|
Ground is available on CN3, pin1.
|
||||||
|
|
||||||
|
Or..
|
||||||
|
|
||||||
|
CONFIG_PWM=y : Enable the generic PWM infrastructure
|
||||||
|
CONFIG_PWM_PULSECOUNT=y : Enable to support for TIM1/8 pulse counts
|
||||||
|
CONFIG_STM32_TIM8=y : Enable TIM8
|
||||||
|
CONFIG_STM32_TIM8_PWM=y : Use TIM8 to generate PWM output
|
||||||
|
CONFIG_STM32_TIM8_CHANNEL=4 : Select output on TIM8, channel 4
|
||||||
|
|
||||||
|
If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 17
|
||||||
|
Ground is available on CN23 pin1.
|
||||||
|
|
||||||
|
See also include/board.h and apps/examples/README.txt
|
||||||
|
|
||||||
|
Special PWM-only debug options:
|
||||||
|
|
||||||
|
CONFIG_DEBUG_PWM_INFO
|
||||||
|
|
||||||
|
5. This example supports the CAN loopback test (apps/examples/can) but this
|
||||||
|
must be manually enabled by selecting::
|
||||||
|
|
||||||
|
CONFIG_CAN=y : Enable the generic CAN infrastructure
|
||||||
|
CONFIG_CAN_EXTID=y or n : Enable to support extended ID frames
|
||||||
|
CONFIG_STM32_CAN1=y : Enable CAN1
|
||||||
|
CONFIG_CAN_LOOPBACK=y : Enable CAN loopback mode
|
||||||
|
|
||||||
|
See also apps/examples/README.txt
|
||||||
|
|
||||||
|
Special CAN-only debug options:
|
||||||
|
|
||||||
|
CONFIG_DEBUG_CAN_INFO
|
||||||
|
CONFIG_STM32_CAN_REGDEBUG
|
||||||
|
|
||||||
|
6. This example can support an FTP client. In order to build in FTP client
|
||||||
|
support simply uncomment the following lines in the defconfig file (before
|
||||||
|
configuring) or in the .config file (after configuring):
|
||||||
|
|
||||||
|
CONFIG_NETUTILS_FTPC=y
|
||||||
|
CONFIG_EXAMPLES_FTPC=y
|
||||||
|
|
||||||
|
7. This example can support an FTP server. In order to build in FTP server
|
||||||
|
support simply add the following lines in the defconfig file (before
|
||||||
|
configuring) or in the .config file (after configuring):
|
||||||
|
|
||||||
|
CONFIG_NETUTILS_FTPD=y
|
||||||
|
CONFIG_EXAMPLES_FTPD=y
|
||||||
|
|
||||||
|
8. This example supports the watchdog timer test (apps/examples/watchdog)
|
||||||
|
but this must be manually enabled by selecting:
|
||||||
|
|
||||||
|
CONFIG_WATCHDOG=y : Enables watchdog timer driver support
|
||||||
|
CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR
|
||||||
|
CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both)
|
||||||
|
|
||||||
|
The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result,
|
||||||
|
has a maximum timeout value of 49 milliseconds. For WWDG watchdog, you
|
||||||
|
should also add the following to the configuration file:
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20
|
||||||
|
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49
|
||||||
|
|
||||||
|
The IWDG timer has a range of about 35 seconds and should not be an issue.
|
||||||
|
|
||||||
|
9. Adding LCD and graphics support:
|
||||||
|
|
||||||
|
defconfig (nuttx/.config):
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_nx=y : Pick one or more
|
||||||
|
CONFIG_EXAMPLES_nxhello=y :
|
||||||
|
CONFIG_EXAMPLES_nximage :
|
||||||
|
CONFIG_EXAMPLES_nxlines :
|
||||||
|
|
||||||
|
CONFIG_STM32_FSMC=y : FSMC support is required for the LCD
|
||||||
|
CONFIG_NX=y : Enable graphics support
|
||||||
|
CONFIG_MM_REGIONS=3 : When FSMC is enabled, so is the on-board SRAM memory region
|
||||||
|
|
||||||
|
10. USB OTG FS Device or Host Support
|
||||||
|
|
||||||
|
CONFIG_USBDEV : Enable USB device support, OR
|
||||||
|
CONFIG_USBHOST : Enable USB host support
|
||||||
|
CONFIG_STM32_OTGFS : Enable the STM32 USB OTG FS block
|
||||||
|
CONFIG_STM32_SYSCFG : Needed
|
||||||
|
CONFIG_SCHED_WORKQUEUE : Worker thread support is required
|
||||||
|
|
||||||
|
11. USB OTG FS Host Support. The following changes will enable support for
|
||||||
|
a USB host on the STM32F4Discovery, including support for a mass storage
|
||||||
|
class driver::
|
||||||
|
|
||||||
|
CONFIG_USBDEV=n : Make sure the USB device support is disabled
|
||||||
|
CONFIG_USBHOST=y : Enable USB host support
|
||||||
|
CONFIG_STM32_OTGFS=y : Enable the STM32 USB OTG FS block
|
||||||
|
CONFIG_STM32_SYSCFG=y : Needed for all USB OTF FS support
|
||||||
|
CONFIG_SCHED_WORKQUEUE=y : Worker thread support is required for the mass
|
||||||
|
storage class driver.
|
||||||
|
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
|
||||||
|
is needed for NSH
|
||||||
|
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
|
||||||
|
|
||||||
|
With those changes, you can use NSH with a FLASH pen driver as shown
|
||||||
|
belong. Here NSH is started with nothing in the USB host slot::
|
||||||
|
|
||||||
|
NuttShell (NSH) NuttX-x.yy
|
||||||
|
nsh> ls /dev
|
||||||
|
/dev:
|
||||||
|
console
|
||||||
|
null
|
||||||
|
ttyS0
|
||||||
|
|
||||||
|
After inserting the FLASH drive, the /dev/sda appears and can be
|
||||||
|
mounted like this::
|
||||||
|
|
||||||
|
nsh> ls /dev
|
||||||
|
/dev:
|
||||||
|
console
|
||||||
|
null
|
||||||
|
sda
|
||||||
|
ttyS0
|
||||||
|
nsh> mount -t vfat /dev/sda /mnt/stuff
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
|
||||||
|
And files on the FLASH can be manipulated to standard interfaces:
|
||||||
|
|
||||||
|
nsh> echo "This is a test" >/mnt/stuff/atest.txt
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
-rw-rw-rw- 16 atest.txt
|
||||||
|
nsh> cat /mnt/stuff/atest.txt
|
||||||
|
This is a test
|
||||||
|
nsh> cp /mnt/stuff/filea.c fileb.c
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
-rw-rw-rw- 16 atest.txt
|
||||||
|
-rw-rw-rw- 16236 fileb.c
|
||||||
|
|
||||||
|
To prevent data loss, don't forget to un-mount the FLASH drive
|
||||||
|
before removing it:
|
||||||
|
|
||||||
|
nsh> umount /mnt/stuff
|
||||||
|
|
||||||
|
12. By default, this configuration supports /dev/random using the STM32's
|
||||||
|
RNG hardware. This can be disabled as follows::
|
||||||
|
|
||||||
|
-CONFIG_STM32_RNG=y
|
||||||
|
+CONFIG_STM32_RNG=n
|
||||||
|
|
||||||
|
-CONFIG_DEV_RANDOM=y
|
||||||
|
+CONFIG_DEV_RANDOM=n
|
||||||
|
|
||||||
|
13. This configuration requires that jumper JP22 be set to enable RS-232
|
||||||
|
operation.
|
||||||
|
|
||||||
|
nsh2
|
||||||
|
-----
|
||||||
|
|
||||||
|
This is an alternative NSH configuration. One limitation of the STM3240G-EVAL
|
||||||
|
board is that you cannot have both a UART-based NSH console and SDIO support.
|
||||||
|
The nsh2 differs from the nsh configuration in the following ways::
|
||||||
|
|
||||||
|
-CONFIG_STM32_USART3=y : USART3 is disabled
|
||||||
|
+CONFIG_STM32_USART3=n
|
||||||
|
|
||||||
|
-CONFIG_STM32_SDIO=n : SDIO is enabled
|
||||||
|
+CONFIG_STM32_SDIO=y
|
||||||
|
|
||||||
|
Logically, these are the only differences: This configuration has SDIO (and
|
||||||
|
the SD card) enabled and the serial console disabled. There is ONLY a
|
||||||
|
Telnet console!.
|
||||||
|
|
||||||
|
There are some special settings to make life with only a Telnet::
|
||||||
|
|
||||||
|
CONFIG_RAMLOG=y - Enable the RAM-based logging feature.
|
||||||
|
CONFIG_CONSOLE_SYSLOG=y - Use the RAM logger as the default console.
|
||||||
|
This means that any console output from non-Telnet threads will
|
||||||
|
go into the circular buffer in RAM.
|
||||||
|
CONFIG_RAMLOG_SYSLOG - This enables the RAM-based logger as the
|
||||||
|
system logger. This means that (1) in addition to the console
|
||||||
|
output from other tasks, ALL of the debug output will also to
|
||||||
|
to the circular buffer in RAM, and (2) NSH will now support a
|
||||||
|
command called 'dmesg' that can be used to dump the RAM log.
|
||||||
|
|
||||||
|
There are a few other configuration differences as necessary to support
|
||||||
|
this different device configuration. Just the do the 'diff' if you are
|
||||||
|
curious.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. See the notes for the nsh configuration. Most also apply to the nsh2
|
||||||
|
configuration. Like the nsh configuration, this configuration can
|
||||||
|
be modified to support a variety of additional tests.
|
||||||
|
|
||||||
|
3. RS-232 is disabled, but Telnet is still available for use as a console.
|
||||||
|
Since RS-232 and SDIO use the same pins (one controlled by JP22), RS232
|
||||||
|
and SDIO cannot be used concurrently.
|
||||||
|
|
||||||
|
4. This configuration requires that jumper JP22 be set to enable SDIO
|
||||||
|
operation. To enable MicroSD Card, which shares same I/Os with RS-232,
|
||||||
|
JP22 is not fitted.
|
||||||
|
|
||||||
|
5. In order to use SDIO without overruns, DMA must be used. The STM32 F4
|
||||||
|
has 192Kb of SRAM in two banks: 112Kb of "system" SRAM located at
|
||||||
|
0x2000:0000 and 64Kb of "CCM" SRAM located at 0x1000:0000. It appears
|
||||||
|
that you cannot perform DMA from CCM SRAM. The work around that I have now
|
||||||
|
is simply to omit the 64Kb of CCM SRAM from the heap so that all memory is
|
||||||
|
allocated from System SRAM. This is done by setting:
|
||||||
|
|
||||||
|
CONFIG_MM_REGIONS=1
|
||||||
|
|
||||||
|
Then DMA works fine. The downside is, of course, is that we lose 64Kb
|
||||||
|
of precious SRAM.
|
||||||
|
|
||||||
|
6. Another SDIO/DMA issue. This one is probably a software bug. This is
|
||||||
|
the bug as stated in the TODO list:
|
||||||
|
|
||||||
|
"If you use a large I/O buffer to access the file system, then the
|
||||||
|
MMCSD driver will perform multiple block SD transfers. With DMA
|
||||||
|
ON, this seems to result in CRC errors detected by the hardware
|
||||||
|
during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_LIMIT=1"
|
||||||
|
|
||||||
|
For this reason, CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 appears in the defconfig
|
||||||
|
file.
|
||||||
|
|
||||||
|
7. Another DMA-related concern. I see this statement in the reference
|
||||||
|
manual: "The burst configuration has to be selected in order to respect
|
||||||
|
the AHB protocol, where bursts must not cross the 1 KB address boundary
|
||||||
|
because the minimum address space that can be allocated to a single slave
|
||||||
|
is 1 KB. This means that the 1 KB address boundary should not be crossed
|
||||||
|
by a burst block transfer, otherwise an AHB error would be generated,
|
||||||
|
that is not reported by the DMA registers."
|
||||||
|
|
||||||
|
There is nothing in the DMA driver to prevent this now.
|
||||||
|
|
||||||
|
nxterm
|
||||||
|
------
|
||||||
|
|
||||||
|
This is yet another NSH configuration. This NSH configuration differs
|
||||||
|
from the others, however, in that it uses the NxTerm driver to host
|
||||||
|
the NSH shell.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. Some of the differences in this configuration and the normal nsh
|
||||||
|
configuration include these settings in the defconfig file:
|
||||||
|
|
||||||
|
These select NX Multi-User mode:
|
||||||
|
|
||||||
|
CONFG_NX_MULTIUSER=y
|
||||||
|
CONFIG_DISABLE_MQUEUE=n
|
||||||
|
|
||||||
|
The following definition in the defconfig file to enables the NxTerm
|
||||||
|
driver:
|
||||||
|
|
||||||
|
CONFIG_NXTERM=y
|
||||||
|
|
||||||
|
And this selects examples/nxterm instead of examples/nsh:
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_NXTERM=y
|
||||||
|
|
||||||
|
LCD Orientation:
|
||||||
|
|
||||||
|
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape
|
||||||
|
|
||||||
|
3. Default build environment (also easily reconfigured):
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y : Windows
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y : With Cygwin
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
|
||||||
|
nxwm
|
||||||
|
----
|
||||||
|
|
||||||
|
This is a special configuration setup for the NxWM window manager
|
||||||
|
UnitTest. The NxWM window manager can be found here::
|
||||||
|
|
||||||
|
apps/graphics/NxWidgets/nxwm
|
||||||
|
|
||||||
|
The NxWM unit test can be found at::
|
||||||
|
|
||||||
|
apps/graphics/NxWidgets/UnitTests/nxwm
|
||||||
|
|
||||||
|
telnetd
|
||||||
|
-------
|
||||||
|
|
||||||
|
A simple test of the Telnet daemon(see apps/netutils/README.txt,
|
||||||
|
apps/examples/README.txt, and apps/examples/telnetd). This is
|
||||||
|
the same daemon that is used in the nsh configuration so if you
|
||||||
|
use NSH, then you don't care about this. This test is good for
|
||||||
|
testing the Telnet daemon only because it works in a simpler
|
||||||
|
environment than does the nsh configuration.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configurations using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. Default build environment (easily reconfigured)::
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y
|
||||||
|
|
||||||
|
xmlrpc
|
||||||
|
------
|
||||||
|
|
||||||
|
An example configuration for the Embeddable Lightweight XML-RPC
|
||||||
|
Server at apps/examples/xmlrpc. See http://www.drdobbs.com/web-development/\
|
||||||
|
an-embeddable-lightweight-xml-rpc-server/184405364 for more info.
|
||||||
|
Contributed by Max Holtzberg.
|
||||||
@ -1,19 +1,10 @@
|
|||||||
README
|
=================
|
||||||
======
|
stm32f411-minimum
|
||||||
|
=================
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the
|
This README discusses issues unique to NuttX configurations for the
|
||||||
WeAct Studio MiniF4 minimum system development board.
|
WeAct Studio MiniF4 minimum system development board.
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Board information
|
|
||||||
- LEDs
|
|
||||||
- UARTs
|
|
||||||
- USB
|
|
||||||
- SPI NOR Flash
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
Board information
|
Board information
|
||||||
=================
|
=================
|
||||||
|
|
||||||
@ -59,18 +50,28 @@ LEDs
|
|||||||
UARTs
|
UARTs
|
||||||
=====
|
=====
|
||||||
|
|
||||||
UART/USART PINS
|
|
||||||
---------------
|
|
||||||
|
|
||||||
USART1
|
USART1
|
||||||
|
------
|
||||||
|
|
||||||
|
========== =====
|
||||||
|
UART/USART PINS
|
||||||
|
========== =====
|
||||||
TX PA9
|
TX PA9
|
||||||
RX PA10
|
RX PA10
|
||||||
|
========== =====
|
||||||
|
|
||||||
USART2
|
USART2
|
||||||
|
------
|
||||||
|
|
||||||
|
========== =====
|
||||||
|
UART/USART PINS
|
||||||
|
========== =====
|
||||||
CTS PA0
|
CTS PA0
|
||||||
RTS PA1
|
RTS PA1
|
||||||
TX PA2
|
TX PA2
|
||||||
RX PA3
|
RX PA3
|
||||||
CK PA4
|
CK PA4
|
||||||
|
========== =====
|
||||||
|
|
||||||
Default USART/UART Configuration
|
Default USART/UART Configuration
|
||||||
--------------------------------
|
--------------------------------
|
||||||
@ -105,7 +106,7 @@ Configurations
|
|||||||
==============
|
==============
|
||||||
|
|
||||||
Each stm32f411-minimum configuration is maintained in a sub-directory and
|
Each stm32f411-minimum configuration is maintained in a sub-directory and
|
||||||
can be selected as follow:
|
can be selected as follow::
|
||||||
|
|
||||||
tools/configure.sh stm32f411-minimum:<subdir>
|
tools/configure.sh stm32f411-minimum:<subdir>
|
||||||
|
|
||||||
@ -115,7 +116,8 @@ can be selected as follow:
|
|||||||
Configuration Directories
|
Configuration Directories
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
nsh:
|
nsh
|
||||||
---
|
---
|
||||||
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
||||||
configuration enables a serial console on UART1.
|
configuration enables a serial console on UART1.
|
||||||
@ -1,5 +1,6 @@
|
|||||||
README
|
=======================
|
||||||
======
|
ST STM32F411E-Discovery
|
||||||
|
=======================
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the STMicro
|
This README discusses issues unique to NuttX configurations for the STMicro
|
||||||
STM32F411E-Discovery board. See
|
STM32F411E-Discovery board. See
|
||||||
@ -0,0 +1,749 @@
|
|||||||
|
================
|
||||||
|
STM32F429I-DISCO
|
||||||
|
================
|
||||||
|
|
||||||
|
This README discusses issues unique to NuttX configurations for the
|
||||||
|
STMicro STM32F429I-DISCO development board featuring the STM32F429ZIT6
|
||||||
|
MCU. The STM32F429ZIT6 is a 180MHz Cortex-M4 operation with 2Mbit Flash
|
||||||
|
memory and 256kbytes. The board features:
|
||||||
|
|
||||||
|
- On-board ST-LINK/V2 for programming and debugging,
|
||||||
|
- On-board 64 Mbits (8 Mbytes) External SDRAM (1 Mbit x 16-bit x 4-bank)
|
||||||
|
- L3GD20, ST MEMS motion sensor, 3-axis digital output gyroscope,
|
||||||
|
- TFT 2.4" LCD, 262K color RGB, 240 x 320 pixels
|
||||||
|
- Touchscreen controller
|
||||||
|
- Two user LEDs and two push-buttons,
|
||||||
|
- USB OTG FS with micro-AB connector, and
|
||||||
|
- Easy access to most MCU pins.
|
||||||
|
|
||||||
|
NOTE: Includes basic NSH command support with full 8MByte SDRAM + the
|
||||||
|
internal 256K. Unsupported are the LCD and USB interfaces.
|
||||||
|
|
||||||
|
The board pin configuration to support on-board SDRAM and LCD
|
||||||
|
prevents use of the OTG FS module which is normally used for USB
|
||||||
|
NSH sessions. Instead, the board routes the OTG HS pins to the
|
||||||
|
USB OTG connector.
|
||||||
|
|
||||||
|
The NSH configuration / testing that has been done so far was
|
||||||
|
performed by connecting an external RS-232 line driver to pins
|
||||||
|
PA9 (TX) and PA10 (RX) and configuring USART1 as the NSH console.
|
||||||
|
|
||||||
|
Refer to the http://www.st.com website for further information about this
|
||||||
|
board (search keyword: 429i-disco)
|
||||||
|
|
||||||
|
NOTE: This port was based on the original discovery kit, STM32F429I-DISCO.
|
||||||
|
That board has been superseded by the new STM32F429I-DISC1.
|
||||||
|
|
||||||
|
Setup and Programming Flash
|
||||||
|
===========================
|
||||||
|
|
||||||
|
I use a USB cable to power and program it. And I use a USB/Serial
|
||||||
|
connected to pins PA9 and PA10 for the serial console (See the section
|
||||||
|
"UARTs" below).
|
||||||
|
|
||||||
|
FLASH may be programmed:
|
||||||
|
|
||||||
|
- Via USB using STM32 ST-Link Utility
|
||||||
|
|
||||||
|
- Via USB using OpenOCD. This command may be used to flash the
|
||||||
|
firmware using OpenOCD::
|
||||||
|
|
||||||
|
$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
|
||||||
|
|
||||||
|
- Via JTAG/SWD connected to the SWD connector CN2.
|
||||||
|
|
||||||
|
CN4 Jumpers. Remove jumpers to enable signals at SWD connector CN2.::
|
||||||
|
|
||||||
|
SWD 6-Pin STM32F429i-Discovery Connector CN2
|
||||||
|
Pin Signal Name Description
|
||||||
|
----- ------ ---------- ------------------------------
|
||||||
|
Pin 1 AIN_1 VDD_TARGET VDD from application
|
||||||
|
Pin 2 T_JCLK SWCLK SWD Clock
|
||||||
|
Pin 3 GND GND Ground
|
||||||
|
Pin 4 T_JTMS SWDIO SWD data input/output
|
||||||
|
Pin 5 T_NRST NRST Reset of target MCU
|
||||||
|
Pin 6 T_SWO SWO Reserved
|
||||||
|
|
||||||
|
SWD 20-pin J-Link Connector
|
||||||
|
Pin Name Type Description
|
||||||
|
------ --------- ------ ------------------------------
|
||||||
|
Pin 1 VTref Input Target reference voltage
|
||||||
|
Pin 2 Vsupply NC Not connected in J-Link
|
||||||
|
Pin 3 Not used NC Not used in J-Link
|
||||||
|
Pin 5 Not used NC Not used in J-Link
|
||||||
|
Pin 7 SWDIO I/O Bi-directional data pin
|
||||||
|
Pin 9 SWCLK Output Clock signal to target CPU
|
||||||
|
Pin 11 Not used NC Not used in J-Link
|
||||||
|
Pin 13 SWO Output Serial wire output trace port
|
||||||
|
Pin 15 RESET I/O Target CPU reset signal (nRST)
|
||||||
|
Pin 17 Not used NC Not connected in J-Link
|
||||||
|
Pin 19 5V-Supply Output Supplies power to some boards.
|
||||||
|
|
||||||
|
Pins 4, 45, 8, 10, 12, 14, 16, 18 and 20 are GND pins in J-Link. They
|
||||||
|
should also be connected to ground in the target system.
|
||||||
|
|
||||||
|
LEDs
|
||||||
|
====
|
||||||
|
|
||||||
|
The STM32F429I-DISCO board has two user LEDs; green, and red on the board.
|
||||||
|
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
||||||
|
defined. In that case, the usage by the board port is defined in
|
||||||
|
include/board.h and src/up_leds.c. The LEDs are used to encode OS-related
|
||||||
|
events as follows::
|
||||||
|
|
||||||
|
SYMBOL Meaning LED1* LED2
|
||||||
|
green red
|
||||||
|
------------------- ----------------------- ------- -------
|
||||||
|
LED_STARTED NuttX has been started ON OFF
|
||||||
|
LED_HEAPALLOCATE Heap has been allocated OFF ON
|
||||||
|
LED_IRQSENABLED Interrupts enabled ON ON
|
||||||
|
LED_STACKCREATED Idle stack created OFF ON
|
||||||
|
LED_INIRQ In an interrupt** ON ON
|
||||||
|
LED_SIGNAL In a signal handler N/C ON
|
||||||
|
LED_ASSERTION An assertion failed ON ON
|
||||||
|
LED_PANIC The system has crashed ON BLINK
|
||||||
|
LED_IDLE STM32 is is sleep mode (Optional, not used)
|
||||||
|
|
||||||
|
* In normal mode, LED1 will be on and LED2 might flicker a bit as IRQs
|
||||||
|
and SIGNALS are processed.
|
||||||
|
* If LED1 is on and LED2 is blinking, then NuttX probably failed to boot
|
||||||
|
or is in a PANIC condition.
|
||||||
|
|
||||||
|
UARTs
|
||||||
|
=====
|
||||||
|
|
||||||
|
On the STM32F429I-DISCO board, because of pin mappings to support the
|
||||||
|
onboard SDRAM and LCD, the only UARTs that have both RX and TX pins
|
||||||
|
available are USART1 and UART5. Other USARTS could be used for RX or TX
|
||||||
|
only, or they could be used for full-duplex if the other pin functions
|
||||||
|
aren't being used (i.e. LCD or SDRAM).
|
||||||
|
|
||||||
|
UART/USART PINS
|
||||||
|
---------------
|
||||||
|
|
||||||
|
..
|
||||||
|
USART1
|
||||||
|
CK PA8[1]
|
||||||
|
CTS PA11[1]
|
||||||
|
RTS PA12[1]
|
||||||
|
RX PA10, PB7
|
||||||
|
TX PA9, PB6[1]
|
||||||
|
USART2
|
||||||
|
CK PA4[1], PD7
|
||||||
|
CTS PA0[1], PD3[1]
|
||||||
|
RTS PA1[1], PD4
|
||||||
|
RX PA3[1], PD6[1]
|
||||||
|
TX PA2[1], PD5
|
||||||
|
USART3
|
||||||
|
CK PB12[1], PC12, PD10[1]
|
||||||
|
CTS PB13[1], PD11[1]
|
||||||
|
RTS PB14[1], PD12[1]
|
||||||
|
RX PB11[1], PC11, PD9[1]
|
||||||
|
TX PB10[1], PC10[1], PD8[1]
|
||||||
|
UART4
|
||||||
|
RX PA1[1], PC11
|
||||||
|
TX PA0[1], PC10[1]
|
||||||
|
UART5
|
||||||
|
RX PD2
|
||||||
|
TX PC12
|
||||||
|
USART6
|
||||||
|
CK PC8, PG7[1]
|
||||||
|
CTS PG13[1], PG15[1]
|
||||||
|
RTS PG12[1], PG8[1]
|
||||||
|
RX PC7[1], PG9
|
||||||
|
TX PC6[1], PG14[1]
|
||||||
|
UART7
|
||||||
|
RX PE7[1], PF6
|
||||||
|
TX PE8[1], PF7[1]
|
||||||
|
|
||||||
|
[1] Indicates pins that have other on-board functions and should be used only
|
||||||
|
with care (See table 6 in the STM32F429I-DISCO User Guide for a list of free
|
||||||
|
I/O pins on the board).
|
||||||
|
|
||||||
|
Default Serial Console
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
USART1 is enabled as the serial console in all configurations (see \*/defconfig).
|
||||||
|
USART1 RX and TX are configured on pins PA10 and PA9, respectively (see
|
||||||
|
include/board.h).::
|
||||||
|
|
||||||
|
Header 32X2 P1
|
||||||
|
--------------
|
||||||
|
Pin 1 5V
|
||||||
|
Pin 51 PA10
|
||||||
|
Pin 52 PA9
|
||||||
|
Pin 63 GND
|
||||||
|
|
||||||
|
If solder bridges SB11 and SB12 are closed, then USART1 will be connected to
|
||||||
|
the ST-Link and should be available over USB as a virtual COM interface.
|
||||||
|
|
||||||
|
Timer Inputs/Outputs
|
||||||
|
====================
|
||||||
|
|
||||||
|
::
|
||||||
|
TIM1
|
||||||
|
CH1 PA8[1], PE9[1]
|
||||||
|
CH2 PA9, PE11[1]
|
||||||
|
CH3 PA10, PE13[1]
|
||||||
|
CH4 PA11[1], PE14[1]
|
||||||
|
TIM2
|
||||||
|
CH1 PA0[1], PA15[1], PA5
|
||||||
|
CH2 PA1[1], PB3[1]
|
||||||
|
CH3 PA2[1], PB10[1]
|
||||||
|
CH4 PA3[1], PB11[1]
|
||||||
|
TIM3
|
||||||
|
CH1 PA6[1], PB4, PC6[1]
|
||||||
|
CH2 PA7[1], PB5[1], PC7[1]
|
||||||
|
CH3 PB0[1], PC8
|
||||||
|
CH4 PB1[1], PC9[1]
|
||||||
|
TIM4
|
||||||
|
CH1 PB6[1], PD12[1]
|
||||||
|
CH2 PB7, PD13[1]
|
||||||
|
CH3 PB8[1], PD14[1]
|
||||||
|
CH4 PB9[1], PD15[1]
|
||||||
|
TIM5
|
||||||
|
CH1 PA0[1], PH10[1]
|
||||||
|
CH2 PA1[1], PH11[1]
|
||||||
|
CH3 PA2[1], PH12[1]
|
||||||
|
CH4 PA3[1], PI0[2]
|
||||||
|
TIM8
|
||||||
|
CH1 PC6[1], PI5[2]
|
||||||
|
CH2 PC7[1], PI6[2]
|
||||||
|
CH3 PC8, PI7[2]
|
||||||
|
CH4 PC9[1], PI2[2]
|
||||||
|
TIM9
|
||||||
|
CH1 PA2[1], PE5
|
||||||
|
CH2 PA3[1], PE6
|
||||||
|
TIM10
|
||||||
|
CH1 PB8[1], PF6
|
||||||
|
TIM11
|
||||||
|
CH1 PB9[1], PF7[1]
|
||||||
|
TIM12
|
||||||
|
CH1 PH6[1], PB14[1]
|
||||||
|
CH2 PC15[1], PH9[1]
|
||||||
|
TIM13
|
||||||
|
CH1 PA6[1], PF8[1]
|
||||||
|
TIM14
|
||||||
|
CH1 PA7[1], PF9[1]
|
||||||
|
|
||||||
|
[1] Indicates pins that have other on-board functions and should be used only
|
||||||
|
with care (See table 6 in the STM32F429I-DISCO User Guide). The rest are
|
||||||
|
free I/O pins (This need to be updated. They are incorrect!)
|
||||||
|
[2] Port I pins are not supported by the MCU
|
||||||
|
|
||||||
|
|
||||||
|
FMC SDRAM
|
||||||
|
=========
|
||||||
|
|
||||||
|
On-board SDRAM
|
||||||
|
--------------
|
||||||
|
The STM32F429I-DISCO has 8 MBytes on-board SDRAM connected to the MCU's
|
||||||
|
SDRAM Bank 2 connections (Bank 6 of the FMC). This means the 8 MiB
|
||||||
|
(when enabled) is mapped to address 0xD0000000-0xD07FFFFF. The port for
|
||||||
|
the STM32F429I-DISCO board includes support for using the onboard 8M SDRAM.
|
||||||
|
|
||||||
|
Configuration Options
|
||||||
|
---------------------
|
||||||
|
Internal SRAM is available in all members of the STM32 family. The F4 family
|
||||||
|
also contains internal CCM SRAM. This SRAM is different because it cannot
|
||||||
|
be used for DMA. So if DMA needed, then the following should be defined
|
||||||
|
to exclude CCM SRAM from the heap::
|
||||||
|
|
||||||
|
CONFIG_STM32_CCMEXCLUDE : Exclude CCM SRAM from the HEAP
|
||||||
|
|
||||||
|
In addition to internal SRAM, SRAM may also be available through the FMC.
|
||||||
|
In order to use FMC SDRAM, the following additional things need to be
|
||||||
|
present in the NuttX configuration file::
|
||||||
|
|
||||||
|
CONFIG_STM32_FMC=y : Enables the FMC and the 8MiB SDRAM
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM=y : Indicates that RAM is available via the
|
||||||
|
FMC (as opposed to an LCD or FLASH).
|
||||||
|
CONFIG_HEAP2_BASE : The base address of the RAM in the FMC
|
||||||
|
address space. This should be 0xD0000000.
|
||||||
|
CONFIG_HEAP2_SIZE : The size of the RAM in the FMC
|
||||||
|
address space. This should be 8388608.
|
||||||
|
CONFIG_MM_REGIONS : Must be set to a large enough value to
|
||||||
|
include the FMC SDRAM (1, 2 or 3 depending
|
||||||
|
if the CCM RAM and/or FMC SDRAM are enabled).
|
||||||
|
|
||||||
|
SRAM Configurations
|
||||||
|
--------------------
|
||||||
|
There are 4 possible SRAM configurations::
|
||||||
|
|
||||||
|
Configuration 1. System SRAM (only)
|
||||||
|
CONFIG_MM_REGIONS == 1
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM NOT defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE defined
|
||||||
|
Configuration 2. System SRAM and CCM SRAM
|
||||||
|
CONFIG_MM_REGIONS == 2
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM NOT defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE NOT defined
|
||||||
|
Configuration 3. System SRAM and FMC SDRAM
|
||||||
|
CONFIG_MM_REGIONS == 2
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE defined
|
||||||
|
Configuration 4. System SRAM, CCM SRAM, and FMC SDRAM
|
||||||
|
CONFIG_MM_REGIONS == 3
|
||||||
|
CONFIG_STM32_EXTERNAL_RAM defined
|
||||||
|
CONFIG_STM32_CCMEXCLUDE NOT defined
|
||||||
|
|
||||||
|
Configurations
|
||||||
|
==============
|
||||||
|
|
||||||
|
Each STM32F429I-DISCO configuration is maintained in a sub-directory and
|
||||||
|
can be selected as follow::
|
||||||
|
|
||||||
|
tools/configure.sh stm32f429i-disco:<subdir>
|
||||||
|
|
||||||
|
Where <subdir> is one of the following:
|
||||||
|
|
||||||
|
extflash:
|
||||||
|
---------
|
||||||
|
|
||||||
|
This is another NSH example. If differs from other 'nsh' configurations
|
||||||
|
in that this configuration defines an external 8 MByte SPI FLASH (the
|
||||||
|
SST25VF064C part from Silicon Storage Technology, Inc.) which must be
|
||||||
|
be connected to the Discovery board's SPI4 pins on the expansion pins.
|
||||||
|
Additionally, this demo uses UART1 for the console
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration assumes an SST25VF064C 8Mbyte SPI FLASH is
|
||||||
|
connected to SPI4 on the following Discovery board Pins::
|
||||||
|
|
||||||
|
SCK: Port PE2 Board Connector P1, Pin 15
|
||||||
|
MOSI: Port PE6 Board Connector P1, Pin 11
|
||||||
|
MISO: Port PE5 Board Connector P1, Pin 14
|
||||||
|
CS: Port PE4 Board Connector P1, Pin 13
|
||||||
|
|
||||||
|
2. This configuration does have UART1 output enabled and set up as
|
||||||
|
the system logging device. To use this UART, you must add an
|
||||||
|
external RS-232 line driver to the UART1 pins of the DISCO board
|
||||||
|
on PA9 and PA10 of connector P1.
|
||||||
|
|
||||||
|
fb
|
||||||
|
--
|
||||||
|
|
||||||
|
STM32F429I-DISCO LTDC Framebuffer demo example. This is a simple
|
||||||
|
configuration used for some basic (non-graphic) debug of the framebuffer
|
||||||
|
character drivers using apps/examples/fb. It simply opens the framebuffer
|
||||||
|
device and draws concentric rectangles of different colors in the
|
||||||
|
framebuffer::
|
||||||
|
|
||||||
|
nsh> fb
|
||||||
|
|
||||||
|
Also included is the touchscreen test of apps/examples/touchscreen. This
|
||||||
|
example will simply open the touchscreen driver then collect and display
|
||||||
|
touch inputs::
|
||||||
|
|
||||||
|
nsh> tc 1
|
||||||
|
tc_main: nsamples: 1
|
||||||
|
tc_main: Initializing external touchscreen device
|
||||||
|
tc_main: Opening /dev/input0
|
||||||
|
Sample :
|
||||||
|
npoints : 1
|
||||||
|
Point 1 :
|
||||||
|
id : 0
|
||||||
|
flags : 3c
|
||||||
|
x : 2296
|
||||||
|
y : 2311
|
||||||
|
h : 0
|
||||||
|
w : 0
|
||||||
|
pressure : 1
|
||||||
|
Terminating!
|
||||||
|
nsh>
|
||||||
|
|
||||||
|
lgvl
|
||||||
|
----
|
||||||
|
|
||||||
|
STM32F429I-DISCO LittlevGL demo example.
|
||||||
|
|
||||||
|
The ltdc is initialized during boot up. Interaction with NSH is via
|
||||||
|
the serial console at 115200 8N1 baud. From the nsh command line
|
||||||
|
execute the lvgldemo example::
|
||||||
|
|
||||||
|
nsh> lvgldemo
|
||||||
|
|
||||||
|
The test will execute the calibration process and then run the
|
||||||
|
LittlevGL demo project.
|
||||||
|
|
||||||
|
nsh
|
||||||
|
---
|
||||||
|
|
||||||
|
Configures the NuttShell (nsh) located at apps/examples/nsh. The
|
||||||
|
Configuration enables the serial interfaces on UART2. Support for
|
||||||
|
builtin applications is enabled, but in the base configuration no
|
||||||
|
builtin applications are selected (see NOTES below).
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. By default, this configuration uses the ARM EABI toolchain
|
||||||
|
for Windows and builds under Cygwin (or probably MSYS). That
|
||||||
|
can easily be reconfigured, of course.::
|
||||||
|
|
||||||
|
CONFIG_HOST_WINDOWS=y : Builds under Windows
|
||||||
|
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
||||||
|
|
||||||
|
3. This example supports the PWM test (apps/examples/pwm) but this must
|
||||||
|
be manually enabled by selecting::
|
||||||
|
|
||||||
|
CONFIG_PWM=y : Enable the generic PWM infrastructure
|
||||||
|
CONFIG_STM32_TIM4=y : Enable TIM4
|
||||||
|
CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output
|
||||||
|
|
||||||
|
See also apps/examples/README.txt
|
||||||
|
|
||||||
|
Special PWM-only debug options::
|
||||||
|
|
||||||
|
CONFIG_DEBUG_PWM_INFO
|
||||||
|
|
||||||
|
5. This example supports the Quadrature Encode test (apps/examples/qencoder)
|
||||||
|
but this must be manually enabled by selecting::
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_QENCODER=y : Enable the apps/examples/qencoder
|
||||||
|
CONFIG_SENSORS=y : Enable support for sensors
|
||||||
|
CONFIG_SENSORS_QENCODER=y : Enable the generic Quadrature Encoder infrastructure
|
||||||
|
CONFIG_STM32_TIM8=y : Enable TIM8
|
||||||
|
CONFIG_STM32_TIM2=n : (Or optionally TIM2)
|
||||||
|
CONFIG_STM32_TIM8_QE=y : Use TIM8 as the quadrature encoder
|
||||||
|
CONFIG_STM32_TIM2_QE=y : (Or optionally TIM2)
|
||||||
|
|
||||||
|
See also apps/examples/README.txt. Special debug options::
|
||||||
|
|
||||||
|
CONFIG_DEBUG_SENSORS
|
||||||
|
|
||||||
|
6. This example supports the watchdog timer test (apps/examples/watchdog)
|
||||||
|
but this must be manually enabled by selecting::
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_WATCHDOG=y : Enable the apps/examples/watchdog
|
||||||
|
CONFIG_WATCHDOG=y : Enables watchdog timer driver support
|
||||||
|
CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR
|
||||||
|
CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both)
|
||||||
|
|
||||||
|
The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result,
|
||||||
|
has a maximum timeout value of 49 milliseconds. for WWDG watchdog, you
|
||||||
|
should also add the following to the configuration file::
|
||||||
|
|
||||||
|
CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20
|
||||||
|
CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49
|
||||||
|
|
||||||
|
The IWDG timer has a range of about 35 seconds and should not be an issue.
|
||||||
|
|
||||||
|
7. USB Support (CDC/ACM device)::
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
|
||||||
|
CONFIG_USBDEV=y : USB device support must be enabled
|
||||||
|
CONFIG_CDCACM=y : The CDC/ACM driver must be built
|
||||||
|
CONFIG_NSH_BUILTIN_APPS=y : NSH built-in application support must be enabled
|
||||||
|
CONFIG_NSH_ARCHINIT=y : To perform USB initialization
|
||||||
|
|
||||||
|
8. Using the USB console.
|
||||||
|
|
||||||
|
The STM32F429I-DISCO NSH configuration can be set up to use a USB CDC/ACM
|
||||||
|
(or PL2303) USB console. The normal way that you would configure the
|
||||||
|
the USB console would be to change the .config file like this::
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=n : Disable the USART2 console
|
||||||
|
CONFIG_DEV_CONSOLE=n : Inhibit use of /dev/console by other logic
|
||||||
|
CONFIG_USBDEV=y : USB device support must be enabled
|
||||||
|
CONFIG_CDCACM=y : The CDC/ACM driver must be built
|
||||||
|
CONFIG_CDCACM_CONSOLE=y : Enable the CDC/ACM USB console.
|
||||||
|
|
||||||
|
NOTE: When you first start the USB console, you have hit ENTER a few
|
||||||
|
times before NSH starts. The logic does this to prevent sending USB data
|
||||||
|
before there is anything on the host side listening for USB serial input.
|
||||||
|
|
||||||
|
9. Here is an alternative USB console configuration. The following
|
||||||
|
configuration will also create a NSH USB console but this version
|
||||||
|
will use /dev/console. Instead, it will use the normal /dev/ttyACM0
|
||||||
|
USB serial device for the console::
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS=y : STM32 OTG FS support
|
||||||
|
CONFIG_USART2_SERIAL_CONSOLE=y : Keep the USART2 console
|
||||||
|
CONFIG_DEV_CONSOLE=y : /dev/console exists (but NSH won't use it)
|
||||||
|
CONFIG_USBDEV=y : USB device support must be enabled
|
||||||
|
CONFIG_CDCACM=y : The CDC/ACM driver must be built
|
||||||
|
CONFIG_CDCACM_CONSOLE=n : Don't use the CDC/ACM USB console.
|
||||||
|
CONFIG_NSH_USBCONSOLE=y : Instead use some other USB device for the console
|
||||||
|
|
||||||
|
The particular USB device that is used is::
|
||||||
|
|
||||||
|
CONFIG_NSH_USBCONDEV="/dev/ttyACM0"
|
||||||
|
|
||||||
|
The advantage of this configuration is only that it is easier to
|
||||||
|
bet working. This alternative does has some side effects:
|
||||||
|
|
||||||
|
- When any other device other than /dev/console is used for a user
|
||||||
|
interface, linefeeds (\n) will not be expanded to carriage return /
|
||||||
|
linefeeds (\r\n). You will need to set your terminal program to account
|
||||||
|
for this.
|
||||||
|
|
||||||
|
- /dev/console still exists and still refers to the serial port. So
|
||||||
|
you can still use certain kinds of debug output (see include/debug.h, all
|
||||||
|
debug output from interrupt handlers will be lost.
|
||||||
|
|
||||||
|
- But don't enable USB debug output! Since USB is console is used for
|
||||||
|
USB debug output and you are using a USB console, there will be
|
||||||
|
infinite loops and deadlocks: Debug output generates USB debug
|
||||||
|
output which generatates USB debug output, etc. If you want USB
|
||||||
|
debug output, you should consider enabling USB trace
|
||||||
|
(CONFIG_USBDEV_TRACE) and perhaps the USB monitor (CONFIG_USBMONITOR).
|
||||||
|
|
||||||
|
See the usbnsh configuration below for more information on configuring
|
||||||
|
USB trace output and the USB monitor.
|
||||||
|
|
||||||
|
10. USB OTG FS Host Support. The following changes will enable support for
|
||||||
|
a USB host on the STM32F429I-DISCO, including support for a mass storage
|
||||||
|
class driver:
|
||||||
|
|
||||||
|
Device Drivers ->
|
||||||
|
CONFIG_USBDEV=n : Make sure the USB device support is disabled
|
||||||
|
CONFIG_USBHOST=y : Enable USB host support
|
||||||
|
CONFIG_USBHOST_ISOC_DISABLE=y
|
||||||
|
|
||||||
|
Device Drivers -> USB Host Driver Support
|
||||||
|
CONFIG_USBHOST_MSC=y : Enable the mass storage class
|
||||||
|
|
||||||
|
System Type -> STM32 Peripheral Support
|
||||||
|
CONFIG_STM32_OTGHS=y : Enable the STM32 USB OTG FH block (FS mode)
|
||||||
|
CONFIG_STM32_SYSCFG=y : Needed for all USB OTF HS support
|
||||||
|
|
||||||
|
RTOS Features -> Work Queue Support
|
||||||
|
CONFIG_SCHED_WORKQUEUE=y : High priority worker thread support is required
|
||||||
|
CONFIG_SCHED_HPWORK=y : for the mass storage class driver.
|
||||||
|
|
||||||
|
File Systems ->
|
||||||
|
CONFIG_FS_FAT=y : Needed by the USB host mass storage class.
|
||||||
|
|
||||||
|
Board Selection ->
|
||||||
|
CONFIG_BOARDCTL=y : Needed for CONFIG_NSH_ARCHINIT
|
||||||
|
|
||||||
|
Application Configuration -> NSH Library
|
||||||
|
CONFIG_NSH_ARCHINIT=y : Architecture specific USB initialization
|
||||||
|
: is needed for NSH
|
||||||
|
|
||||||
|
With those changes, you can use NSH with a FLASH pen driver as shown
|
||||||
|
belong. Here NSH is started with nothing in the USB host slot:
|
||||||
|
|
||||||
|
NuttShell (NSH) NuttX-x.yy
|
||||||
|
nsh> ls /dev
|
||||||
|
/dev:
|
||||||
|
console
|
||||||
|
null
|
||||||
|
ttyS0
|
||||||
|
|
||||||
|
After inserting the FLASH drive, the /dev/sda appears and can be
|
||||||
|
mounted like this:
|
||||||
|
|
||||||
|
nsh> ls /dev
|
||||||
|
/dev:
|
||||||
|
console
|
||||||
|
null
|
||||||
|
sda
|
||||||
|
ttyS0
|
||||||
|
nsh> mount -t vfat /dev/sda /mnt/stuff
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
|
||||||
|
And files on the FLASH can be manipulated to standard interfaces:
|
||||||
|
|
||||||
|
nsh> echo "This is a test" >/mnt/stuff/atest.txt
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
-rw-rw-rw- 16 atest.txt
|
||||||
|
nsh> cat /mnt/stuff/atest.txt
|
||||||
|
This is a test
|
||||||
|
nsh> cp /mnt/stuff/filea.c fileb.c
|
||||||
|
nsh> ls /mnt/stuff
|
||||||
|
/mnt/stuff:
|
||||||
|
-rw-rw-rw- 16236 filea.c
|
||||||
|
-rw-rw-rw- 16 atest.txt
|
||||||
|
-rw-rw-rw- 16236 fileb.c
|
||||||
|
|
||||||
|
To prevent data loss, don't forget to un-mount the FLASH drive
|
||||||
|
before removing it:
|
||||||
|
|
||||||
|
nsh> umount /mnt/stuff
|
||||||
|
|
||||||
|
11. I used this configuration to test the USB hub class. I did this
|
||||||
|
testing with the following changes to the configuration (in addition
|
||||||
|
to those listed above for base USB host/mass storage class support):
|
||||||
|
|
||||||
|
Drivers -> USB Host Driver Support
|
||||||
|
CONFIG_USBHOST_HUB=y : Enable the hub class
|
||||||
|
CONFIG_USBHOST_ASYNCH=y : Asynchronous I/O supported needed for hubs
|
||||||
|
|
||||||
|
Board Selection ->
|
||||||
|
CONFIG_STM32F429IDISCO_USBHOST_STACKSIZE=2048 (bigger than it needs to be)
|
||||||
|
|
||||||
|
RTOS Features -> Work Queue Support
|
||||||
|
CONFIG_SCHED_LPWORK=y : Low priority queue support is needed
|
||||||
|
CONFIG_SCHED_LPNTHREADS=1
|
||||||
|
CONFIG_SCHED_LPWORKSTACKSIZE=1024
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. It is necessary to perform work on the low-priority work queue
|
||||||
|
(vs. the high priority work queue) because deferred hub-related
|
||||||
|
work requires some delays and waiting that is not appropriate on
|
||||||
|
the high priority work queue.
|
||||||
|
|
||||||
|
2. Stack usage make increase when USB hub support is enabled because
|
||||||
|
the nesting depth of certain USB host class logic can increase.
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
2015-04-30
|
||||||
|
Appears to be fully functional.
|
||||||
|
|
||||||
|
nx
|
||||||
|
--
|
||||||
|
|
||||||
|
This a simple test using the graphic example at apps/example/nx. This
|
||||||
|
configuration illustrates the use of the LCD with the lower performance
|
||||||
|
SPI interface.
|
||||||
|
|
||||||
|
nxwm
|
||||||
|
----
|
||||||
|
|
||||||
|
This is a special configuration setup for the NxWM window manager
|
||||||
|
UnitTest.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. The NxWM window manager can be found here::
|
||||||
|
|
||||||
|
apps/graphics/NxWidgets/nxwm
|
||||||
|
|
||||||
|
The NxWM unit test can be found at::
|
||||||
|
|
||||||
|
apps/graphics/NxWidgets/UnitTests/nxwm
|
||||||
|
|
||||||
|
STATUS:
|
||||||
|
17-01-08: There are instabilities in this configuration that make it
|
||||||
|
not usable on this platform. While the equivalent configuration works
|
||||||
|
on other platforms, this one does not: The calculator display does
|
||||||
|
not form properly. There are fails in the NxTerm display, usually
|
||||||
|
around the point where the display should scroll up.
|
||||||
|
|
||||||
|
Update: With all optimizations disabled, the issue seems to go away.
|
||||||
|
So this is most likely due to using high levels of optimization with a
|
||||||
|
bleeding edge GCC toolchain.
|
||||||
|
|
||||||
|
17-11-15: The original configuration used the slower SPI LCD interface.
|
||||||
|
The configuration was converted to use the high performance LTDC frame
|
||||||
|
buffer interface. Performance is now excellent and I see none of the
|
||||||
|
instabilities mentioned above even at high levels of optimization.
|
||||||
|
|
||||||
|
The difficulty that I experienced was touching the tiny icons on the
|
||||||
|
menus. The touscreen controller (along with my fat fingers) does not
|
||||||
|
appear to have sufficient precision to work in this way. Larger icons
|
||||||
|
would likely make the interface easier to use.
|
||||||
|
|
||||||
|
usbnsh
|
||||||
|
------
|
||||||
|
|
||||||
|
This is another NSH example. If differs from other 'nsh' configurations
|
||||||
|
in that this configurations uses a USB serial device for console I/O.
|
||||||
|
Such a configuration is useful on the stm32f429i-disco which has no
|
||||||
|
builtin RS-232 drivers.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses the mconf-based configuration tool. To
|
||||||
|
change this configuration using that tool, you should:
|
||||||
|
|
||||||
|
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
||||||
|
see additional README.txt files in the NuttX tools repository.
|
||||||
|
|
||||||
|
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
||||||
|
reconfiguration process.
|
||||||
|
|
||||||
|
2. This configuration does have UART1 output enabled and set up as
|
||||||
|
the system logging device. To use this UART, you must add an
|
||||||
|
external RS-232 line driver to the UART1 pins of the DISCO board
|
||||||
|
on PA9 and PA10 of connector P1.
|
||||||
|
|
||||||
|
usbmsc
|
||||||
|
------
|
||||||
|
|
||||||
|
This is an example of enabling the FS OTG port on the DISCO board for
|
||||||
|
mass storage use. It provides an NSH session on UART1 to allow
|
||||||
|
accessing the connected USB mass storage device. Such a configuration
|
||||||
|
is useful on the stm32f429i-disco which has no onboard SD card or mass
|
||||||
|
storage solution.
|
||||||
|
|
||||||
|
NOTES:
|
||||||
|
|
||||||
|
1. This configuration uses UART1 as the system console. To use this
|
||||||
|
UART, you must add an external RS-232 line driver to the UART1 pins
|
||||||
|
of the DISCO board on PA9 and PA10 of connector P1.
|
||||||
|
|
||||||
|
2. The mass storage device will appear as /dev/sda and supports FAT
|
||||||
|
formatted "thumb" flash drives with::
|
||||||
|
|
||||||
|
nsh> mount -t vfat /dev/sda /mount_name
|
||||||
|
|
||||||
|
STM32F429I-DISCO LTDC Framebuffer demo example
|
||||||
|
==============================================
|
||||||
|
|
||||||
|
STM32F429I-DISCO LTDC Framebuffer demo example
|
||||||
|
|
||||||
|
Configure and build
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
::
|
||||||
|
cd tools
|
||||||
|
./configure -a <appdir> stm32f429i-disco/fb
|
||||||
|
cd ..
|
||||||
|
make
|
||||||
|
|
||||||
|
Framebuffer calculation
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
Use the helper script boards/stm32f429i-disco/tools/fbcalc.sh for calculating
|
||||||
|
the heap2 and framebuffer memory region. The script assumes that all overlay
|
||||||
|
buffers (LTDC and DMA2D) located in heap2 memory region starting at address
|
||||||
|
0xD0000000. When changing the display size (when using a custom display), DMA2D
|
||||||
|
overlay size or the pixel format you have to recalculate the heap2 settings.
|
||||||
|
In this configuration all overlays (LTDC and DMA2D) positioned at the end of
|
||||||
|
heap2.
|
||||||
|
|
||||||
|
Configuration
|
||||||
|
-------------
|
||||||
|
|
||||||
|
This configuration provides 2 LTDC (visible overlays) and 2 DMA2D overlays with
|
||||||
|
pixel format RGB565 and a resolution of 240x320.
|
||||||
|
|
||||||
|
Loading
|
||||||
|
-------
|
||||||
|
|
||||||
|
st-flash write nuttx.bin 0x8000000
|
||||||
|
|
||||||
|
Executing
|
||||||
|
---------
|
||||||
|
|
||||||
|
The ltdc is initialized during boot up. Interaction with NSH is via the serial
|
||||||
|
console at 115200 8N1 baud. From the nsh comandline execute the fb example::
|
||||||
|
|
||||||
|
nsh> fb
|
||||||
|
|
||||||
|
The test will put a pattern of concentric squares in the framebuffer and
|
||||||
|
terminate.
|
||||||
|
|
||||||
|
You can also test overlay hardware acceleration functionality by executing the
|
||||||
|
following command (shows a commandline help)::
|
||||||
|
|
||||||
|
nsh> fboverlay
|
||||||
File diff suppressed because it is too large
Load Diff
536
Documentation/platforms/arm/stm32f4/index.rst
Normal file
536
Documentation/platforms/arm/stm32f4/index.rst
Normal file
@ -0,0 +1,536 @@
|
|||||||
|
==========
|
||||||
|
ST STM32F4
|
||||||
|
==========
|
||||||
|
|
||||||
|
Supported MCUs
|
||||||
|
==============
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
Peripheral Support
|
||||||
|
==================
|
||||||
|
|
||||||
|
The following list indicates peripherals supported in NuttX:
|
||||||
|
|
||||||
|
========== ======= =====
|
||||||
|
Peripheral Support Notes
|
||||||
|
========== ======= =====
|
||||||
|
IRQs Yes
|
||||||
|
GPIO Yes
|
||||||
|
EXTI Yes
|
||||||
|
HSE Yes
|
||||||
|
PLL Yes
|
||||||
|
HSI Yes
|
||||||
|
MSI Yes
|
||||||
|
LSE Yes
|
||||||
|
RCC Yes
|
||||||
|
SYSCFG Yes
|
||||||
|
USART Yes
|
||||||
|
FLASH Yes
|
||||||
|
DMA Yes
|
||||||
|
SPI Yes
|
||||||
|
I2C Yes
|
||||||
|
I2S Yes
|
||||||
|
FMPI2C No
|
||||||
|
SPDIFRX No
|
||||||
|
SAI No
|
||||||
|
RTC Yes
|
||||||
|
Timers Yes
|
||||||
|
PM Yes
|
||||||
|
RNG Yes
|
||||||
|
CRC No
|
||||||
|
HASH No
|
||||||
|
ADC Yes
|
||||||
|
DAC Yes
|
||||||
|
WWDG Yes
|
||||||
|
IWDG Yes
|
||||||
|
CAN Yes
|
||||||
|
USB FS Yes
|
||||||
|
USB HS Yes
|
||||||
|
ETH Yes
|
||||||
|
FMC Yes
|
||||||
|
QSPI Yes
|
||||||
|
DCMI No
|
||||||
|
AES Yes
|
||||||
|
HDMI-CED No
|
||||||
|
SDIO Yes
|
||||||
|
========== ======= =====
|
||||||
|
|
||||||
|
Memory
|
||||||
|
------
|
||||||
|
|
||||||
|
CONFIG_RAM_SIZE - Describes the installed DRAM (SRAM in this case):
|
||||||
|
|
||||||
|
CONFIG_RAM_SIZE=16384 (16Kb)
|
||||||
|
|
||||||
|
CONFIG_RAM_START - The start address of installed DRAM
|
||||||
|
|
||||||
|
CONFIG_RAM_START=0x20000000
|
||||||
|
|
||||||
|
CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP
|
||||||
|
|
||||||
|
CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
|
||||||
|
stack. If defined, this symbol is the size of the interrupt
|
||||||
|
stack in bytes. If not defined, the user task stacks will be
|
||||||
|
used during interrupt handling.
|
||||||
|
|
||||||
|
Clock
|
||||||
|
-----
|
||||||
|
|
||||||
|
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock
|
||||||
|
configuration features.::
|
||||||
|
|
||||||
|
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n
|
||||||
|
|
||||||
|
CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation
|
||||||
|
of delay loops
|
||||||
|
|
||||||
|
TIMER
|
||||||
|
-----
|
||||||
|
|
||||||
|
Timer devices may be used for different purposes. One special purpose is
|
||||||
|
to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn
|
||||||
|
is defined (as above) then the following may also be defined to indicate that
|
||||||
|
the timer is intended to be used for pulsed output modulation, ADC conversion,
|
||||||
|
or DAC conversion. Note that ADC/DAC require two definition: Not only do you have
|
||||||
|
to assign the timer (n) for used by the ADC or DAC, but then you also have to
|
||||||
|
configure which ADC or DAC (m) it is assigned to.
|
||||||
|
|
||||||
|
CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14
|
||||||
|
CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14
|
||||||
|
CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3
|
||||||
|
CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14
|
||||||
|
CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2
|
||||||
|
|
||||||
|
For each timer that is enabled for PWM usage, we need the following additional
|
||||||
|
configuration settings:
|
||||||
|
|
||||||
|
CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4}
|
||||||
|
|
||||||
|
NOTE: The STM32 timers are each capable of generating different signals on
|
||||||
|
each of the four channels with different duty cycles. That capability is
|
||||||
|
not supported by this driver: Only one output channel per timer.
|
||||||
|
|
||||||
|
JTAG
|
||||||
|
----
|
||||||
|
|
||||||
|
CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
|
||||||
|
|
||||||
|
CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
|
||||||
|
but without JNTRST.
|
||||||
|
|
||||||
|
CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled
|
||||||
|
|
||||||
|
USART
|
||||||
|
-----
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART
|
||||||
|
m (m=4,5) for the console and ttys0 (default is the USART1).
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received.
|
||||||
|
This specific the size of the receive buffer
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before
|
||||||
|
being sent. This specific the size of the transmit buffer
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8.
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity
|
||||||
|
|
||||||
|
CONFIG_U[S]ARTn_2STOP - Two stop bits
|
||||||
|
|
||||||
|
CAN
|
||||||
|
---
|
||||||
|
|
||||||
|
CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
|
||||||
|
CONFIG_STM32_CAN2 must also be defined)
|
||||||
|
|
||||||
|
CONFIG_CAN_EXTID - Enables support for the 29-bit extended ID. Default
|
||||||
|
Standard 11-bit IDs.
|
||||||
|
|
||||||
|
CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages.
|
||||||
|
Default: 8
|
||||||
|
|
||||||
|
CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests.
|
||||||
|
Default: 4
|
||||||
|
|
||||||
|
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
|
||||||
|
mode for testing. The STM32 CAN driver does support loopback mode.
|
||||||
|
|
||||||
|
CONFIG_STM32_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1
|
||||||
|
is defined.
|
||||||
|
|
||||||
|
CONFIG_STM32_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2
|
||||||
|
is defined.
|
||||||
|
|
||||||
|
CONFIG_STM32_CAN_TSEG1 - The number of CAN time quanta in segment 1.
|
||||||
|
Default: 6
|
||||||
|
|
||||||
|
CONFIG_STM32_CAN_TSEG2 - the number of CAN time quanta in segment 2.
|
||||||
|
Default: 7
|
||||||
|
|
||||||
|
CONFIG_STM32_CAN_REGDEBUG - If CONFIG_DEBUG_FEATURES is set, this will generate an
|
||||||
|
dump of all CAN registers.
|
||||||
|
|
||||||
|
SPI
|
||||||
|
---
|
||||||
|
|
||||||
|
CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI
|
||||||
|
support. Non-interrupt-driven, poll-waiting is recommended if the
|
||||||
|
interrupt rate would be to high in the interrupt driven case.
|
||||||
|
|
||||||
|
CONFIG_STM32_SPIx_DMA - Use DMA to improve SPIx transfer performance.
|
||||||
|
Cannot be used with CONFIG_STM32_SPI_INTERRUPT.
|
||||||
|
|
||||||
|
DMA
|
||||||
|
---
|
||||||
|
|
||||||
|
CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO and CONFIG_STM32_DMA2.
|
||||||
|
CONFIG_STM32_SDIO_PRI - Select SDIO interrupt priority. Default: 128
|
||||||
|
|
||||||
|
CONFIG_STM32_SDIO_DMAPRIO - Select SDIO DMA interrupt priority. Default: Medium
|
||||||
|
|
||||||
|
CONFIG_STM32_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default:
|
||||||
|
4-bit transfer mode.
|
||||||
|
|
||||||
|
USB
|
||||||
|
---
|
||||||
|
|
||||||
|
STM32 USB OTG FS Host Driver Support
|
||||||
|
|
||||||
|
Pre-requisites::
|
||||||
|
|
||||||
|
CONFIG_USBDEV - Enable USB device support
|
||||||
|
CONFIG_USBHOST - Enable USB host support
|
||||||
|
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
|
||||||
|
CONFIG_STM32_SYSCFG - Needed
|
||||||
|
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
|
||||||
|
|
||||||
|
Options:
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
|
||||||
|
Default 128 (512 bytes)
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
|
||||||
|
in 32-bit words. Default 96 (384 bytes)
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
|
||||||
|
words. Default 96 (384 bytes)
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
|
||||||
|
|
||||||
|
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
|
||||||
|
want to do that?
|
||||||
|
|
||||||
|
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
|
||||||
|
debug. Depends on CONFIG_DEBUG_FEATURES.
|
||||||
|
|
||||||
|
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
|
||||||
|
packets. Depends on CONFIG_DEBUG_FEATURES.
|
||||||
|
|
||||||
|
LTDC hardware acceleration
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
The LTDC driver provides two 2 LTDC overlays and supports the following hardware
|
||||||
|
acceleration and features:
|
||||||
|
|
||||||
|
Configured at build time
|
||||||
|
- background color
|
||||||
|
- default color (outside visible screen)
|
||||||
|
|
||||||
|
Configurable by nuttx framebuffer interface
|
||||||
|
|
||||||
|
- cmap support (color table is shared by both LTDC overlays and DMA2D when enabled)
|
||||||
|
|
||||||
|
Configurable via the nuttx framebuffer interface (for each layer separately)
|
||||||
|
|
||||||
|
- chromakey
|
||||||
|
|
||||||
|
- transparency (const alpha and pixel alpha)
|
||||||
|
|
||||||
|
- blank
|
||||||
|
|
||||||
|
- color (if DMA2D is enabled and cmap is disabled)
|
||||||
|
|
||||||
|
- blit (if DMA2D is enabled)
|
||||||
|
|
||||||
|
- blend (if DMA2D is enabled and cmap is disabled)
|
||||||
|
|
||||||
|
LTDC overlays are similar to a non-destructive overlay. Both LTDC overlays will
|
||||||
|
be permanently blended in the order (background -> overlay 0 -> overlay 1) and
|
||||||
|
converted to a resulting video signal by the LTDC controller. That means each
|
||||||
|
operation with a LTDC overlay (Overlay 0 and Overlay 1) via nuttx framebuffer
|
||||||
|
interface will be visible immediately.
|
||||||
|
Think about continuous blending between both overlays.
|
||||||
|
|
||||||
|
DMA2D hardware acceleration
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
The DMA2D driver implements the following hardware acceleration:
|
||||||
|
|
||||||
|
Configurable via the nuttx framebuffer interface
|
||||||
|
|
||||||
|
- cmap support (color table is shared by all DMA2D overlays and LTDC overlays)
|
||||||
|
|
||||||
|
Configurable via the nuttx framebuffer interface (for each layer separately)
|
||||||
|
|
||||||
|
- color (fill memory region with a specific ARGB8888 color immediately), if
|
||||||
|
cmap is disabled
|
||||||
|
- blit (copy memory region to another memory region with pixel format
|
||||||
|
conversion if necessary)
|
||||||
|
- blend (blend two memory regions and copy the result to a third memory region
|
||||||
|
with pixel format conversion if necessary), if cmap is disabled
|
||||||
|
|
||||||
|
Blit and blend operation using a fixes memory size defined by the background
|
||||||
|
layer. DMA2D controller doesn't support scaling.
|
||||||
|
|
||||||
|
DMA2D overlays are similar to destructive overlays. They are invisible. They can
|
||||||
|
be used for image preprocessing. The memory region affected by the operations
|
||||||
|
(color, blit, blend) can be addressed by the area control command before. The
|
||||||
|
configured overlay transparency of DMA2D overlays will be used for subsequently
|
||||||
|
blend operation and is valid for the whole overlay.
|
||||||
|
|
||||||
|
FPU
|
||||||
|
===
|
||||||
|
|
||||||
|
FPU Configuration Options
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
There are two version of the FPU support built into the STM32 port.
|
||||||
|
|
||||||
|
1. Non-Lazy Floating Point Register Save
|
||||||
|
|
||||||
|
In this configuration floating point register save and restore is
|
||||||
|
implemented on interrupt entry and return, respectively. In this
|
||||||
|
case, you may use floating point operations for interrupt handling
|
||||||
|
logic if necessary. This FPU behavior logic is enabled by default
|
||||||
|
with::
|
||||||
|
|
||||||
|
CONFIG_ARCH_FPU=y
|
||||||
|
|
||||||
|
2. Lazy Floating Point Register Save.
|
||||||
|
|
||||||
|
An alternative implementation only 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::
|
||||||
|
|
||||||
|
CONFIG_ARCH_FPU=y
|
||||||
|
|
||||||
|
Development Environment
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Either Linux or Cygwin on Windows can be used for the development environment.
|
||||||
|
The source has been built only using the GNU toolchain (see below). Other
|
||||||
|
toolchains will likely cause problems.
|
||||||
|
|
||||||
|
GNU Toolchain Options
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Toolchain Configurations
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
The NuttX make system has been modified to support the following different
|
||||||
|
toolchain options.
|
||||||
|
|
||||||
|
1. The NuttX buildroot Toolchain (see below), or
|
||||||
|
|
||||||
|
2. Any generic arm-none-eabi GNU toolchain.
|
||||||
|
|
||||||
|
All testing has been conducted using the NuttX Codesourcery toolchain. To use
|
||||||
|
a different toolchain, you simply need to modify the configuration. As an
|
||||||
|
example::
|
||||||
|
|
||||||
|
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
|
||||||
|
|
||||||
|
IDEs
|
||||||
|
====
|
||||||
|
|
||||||
|
NuttX is built using command-line make. It can be used with an IDE, but some
|
||||||
|
effort will be required to create the project.
|
||||||
|
|
||||||
|
Makefile Build
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
|
||||||
|
simply use the NuttX makefile to build the system. That is almost for free
|
||||||
|
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
|
||||||
|
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
|
||||||
|
there is a lot of help on the internet).
|
||||||
|
|
||||||
|
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
|
||||||
|
Download and install the latest version (as of this writing it was sourceryg++-2013.05-64-arm-none-eabi)
|
||||||
|
|
||||||
|
Import the project from git.
|
||||||
|
File->import->Git-URI, then import a Exiting code as a Makefile progject
|
||||||
|
from the working directory the git clone was done to.
|
||||||
|
|
||||||
|
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
|
||||||
|
build, before the make will work in CodeBench.
|
||||||
|
|
||||||
|
Native Build
|
||||||
|
------------
|
||||||
|
|
||||||
|
Here are a few tips before you start that effort:
|
||||||
|
|
||||||
|
1) Select the toolchain that you will be using in your .config file
|
||||||
|
|
||||||
|
2) Start the NuttX build at least one time from the Cygwin command line
|
||||||
|
before trying to create your project. This is necessary to create
|
||||||
|
certain auto-generated files and directories that will be needed.
|
||||||
|
|
||||||
|
3) Set up include paths: You will need include/, arch/arm/src/stm32,
|
||||||
|
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
|
||||||
|
|
||||||
|
4) All assembly files need to have the definition option -D __ASSEMBLY__
|
||||||
|
on the command line.
|
||||||
|
|
||||||
|
Startup files will probably cause you some headaches. The NuttX startup file
|
||||||
|
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
|
||||||
|
one time from the Cygwin command line in order to obtain the pre-built
|
||||||
|
startup object needed by RIDE.
|
||||||
|
|
||||||
|
NuttX EABI "buildroot" Toolchain
|
||||||
|
================================
|
||||||
|
|
||||||
|
A GNU GCC-based toolchain is assumed. The PATH environment variable should
|
||||||
|
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
|
||||||
|
different from the default in your PATH variable).
|
||||||
|
|
||||||
|
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
|
||||||
|
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
|
||||||
|
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
||||||
|
|
||||||
|
NXFLAT Toolchain
|
||||||
|
================
|
||||||
|
|
||||||
|
If you are *not* using the NuttX buildroot toolchain and you want to use
|
||||||
|
the NXFLAT tools, then you will still have to build a portion of the buildroot
|
||||||
|
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
|
||||||
|
be downloaded from the NuttX Bitbucket download site
|
||||||
|
(https://bitbucket.org/nuttx/nuttx/downloads/).
|
||||||
|
|
||||||
|
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
||||||
|
|
||||||
|
1. You must have already configured NuttX in <some-dir>/nuttx.
|
||||||
|
|
||||||
|
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
|
||||||
|
|
||||||
|
2. Download the latest buildroot package into <some-dir>
|
||||||
|
|
||||||
|
3. unpack the buildroot tarball. The resulting directory may
|
||||||
|
have versioning information on it like buildroot-x.y.z. If so,
|
||||||
|
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
|
||||||
|
|
||||||
|
4. cd <some-dir>/buildroot
|
||||||
|
|
||||||
|
5. cp boards/cortexm3-defconfig-nxflat .config
|
||||||
|
|
||||||
|
6. make oldconfig
|
||||||
|
|
||||||
|
7. make
|
||||||
|
|
||||||
|
8. Make sure that the PATH variable includes the path to the newly built
|
||||||
|
NXFLAT binaries.
|
||||||
|
|
||||||
|
Protected Mode Build
|
||||||
|
====================
|
||||||
|
|
||||||
|
The "protected" mode build uses the Cormtex-M4 MPU to separate the FLASH and
|
||||||
|
SRAM into kernel-mode and user-mode regions. The kernel mode regions are
|
||||||
|
then protected from any errant or mischievous behavior from user-space
|
||||||
|
applications.
|
||||||
|
|
||||||
|
Common notes for all protected mode builds follow:
|
||||||
|
|
||||||
|
1. It is recommends to use a special make command; not just 'make' but make
|
||||||
|
with the following two arguments::
|
||||||
|
|
||||||
|
make pass1 pass2
|
||||||
|
|
||||||
|
In the normal case (just 'make'), make will attempt to build both user-
|
||||||
|
and kernel-mode blobs more or less interleaved. That actual works!
|
||||||
|
However, for me it is very confusing so I prefer the above make command:
|
||||||
|
Make the user-space binaries first (pass1), then make the kernel-space
|
||||||
|
binaries (pass2)
|
||||||
|
|
||||||
|
2. At the end of the build, there will be several files in the top-level
|
||||||
|
NuttX build directory::
|
||||||
|
|
||||||
|
PASS1:
|
||||||
|
nuttx_user.elf - The pass1 user-space ELF file
|
||||||
|
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
||||||
|
User.map - Symbols in the user-space ELF file
|
||||||
|
|
||||||
|
PASS2:
|
||||||
|
nuttx - The pass2 kernel-space ELF file
|
||||||
|
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
||||||
|
System.map - Symbols in the kernel-space ELF file
|
||||||
|
|
||||||
|
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
|
||||||
|
formats.
|
||||||
|
|
||||||
|
3. Combining .hex files. If you plan to use the .hex files with your
|
||||||
|
debugger or FLASH utility, then you may need to combine the two hex
|
||||||
|
files into a single .hex file. Here is how you can do that.
|
||||||
|
|
||||||
|
a. The 'tail' of the nuttx.hex file should look something like this
|
||||||
|
(with my comments added)::
|
||||||
|
|
||||||
|
$ tail nuttx.hex
|
||||||
|
# 00, data records
|
||||||
|
...
|
||||||
|
:10 9DC0 00 01000000000800006400020100001F0004
|
||||||
|
:10 9DD0 00 3B005A0078009700B500D400F300110151
|
||||||
|
:08 9DE0 00 30014E016D0100008D
|
||||||
|
# 05, Start Linear Address Record
|
||||||
|
:04 0000 05 0800 0419 D2
|
||||||
|
# 01, End Of File record
|
||||||
|
:00 0000 01 FF
|
||||||
|
|
||||||
|
Use an editor such as vi to remove the 05 and 01 records.
|
||||||
|
|
||||||
|
b. The 'head' of the nuttx_user.hex file should look something like
|
||||||
|
this (again with my comments added)::
|
||||||
|
|
||||||
|
$ head nuttx_user.hex
|
||||||
|
# 04, Extended Linear Address Record
|
||||||
|
:02 0000 04 0801 F1
|
||||||
|
# 00, data records
|
||||||
|
:10 8000 00 BD89 01084C800108C8110208D01102087E
|
||||||
|
:10 8010 00 0010 00201C1000201C1000203C16002026
|
||||||
|
:10 8020 00 4D80 01085D80010869800108ED83010829
|
||||||
|
...
|
||||||
|
|
||||||
|
Nothing needs to be done here. The nuttx_user.hex file should
|
||||||
|
be fine.
|
||||||
|
|
||||||
|
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
||||||
|
file to produce a single combined hex file::
|
||||||
|
|
||||||
|
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
||||||
|
|
||||||
|
Then use the combined.hex file with the to write the FLASH image. With
|
||||||
|
GDB this would be::
|
||||||
|
|
||||||
|
gdb> mon reset
|
||||||
|
gdb> mon halt
|
||||||
|
gdb> mon clrbp
|
||||||
|
gdb> load combined.hex
|
||||||
|
|
||||||
|
If you do this a lot, you will probably want to invest a little time
|
||||||
|
to develop a tool to automate these steps.
|
||||||
|
|
||||||
|
Supported Boards
|
||||||
|
================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
boards/*/*
|
||||||
@ -1,6 +1,6 @@
|
|||||||
========
|
===========
|
||||||
STM32WL5
|
ST STM32WL5
|
||||||
========
|
===========
|
||||||
|
|
||||||
The STM32WL5 is a dual CPU (not core!) chip based on ARM Cortex-M4 and
|
The STM32WL5 is a dual CPU (not core!) chip based on ARM Cortex-M4 and
|
||||||
Cortex-M0 with integrated sub-GHz radio for LoRa (G)FSK, (G)MSK and BPSK
|
Cortex-M0 with integrated sub-GHz radio for LoRa (G)FSK, (G)MSK and BPSK
|
||||||
|
|||||||
@ -1,659 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the
|
|
||||||
MikroElektronika Mikromedia for STM32F4 development board. This is
|
|
||||||
another board support by NuttX that uses the same STM32F407VGT6 MCU
|
|
||||||
as does the STM32F4-Discovery board. This board, however, has very
|
|
||||||
different on-board peripherals than does the STM32F4-Discovery:
|
|
||||||
|
|
||||||
- TFT display with touch panel,
|
|
||||||
- VS1053 stereo audio codec with headphone jack,
|
|
||||||
- SD card slot,
|
|
||||||
- Serial FLASH memory,
|
|
||||||
- USB OTG FS with micro-AB connector, and
|
|
||||||
- Battery connect and batter charger circuit.
|
|
||||||
|
|
||||||
See the http://www.mikroe.com/mikromedia/stm32-m4/ for more information
|
|
||||||
about this board.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- LEDs
|
|
||||||
- PWM
|
|
||||||
- UARTs
|
|
||||||
- Timer Inputs/Outputs
|
|
||||||
- FPU
|
|
||||||
- FSMC SRAM
|
|
||||||
- SSD1289
|
|
||||||
- Mikroe-STM32F4-specific Configuration Options
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
====
|
|
||||||
|
|
||||||
The Mikroe-STM32F4 board has no user accessible LEDs onboard, only a power
|
|
||||||
and "charging" LED. All visual user output must be performed through the TFT
|
|
||||||
display.
|
|
||||||
|
|
||||||
External LEDs could be added via the expansion headers on the side of the
|
|
||||||
board, but as this would be a custom configuration, LEDs are not supported
|
|
||||||
in this port.
|
|
||||||
|
|
||||||
PWM
|
|
||||||
===
|
|
||||||
|
|
||||||
The Mikroe-STM32F4 has no real on-board PWM devices, but it does have PWM
|
|
||||||
pins routed to the expansion I/O headers on the side of the board.
|
|
||||||
|
|
||||||
UARTs
|
|
||||||
=====
|
|
||||||
|
|
||||||
The Mikroe-STM32F4 board has no onboard RS-232 line driver, however the
|
|
||||||
expansion I/O header provides access to USART2 on pins PD5/PD6. The port
|
|
||||||
includes support for USART2 configured as /dev/ttyS0.
|
|
||||||
|
|
||||||
UART/USART PINS
|
|
||||||
---------------
|
|
||||||
|
|
||||||
USART2
|
|
||||||
RX PD6
|
|
||||||
TX PD5
|
|
||||||
|
|
||||||
Default USART/UART Configuration
|
|
||||||
--------------------------------
|
|
||||||
|
|
||||||
USART2 is enabled in all configurations (see */defconfig). RX and TX are
|
|
||||||
configured on pins PD6 and PD5, respectively (see include/board.h).
|
|
||||||
|
|
||||||
Timer Inputs/Outputs
|
|
||||||
====================
|
|
||||||
|
|
||||||
TIM1
|
|
||||||
CH1 PA8, PE9
|
|
||||||
CH2 PA9*, PE11
|
|
||||||
CH3 PA10*, PE13
|
|
||||||
CH4 PA11*, PE14
|
|
||||||
TIM2
|
|
||||||
CH1 PA0*, PA15, PA5*
|
|
||||||
CH2 PA1, PB3*
|
|
||||||
CH3 PA2, PB10*
|
|
||||||
CH4 PA3, PB11
|
|
||||||
TIM3
|
|
||||||
CH1 PA6*, PB4, PC6
|
|
||||||
CH2 PA7*, PB5, PC7*
|
|
||||||
CH3 PB0, PC8
|
|
||||||
CH4 PB1, PC9
|
|
||||||
TIM4
|
|
||||||
CH1 PB6*, PD12*
|
|
||||||
CH2 PB7, PD13*
|
|
||||||
CH3 PB8, PD14*
|
|
||||||
CH4 PB9*, PD15*
|
|
||||||
TIM5
|
|
||||||
CH1 PA0*, PH10**
|
|
||||||
CH2 PA1, PH11**
|
|
||||||
CH3 PA2, PH12**
|
|
||||||
CH4 PA3, PI0
|
|
||||||
TIM8
|
|
||||||
CH1 PC6, PI5
|
|
||||||
CH2 PC7*, PI6
|
|
||||||
CH3 PC8, PI7
|
|
||||||
CH4 PC9, PI2
|
|
||||||
TIM9
|
|
||||||
CH1 PA2, PE5
|
|
||||||
CH2 PA3, PE6
|
|
||||||
TIM10
|
|
||||||
CH1 PB8, PF6
|
|
||||||
TIM11
|
|
||||||
CH1 PB9*, PF7
|
|
||||||
TIM12
|
|
||||||
CH1 PH6**, PB14
|
|
||||||
CH2 PC15, PH9**
|
|
||||||
TIM13
|
|
||||||
CH1 PA6*, PF8
|
|
||||||
TIM14
|
|
||||||
CH1 PA7*, PF9
|
|
||||||
|
|
||||||
* Indicates pins that have other on-board functions and should be used only
|
|
||||||
with care (See table 5 in the Mikroe-STM32F4 User Guide). The rest are
|
|
||||||
free I/O pins.
|
|
||||||
** Port H pins are not supported by the MCU
|
|
||||||
|
|
||||||
FPU
|
|
||||||
===
|
|
||||||
|
|
||||||
FPU Configuration Options
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
There are two version of the FPU support built into the STM32 port.
|
|
||||||
|
|
||||||
1. Non-Lazy Floating Point Register Save
|
|
||||||
|
|
||||||
In this configuration floating point register save and restore is
|
|
||||||
implemented on interrupt entry and return, respectively. In this
|
|
||||||
case, you may use floating point operations for interrupt handling
|
|
||||||
logic if necessary. This FPU behavior logic is enabled by default
|
|
||||||
with:
|
|
||||||
|
|
||||||
CONFIG_ARCH_FPU=y
|
|
||||||
|
|
||||||
2. Lazy Floating Point Register Save.
|
|
||||||
|
|
||||||
An alternative implementation only 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:
|
|
||||||
|
|
||||||
CONFIG_ARCH_FPU=y
|
|
||||||
|
|
||||||
MIO283QT-2/MIO283QT-9A
|
|
||||||
======================
|
|
||||||
|
|
||||||
The original Mikroe-SMT32F4 board as an on-board MIO283QT-2 TFT LCD that can
|
|
||||||
be configured and used. This is a 320x240 resolution display with color
|
|
||||||
capability to 262K colors, though the mio283qt-2 driver in NuttX only
|
|
||||||
supports 16-bit color depth, or 65K colors. Changes to both the
|
|
||||||
mio283qt-2 driver and the driver interface layer would need to be made
|
|
||||||
to support 24 BPP mode.
|
|
||||||
|
|
||||||
UPDATE: New boards now support a MIO283QT-9A TFT LCD that is not compatible
|
|
||||||
with the MIO283QT-2. It uses a different LCD controller. The default in
|
|
||||||
all of these configurations is the MIO283QT-2. But MIO283QT-9A is also
|
|
||||||
supported and you can switch from the MIO283QT-2 to the MIO283QT-9A by simply
|
|
||||||
modifying the NuttX configuration
|
|
||||||
|
|
||||||
Mikroe-STM32F4-specific Configuration Options
|
|
||||||
===============================================
|
|
||||||
|
|
||||||
CONFIG_ARCH - Identifies the arch/ subdirectory. This should
|
|
||||||
be set to:
|
|
||||||
|
|
||||||
CONFIG_ARCH=arm
|
|
||||||
|
|
||||||
CONFIG_ARCH_family - For use in C code:
|
|
||||||
|
|
||||||
CONFIG_ARCH_ARM=y
|
|
||||||
|
|
||||||
CONFIG_ARCH_architecture - For use in C code:
|
|
||||||
|
|
||||||
CONFIG_ARCH_CORTEXM4=y
|
|
||||||
|
|
||||||
CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory
|
|
||||||
|
|
||||||
CONFIG_ARCH_CHIP=stm32
|
|
||||||
|
|
||||||
CONFIG_ARCH_CHIP_name - For use in C code to identify the exact
|
|
||||||
chip:
|
|
||||||
|
|
||||||
CONFIG_ARCH_CHIP_STM32F407VG=y
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock
|
|
||||||
configuration features.
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD - Identifies the boards/ subdirectory and
|
|
||||||
hence, the board that supports the particular chip or SoC.
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD=Mikroe-STM32F4 (for the Mikroe-STM32F4 development board)
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD_name - For use in C code
|
|
||||||
|
|
||||||
CONFIG_ARCH_BOARD_STM32F4_DISCOVERY=y
|
|
||||||
|
|
||||||
CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation
|
|
||||||
of delay loops
|
|
||||||
|
|
||||||
CONFIG_ENDIAN_BIG - define if big endian (default is little
|
|
||||||
endian)
|
|
||||||
|
|
||||||
CONFIG_RAM_SIZE - Describes the installed DRAM (SRAM in this case):
|
|
||||||
|
|
||||||
CONFIG_RAM_SIZE=0x00010000 (64Kb)
|
|
||||||
|
|
||||||
CONFIG_RAM_START - The start address of installed DRAM
|
|
||||||
|
|
||||||
CONFIG_RAM_START=0x20000000
|
|
||||||
|
|
||||||
CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP
|
|
||||||
|
|
||||||
In addition to internal SRAM, SRAM may also be available through the FSMC.
|
|
||||||
In order to use FSMC SRAM, the following additional things need to be
|
|
||||||
present in the NuttX configuration file:
|
|
||||||
|
|
||||||
CONFIG_HEAP2_BASE - The base address of the SRAM in the FSMC address space (hex)
|
|
||||||
|
|
||||||
CONFIG_HEAP2_SIZE - The size of the SRAM in the FSMC address space (decimal)
|
|
||||||
|
|
||||||
CONFIG_ARCH_FPU - The Mikroe-STM32F4 supports a floating point unit (FPU)
|
|
||||||
|
|
||||||
CONFIG_ARCH_FPU=y
|
|
||||||
|
|
||||||
CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
|
|
||||||
stack. If defined, this symbol is the size of the interrupt
|
|
||||||
stack in bytes. If not defined, the user task stacks will be
|
|
||||||
used during interrupt handling.
|
|
||||||
|
|
||||||
CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions
|
|
||||||
|
|
||||||
CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to board architecture.
|
|
||||||
|
|
||||||
Individual subsystems can be enabled:
|
|
||||||
|
|
||||||
AHB1
|
|
||||||
----
|
|
||||||
CONFIG_STM32_CRC
|
|
||||||
CONFIG_STM32_BKPSRAM
|
|
||||||
CONFIG_STM32_CCMDATARAM
|
|
||||||
CONFIG_STM32_DMA1
|
|
||||||
CONFIG_STM32_DMA2
|
|
||||||
CONFIG_STM32_ETHMAC
|
|
||||||
CONFIG_STM32_OTGHS
|
|
||||||
|
|
||||||
AHB2
|
|
||||||
----
|
|
||||||
CONFIG_STM32_DCMI
|
|
||||||
CONFIG_STM32_CRYP
|
|
||||||
CONFIG_STM32_HASH
|
|
||||||
CONFIG_STM32_RNG
|
|
||||||
CONFIG_STM32_OTGFS
|
|
||||||
|
|
||||||
AHB3
|
|
||||||
----
|
|
||||||
CONFIG_STM32_FSMC
|
|
||||||
|
|
||||||
APB1
|
|
||||||
----
|
|
||||||
CONFIG_STM32_TIM2
|
|
||||||
CONFIG_STM32_TIM3
|
|
||||||
CONFIG_STM32_TIM4
|
|
||||||
CONFIG_STM32_TIM5
|
|
||||||
CONFIG_STM32_TIM6
|
|
||||||
CONFIG_STM32_TIM7
|
|
||||||
CONFIG_STM32_TIM12
|
|
||||||
CONFIG_STM32_TIM13
|
|
||||||
CONFIG_STM32_TIM14
|
|
||||||
CONFIG_STM32_WWDG
|
|
||||||
CONFIG_STM32_IWDG
|
|
||||||
CONFIG_STM32_SPI2
|
|
||||||
CONFIG_STM32_SPI3
|
|
||||||
CONFIG_STM32_USART2
|
|
||||||
CONFIG_STM32_USART3
|
|
||||||
CONFIG_STM32_UART4
|
|
||||||
CONFIG_STM32_UART5
|
|
||||||
CONFIG_STM32_I2C1
|
|
||||||
CONFIG_STM32_I2C2
|
|
||||||
CONFIG_STM32_I2C3
|
|
||||||
CONFIG_STM32_CAN1
|
|
||||||
CONFIG_STM32_CAN2
|
|
||||||
CONFIG_STM32_DAC1
|
|
||||||
CONFIG_STM32_DAC2
|
|
||||||
CONFIG_STM32_PWR -- Required for RTC
|
|
||||||
|
|
||||||
APB2
|
|
||||||
----
|
|
||||||
CONFIG_STM32_TIM1
|
|
||||||
CONFIG_STM32_TIM8
|
|
||||||
CONFIG_STM32_USART1
|
|
||||||
CONFIG_STM32_USART6
|
|
||||||
CONFIG_STM32_ADC1
|
|
||||||
CONFIG_STM32_ADC2
|
|
||||||
CONFIG_STM32_ADC3
|
|
||||||
CONFIG_STM32_SDIO
|
|
||||||
CONFIG_STM32_SPI1
|
|
||||||
CONFIG_STM32_SYSCFG
|
|
||||||
CONFIG_STM32_TIM9
|
|
||||||
CONFIG_STM32_TIM10
|
|
||||||
CONFIG_STM32_TIM11
|
|
||||||
|
|
||||||
Timer devices may be used for different purposes. One special purpose is
|
|
||||||
to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn
|
|
||||||
is defined (as above) then the following may also be defined to indicate that
|
|
||||||
the timer is intended to be used for pulsed output modulation, ADC conversion,
|
|
||||||
or DAC conversion. Note that ADC/DAC require two definition: Not only do you have
|
|
||||||
to assign the timer (n) for used by the ADC or DAC, but then you also have to
|
|
||||||
configure which ADC or DAC (m) it is assigned to.
|
|
||||||
|
|
||||||
CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14
|
|
||||||
CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14
|
|
||||||
CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3
|
|
||||||
CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14
|
|
||||||
CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2
|
|
||||||
|
|
||||||
For each timer that is enabled for PWM usage, we need the following additional
|
|
||||||
configuration settings:
|
|
||||||
|
|
||||||
CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4}
|
|
||||||
|
|
||||||
NOTE: The STM32 timers are each capable of generating different signals on
|
|
||||||
each of the four channels with different duty cycles. That capability is
|
|
||||||
not supported by this driver: Only one output channel per timer.
|
|
||||||
|
|
||||||
JTAG Enable settings (by default only SW-DP is enabled):
|
|
||||||
|
|
||||||
CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
|
|
||||||
CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP)
|
|
||||||
but without JNTRST.
|
|
||||||
CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled
|
|
||||||
|
|
||||||
Mikroe-STM32F4 specific device driver settings
|
|
||||||
|
|
||||||
CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART
|
|
||||||
m (m=4,5) for the console and ttys0 (default is the USART1).
|
|
||||||
CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received.
|
|
||||||
This specific the size of the receive buffer
|
|
||||||
CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before
|
|
||||||
being sent. This specific the size of the transmit buffer
|
|
||||||
CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be
|
|
||||||
CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8.
|
|
||||||
CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity
|
|
||||||
CONFIG_U[S]ARTn_2STOP - Two stop bits
|
|
||||||
|
|
||||||
Mikroe-STM32F4 CAN Configuration
|
|
||||||
|
|
||||||
CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or
|
|
||||||
CONFIG_STM32_CAN2 must also be defined)
|
|
||||||
CONFIG_CAN_EXTID - Enables support for the 29-bit extended ID. Default
|
|
||||||
Standard 11-bit IDs.
|
|
||||||
CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages.
|
|
||||||
Default: 8
|
|
||||||
CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests.
|
|
||||||
Default: 4
|
|
||||||
CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback
|
|
||||||
mode for testing. The STM32 CAN driver does support loopback mode.
|
|
||||||
CONFIG_STM32_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1
|
|
||||||
is defined.
|
|
||||||
CONFIG_STM32_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2
|
|
||||||
is defined.
|
|
||||||
CONFIG_STM32_CAN_TSEG1 - The number of CAN time quanta in segment 1.
|
|
||||||
Default: 6
|
|
||||||
CONFIG_STM32_CAN_TSEG2 - the number of CAN time quanta in segment 2.
|
|
||||||
Default: 7
|
|
||||||
CONFIG_STM32_CAN_REGDEBUG - If CONFIG_DEBUG_FEATURES is set, this will generate an
|
|
||||||
dump of all CAN registers.
|
|
||||||
|
|
||||||
Mikroe-STM32F4 SPI Configuration
|
|
||||||
|
|
||||||
CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI
|
|
||||||
support. Non-interrupt-driven, poll-waiting is recommended if the
|
|
||||||
interrupt rate would be to high in the interrupt driven case.
|
|
||||||
CONFIG_STM32_SPIx_DMA - Use DMA to improve SPIx transfer performance.
|
|
||||||
Cannot be used with CONFIG_STM32_SPI_INTERRUPT.
|
|
||||||
|
|
||||||
Mikroe-STM32F4 DMA Configuration
|
|
||||||
|
|
||||||
CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO
|
|
||||||
and CONFIG_STM32_DMA2.
|
|
||||||
CONFIG_STM32_SDIO_PRI - Select SDIO interrupt priority. Default: 128
|
|
||||||
CONFIG_STM32_SDIO_DMAPRIO - Select SDIO DMA interrupt priority.
|
|
||||||
Default: Medium
|
|
||||||
CONFIG_STM32_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default:
|
|
||||||
4-bit transfer mode.
|
|
||||||
|
|
||||||
STM32 USB OTG FS Host Driver Support
|
|
||||||
|
|
||||||
Pre-requisites
|
|
||||||
|
|
||||||
CONFIG_USBDEV - Enable USB device support
|
|
||||||
CONFIG_USBHOST - Enable USB host support
|
|
||||||
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
|
|
||||||
CONFIG_STM32_SYSCFG - Needed
|
|
||||||
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
|
|
||||||
|
|
||||||
Options:
|
|
||||||
|
|
||||||
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
|
|
||||||
Default 128 (512 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
|
|
||||||
in 32-bit words. Default 96 (384 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
|
|
||||||
words. Default 96 (384 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
|
|
||||||
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
|
|
||||||
want to do that?
|
|
||||||
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
|
|
||||||
debug. Depends on CONFIG_DEBUG_FEATURES.
|
|
||||||
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
|
|
||||||
packets. Depends on CONFIG_DEBUG_FEATURES.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
Each Mikroe-STM32F4 configuration is maintained in a sub-directory and
|
|
||||||
can be selected as follow:
|
|
||||||
|
|
||||||
tools/configure.sh mikroe-stm32f4:<subdir>
|
|
||||||
|
|
||||||
If this is a Windows native build, then configure.bat should be used
|
|
||||||
instead of configure.sh:
|
|
||||||
|
|
||||||
configure.bat Mikroe-STM32F4\<subdir>
|
|
||||||
|
|
||||||
Where <subdir> is one of the following:
|
|
||||||
|
|
||||||
fulldemo
|
|
||||||
--------
|
|
||||||
This is an example that includes an NSH shell over USB that also
|
|
||||||
enables all features of the Mikroe-STM32F4 board including the LCD,
|
|
||||||
on-board 1M Flash with SMART filesystem, Aux RS-232 serial port on the
|
|
||||||
expansion header, etc. A couple of the NX graphics commands are made
|
|
||||||
available via the NSH prompt for performing LCD demonstrations, and the
|
|
||||||
nximage example is used as a splash-screen at startup.
|
|
||||||
|
|
||||||
kostest:
|
|
||||||
-------
|
|
||||||
NOTE: This configuration compiles, but has not been fully tested
|
|
||||||
on the hardware yet.
|
|
||||||
|
|
||||||
This configuration directory, performs a simple OS test using
|
|
||||||
apps/examples/ostest with NuttX build as a kernel-mode monolithic
|
|
||||||
module and the user applications are built separately. Is
|
|
||||||
is recommended to use a special make command; not just 'make' but
|
|
||||||
make with the following two arguments:
|
|
||||||
|
|
||||||
make pass1 pass2
|
|
||||||
|
|
||||||
In the normal case (just 'make'), make will attempt to build both user-
|
|
||||||
and kernel-mode blobs more or less interleaved. This actual works!
|
|
||||||
However, for me it is very confusing so I prefer the above make command:
|
|
||||||
Make the user-space binaries first (pass1), then make the kernel-space
|
|
||||||
binaries (pass2)
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
|
|
||||||
2. This is the default platform/toolchain in the configuration:
|
|
||||||
|
|
||||||
CONFIG_HOST_WINDOWS=y : Windows
|
|
||||||
CONFIG_WINDOWS_CYGWIN=y : Cygwin environment on Windows
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
|
||||||
|
|
||||||
This is easily changed by modifying the configuration.
|
|
||||||
|
|
||||||
3. At the end of the build, there will be several files in the top-level
|
|
||||||
NuttX build directory:
|
|
||||||
|
|
||||||
PASS1:
|
|
||||||
nuttx_user.elf - The pass1 user-space ELF file
|
|
||||||
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
|
||||||
User.map - Symbols in the user-space ELF file
|
|
||||||
|
|
||||||
PASS2:
|
|
||||||
nuttx - The pass2 kernel-space ELF file
|
|
||||||
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
|
||||||
System.map - Symbols in the kernel-space ELF file
|
|
||||||
|
|
||||||
4. Combining .hex files. If you plan to use the STM32 ST-Link Utility to
|
|
||||||
load the .hex files into FLASH, then you need to combine the two hex
|
|
||||||
files into a single .hex file. Here is how you can do that.
|
|
||||||
|
|
||||||
a. The 'tail' of the nuttx.hex file should look something like this
|
|
||||||
(with my comments added):
|
|
||||||
|
|
||||||
$ tail nuttx.hex
|
|
||||||
# 00, data records
|
|
||||||
...
|
|
||||||
:10 9DC0 00 01000000000800006400020100001F0004
|
|
||||||
:10 9DD0 00 3B005A0078009700B500D400F300110151
|
|
||||||
:08 9DE0 00 30014E016D0100008D
|
|
||||||
# 05, Start Linear Address Record
|
|
||||||
:04 0000 05 0800 0419 D2
|
|
||||||
# 01, End Of File record
|
|
||||||
:00 0000 01 FF
|
|
||||||
|
|
||||||
Use an editor such as vi to remove the 05 and 01 records.
|
|
||||||
|
|
||||||
b. The 'head' of the nuttx_user.hex file should look something like
|
|
||||||
this (again with my comments added):
|
|
||||||
|
|
||||||
$ head nuttx_user.hex
|
|
||||||
# 04, Extended Linear Address Record
|
|
||||||
:02 0000 04 0801 F1
|
|
||||||
# 00, data records
|
|
||||||
:10 8000 00 BD89 01084C800108C8110208D01102087E
|
|
||||||
:10 8010 00 0010 00201C1000201C1000203C16002026
|
|
||||||
:10 8020 00 4D80 01085D80010869800108ED83010829
|
|
||||||
...
|
|
||||||
|
|
||||||
Nothing needs to be done here. The nuttx_user.hex file should
|
|
||||||
be fine.
|
|
||||||
|
|
||||||
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
|
||||||
file to produce a single combined hex file:
|
|
||||||
|
|
||||||
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
|
||||||
|
|
||||||
Then use the combined.hex file with the STM32 ST-Link tool. If
|
|
||||||
you do this a lot, you will probably want to invest a little time
|
|
||||||
to develop a tool to automate these steps.
|
|
||||||
|
|
||||||
nsh
|
|
||||||
---
|
|
||||||
This is an NSH example that uses USART2 as the console. Note that
|
|
||||||
the Mikroe-STM32F4 board doesn't actually have onboard line drivers
|
|
||||||
or a connector for USART2, but it does route the USART2 signals to
|
|
||||||
the expansion header. To use this demo, you would need to connect
|
|
||||||
an external 3.3V RS-232 line driver to the USART's I/O lines on the
|
|
||||||
expansion header.
|
|
||||||
|
|
||||||
NOTE: This demo doesn't quite work yet. I can get output to the
|
|
||||||
USART, but so far, I have not gotten nsh to actually come up.
|
|
||||||
|
|
||||||
nx
|
|
||||||
--
|
|
||||||
An example using the NuttX graphics system (NX). This example
|
|
||||||
focuses on general window controls, movement, mouse and keyboard
|
|
||||||
input.
|
|
||||||
|
|
||||||
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
|
|
||||||
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
|
|
||||||
|
|
||||||
You can the newer MIO283QT-9A by enabling it in the configuration.
|
|
||||||
|
|
||||||
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
|
|
||||||
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
|
|
||||||
|
|
||||||
nxlines:
|
|
||||||
------
|
|
||||||
An example using the NuttX graphics system (NX). This example focuses on
|
|
||||||
placing lines on the background in various orientations using the
|
|
||||||
on-board TFT LCD.
|
|
||||||
|
|
||||||
CONFIG_LCD_LANDSCAPE=y : 320x240 landscape orientation
|
|
||||||
CONFIG_LCD_MIO283QT2=y : MIO283QT-2 is the default
|
|
||||||
|
|
||||||
You can the newer MIO283QT-9A by enabling it in the configuration.
|
|
||||||
|
|
||||||
CONFIG_LCD_MIO283QT2=n : Disable the MIO283QT-2
|
|
||||||
CONFIG_LCD_MIO283QT9A=y : Enable the MIO283QT-9A
|
|
||||||
|
|
||||||
nxtext:
|
|
||||||
------
|
|
||||||
Another example using the NuttX graphics system (NX). This
|
|
||||||
example focuses on placing text on the background while pop-up
|
|
||||||
windows occur. Text should continue to update normally with
|
|
||||||
or without the popup windows present.
|
|
||||||
|
|
||||||
usbnsh:
|
|
||||||
-------
|
|
||||||
|
|
||||||
This is another NSH example. If differs from other 'nsh' configurations
|
|
||||||
in that this configurations uses a USB serial device for console I/O.
|
|
||||||
Such a configuration is useful on the stm32f4discovery which has no
|
|
||||||
builtin RS-232 drivers.
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
|
|
||||||
2. By default, this configuration uses the ARM EABI toolchain
|
|
||||||
for Windows and builds under Cygwin (or probably MSYS). That
|
|
||||||
can easily be reconfigured, of course.
|
|
||||||
|
|
||||||
CONFIG_HOST_WINDOWS=y : Builds under Windows
|
|
||||||
CONFIG_WINDOWS_CYGWIN=y : Using Cygwin
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Windows
|
|
||||||
|
|
||||||
3. This configuration does have UART2 output enabled and set up as
|
|
||||||
the system logging device:
|
|
||||||
|
|
||||||
CONFIG_SYSLOG_CHAR=y : Use a character device for system logging
|
|
||||||
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0" : UART2 will be /dev/ttyS0
|
|
||||||
|
|
||||||
However, there is nothing to generate SYSLOG output in the default
|
|
||||||
configuration so nothing should appear on UART2 unless you enable
|
|
||||||
some debug output or enable the USB monitor.
|
|
||||||
|
|
||||||
4. Enabling USB monitor SYSLOG output. If tracing is enabled, the USB
|
|
||||||
device will save encoded trace output in in-memory buffer; if the
|
|
||||||
USB monitor is enabled, that trace buffer will be periodically
|
|
||||||
emptied and dumped to the system logging device (UART2 in this
|
|
||||||
configuration):
|
|
||||||
|
|
||||||
CONFIG_USBDEV_TRACE=y : Enable USB trace feature
|
|
||||||
CONFIG_USBDEV_TRACE_NRECORDS=128 : Buffer 128 records in memory
|
|
||||||
CONFIG_NSH_USBDEV_TRACE=n : No builtin tracing from NSH
|
|
||||||
CONFIG_NSH_ARCHINIT=y : Automatically start the USB monitor
|
|
||||||
CONFIG_USBMONITOR=y : Enable the USB monitor daemon
|
|
||||||
CONFIG_USBMONITOR_STACKSIZE=2048 : USB monitor daemon stack size
|
|
||||||
CONFIG_USBMONITOR_PRIORITY=50 : USB monitor daemon priority
|
|
||||||
CONFIG_USBMONITOR_INTERVAL=2 : Dump trace data every 2 seconds
|
|
||||||
|
|
||||||
CONFIG_USBMONITOR_TRACEINIT=y : Enable TRACE output
|
|
||||||
CONFIG_USBMONITOR_TRACECLASS=y
|
|
||||||
CONFIG_USBMONITOR_TRACETRANSFERS=y
|
|
||||||
CONFIG_USBMONITOR_TRACECONTROLLER=y
|
|
||||||
CONFIG_USBMONITOR_TRACEINTERRUPTS=y
|
|
||||||
|
|
||||||
5. By default, this project assumes that you are *NOT* using the DFU
|
|
||||||
bootloader.
|
|
||||||
|
|
||||||
Using the Prolifics PL2303 Emulation
|
|
||||||
------------------------------------
|
|
||||||
You could also use the non-standard PL2303 serial device instead of
|
|
||||||
the standard CDC/ACM serial device by changing:
|
|
||||||
|
|
||||||
CONFIG_CDCACM=y : Disable the CDC/ACM serial device class
|
|
||||||
CONFIG_CDCACM_CONSOLE=y : The CDC/ACM serial device is NOT the console
|
|
||||||
CONFIG_PL2303=y : The Prolifics PL2303 emulation is enabled
|
|
||||||
CONFIG_PL2303_CONSOLE=y : The PL2303 serial device is the console
|
|
||||||
@ -1,250 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the ST
|
|
||||||
NucleoF410RB board from ST Micro. See
|
|
||||||
|
|
||||||
http://www.st.com/en/evaluation-tools/nucleo-f410rb.html
|
|
||||||
|
|
||||||
NucleoF410RB:
|
|
||||||
|
|
||||||
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F410RB
|
|
||||||
Memory: 128 KB Flash and 32 KB SRAM
|
|
||||||
ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
|
|
||||||
DAC: 1x12-bit, 2.4 MSPS A/D converter: up to 1 channels
|
|
||||||
DMA: 16-stream DMA controllers with FIFOs and burst support
|
|
||||||
Timers: Up to 11 timers: up to 5 16-bit, 1 32-bit timers, two
|
|
||||||
watchdog timers, and a SysTick timer
|
|
||||||
GPIO: Up to 81 I/O ports with interrupt capability
|
|
||||||
I2C: Up to 3 I2C interfaces
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
SPIs: Up to 4 SPIs (2 I2S)
|
|
||||||
CRC calculation unit
|
|
||||||
RTC
|
|
||||||
|
|
||||||
Peripherals: 1 led, 1 push button
|
|
||||||
Debug: Serial wire debug and JTAG interfaces
|
|
||||||
Expansion I/F Ardino and Morpho Headers
|
|
||||||
|
|
||||||
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
|
||||||
OpenOcd FTDI function - USB to JTAG front-end.
|
|
||||||
|
|
||||||
See https://os.mbed.com/platforms/ST-Nucleo-F410RB for more
|
|
||||||
information about this board.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Nucleo-64 Boards
|
|
||||||
- Button
|
|
||||||
- LED
|
|
||||||
- USARTs and Serial Consoles
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
Nucleo-64 Boards
|
|
||||||
================
|
|
||||||
|
|
||||||
The Nucleo-F410RB board is member of the Nucleo-64 board family. The
|
|
||||||
Nucleo-64 is a standard board for use with several STM32 parts in the
|
|
||||||
LQFP64 package. Variants include
|
|
||||||
|
|
||||||
Order code Targeted STM32
|
|
||||||
------------- --------------
|
|
||||||
NUCLEO-F030R8 STM32F030R8T6
|
|
||||||
NUCLEO-F070RB STM32F070RBT6
|
|
||||||
NUCLEO-F072RB STM32F072RBT6
|
|
||||||
NUCLEO-F091RC STM32F091RCT6
|
|
||||||
NUCLEO-F103RB STM32F103RBT6
|
|
||||||
NUCLEO-F302R8 STM32F302R8T6
|
|
||||||
NUCLEO-F303RE STM32F303RET6
|
|
||||||
NUCLEO-F334R8 STM32F334R8T6
|
|
||||||
NUCLEO-F401RE STM32F401RET6
|
|
||||||
NUCLEO-F410RB STM32F410RBT6
|
|
||||||
NUCLEO-F411RE STM32F411RET6
|
|
||||||
NUCLEO-F446RE STM32F446RET6
|
|
||||||
NUCLEO-L053R8 STM32L053R8T6
|
|
||||||
NUCLEO-L073RZ STM32L073RZT6
|
|
||||||
NUCLEO-L152RE STM32L152RET6
|
|
||||||
NUCLEO-L452RE STM32L452RET6
|
|
||||||
NUCLEO-L476RG STM32L476RGT6
|
|
||||||
|
|
||||||
Hardware
|
|
||||||
========
|
|
||||||
|
|
||||||
Buttons
|
|
||||||
-------
|
|
||||||
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
|
||||||
microcontroller.
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
----
|
|
||||||
The Nucleo F410RB provide a single user LED, LD2. LD2
|
|
||||||
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
|
||||||
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
|
||||||
|
|
||||||
- When the I/O is HIGH value, the LED is on.
|
|
||||||
- When the I/O is LOW, the LED is off.
|
|
||||||
|
|
||||||
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
|
||||||
defined. In that case, the usage by the board port is defined in
|
|
||||||
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
|
||||||
events as follows when the red LED (PE24) is available:
|
|
||||||
|
|
||||||
SYMBOL Meaning LD2
|
|
||||||
------------------- ----------------------- -----------
|
|
||||||
LED_STARTED NuttX has been started OFF
|
|
||||||
LED_HEAPALLOCATE Heap has been allocated OFF
|
|
||||||
LED_IRQSENABLED Interrupts enabled OFF
|
|
||||||
LED_STACKCREATED Idle stack created ON
|
|
||||||
LED_INIRQ In an interrupt No change
|
|
||||||
LED_SIGNAL In a signal handler No change
|
|
||||||
LED_ASSERTION An assertion failed No change
|
|
||||||
LED_PANIC The system has crashed Blinking
|
|
||||||
LED_IDLE MCU is is sleep mode Not used
|
|
||||||
|
|
||||||
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
|
||||||
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
|
||||||
has been detected and the system has halted.
|
|
||||||
|
|
||||||
Serial Consoles
|
|
||||||
===============
|
|
||||||
|
|
||||||
USART1
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA11 CN10 pin 14
|
|
||||||
PB7 CN7 pin 21
|
|
||||||
TXD: PA10 CN9 pin 3, CN10 pin 33
|
|
||||||
PB6 CN5 pin 3, CN10 pin 17
|
|
||||||
|
|
||||||
NOTE: You may need to edit the include/board.h to select different USART1
|
|
||||||
pin selections.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F410RB
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
To configure USART1 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART1=y
|
|
||||||
CONFIG_USART1_SERIALDRIVER=y
|
|
||||||
CONFIG_USART1_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART1_RXBUFSIZE=256
|
|
||||||
CONFIG_USART1_TXBUFSIZE=256
|
|
||||||
CONFIG_USART1_BAUD=115200
|
|
||||||
CONFIG_USART1_BITS=8
|
|
||||||
CONFIG_USART1_PARITY=0
|
|
||||||
CONFIG_USART1_2STOP=0
|
|
||||||
|
|
||||||
USART2
|
|
||||||
-----
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
|
||||||
PD6
|
|
||||||
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
|
||||||
PD5
|
|
||||||
|
|
||||||
UART2 is the default in all of these configurations.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F410RB
|
|
||||||
----------- ------------
|
|
||||||
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 2 PA2 USART2_TX some RS-232 converters
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
|
||||||
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
|
||||||
as USART signals. Thus SB13 and SB14 should be OFF.
|
|
||||||
|
|
||||||
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
disconnected to PA3 and PA2 on STM32 MCU.
|
|
||||||
|
|
||||||
To configure USART2 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART2=y
|
|
||||||
CONFIG_USART2_SERIALDRIVER=y
|
|
||||||
CONFIG_USART2_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART2_RXBUFSIZE=256
|
|
||||||
CONFIG_USART2_TXBUFSIZE=256
|
|
||||||
CONFIG_USART2_BAUD=115200
|
|
||||||
CONFIG_USART2_BITS=8
|
|
||||||
CONFIG_USART2_PARITY=0
|
|
||||||
CONFIG_USART2_2STOP=0
|
|
||||||
|
|
||||||
USART6
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PC7 CN5 pin2, CN10 pin 19
|
|
||||||
PA12 CN10, pin 12
|
|
||||||
TXD: PC6 CN10, pin 4
|
|
||||||
PA11 CN10, pin 14
|
|
||||||
|
|
||||||
To configure USART6 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART6=y
|
|
||||||
CONFIG_USART6_SERIALDRIVER=y
|
|
||||||
CONFIG_USART6_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART6_RXBUFSIZE=256
|
|
||||||
CONFIG_USART6_TXBUFSIZE=256
|
|
||||||
CONFIG_USART6_BAUD=115200
|
|
||||||
CONFIG_USART6_BITS=8
|
|
||||||
CONFIG_USART6_PARITY=0
|
|
||||||
CONFIG_USART6_2STOP=0
|
|
||||||
|
|
||||||
Virtual COM Port
|
|
||||||
----------------
|
|
||||||
Yet another option is to use UART2 and the USB virtual COM port. This
|
|
||||||
option may be more convenient for long term development, but is painful
|
|
||||||
to use during board bring-up.
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
|
||||||
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
|
||||||
connector CN10.
|
|
||||||
|
|
||||||
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
|
||||||
between them. Thus SB61, SB62 and SB63 should be OFF.
|
|
||||||
|
|
||||||
Configuring USART2 is the same as given above.
|
|
||||||
|
|
||||||
Question: What BAUD should be configure to interface with the Virtual
|
|
||||||
COM port? 115200 8N1?
|
|
||||||
|
|
||||||
Default
|
|
||||||
-------
|
|
||||||
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
|
||||||
virtual COM port is enabled.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
---------
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
|
||||||
Nucleo-F410RB board. The Configuration enables the serial interfaces
|
|
||||||
on UART2. Support for builtin applications is enabled, but in the base
|
|
||||||
configuration no builtin applications are selected (see NOTES below).
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
@ -1,253 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the ST
|
|
||||||
NucleoF410RB board from ST Micro. See
|
|
||||||
|
|
||||||
http://www.st.com/en/evaluation-tools/nucleo-f412zg.html
|
|
||||||
|
|
||||||
NucleoF412ZG:
|
|
||||||
|
|
||||||
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F412ZG
|
|
||||||
Memory: 1 MB Flash and 256 KB SRAM
|
|
||||||
ADC: 1x12-bit, 2.4 MSPS A/D converter: up to 16 channels
|
|
||||||
DMA: 2x8-stream DMA controllers with FIFOs and burst support
|
|
||||||
Timers: Up to 17 timers: up to 12 16-bit, 2 32-bit timers, two
|
|
||||||
watchdog timers, and a SysTick timer
|
|
||||||
GPIO: Up to 114 I/O ports with interrupt capability
|
|
||||||
I2C: Up to 4 I2C interfaces
|
|
||||||
USARTs: Up to 4 USARTs
|
|
||||||
SPIs: Up to 5 SPIs (5 I2S)
|
|
||||||
SDIO interface (SD/MMC/eMMC)
|
|
||||||
Advanced connectivity: USB 2.0 full-speed device/host/OTG controller with PHY
|
|
||||||
2x CAN (2.0B Active)
|
|
||||||
True random number generator
|
|
||||||
CRC calculation unit
|
|
||||||
96-bit unique ID
|
|
||||||
RTC
|
|
||||||
|
|
||||||
JAKE: TODO
|
|
||||||
|
|
||||||
See:
|
|
||||||
https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
|
|
||||||
|
|
||||||
Peripherals: 3 led, 2 push button
|
|
||||||
Debug: Serial wire debug and JTAG interfaces
|
|
||||||
Expansion I/F Ardino and Morpho Headers
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Nucleo-64 Boards
|
|
||||||
- Button
|
|
||||||
- LED
|
|
||||||
- USARTs and Serial Consoles
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
Nucleo-64 Boards
|
|
||||||
================
|
|
||||||
|
|
||||||
The Nucleo-F410RB board is member of the Nucleo-64 board family. The
|
|
||||||
Nucleo-64 is a standard board for use with several STM32 parts in the
|
|
||||||
LQFP64 package. Variants include
|
|
||||||
|
|
||||||
Order code Targeted STM32
|
|
||||||
------------- --------------
|
|
||||||
NUCLEO-F030R8 STM32F030R8T6
|
|
||||||
NUCLEO-F070RB STM32F070RBT6
|
|
||||||
NUCLEO-F072RB STM32F072RBT6
|
|
||||||
NUCLEO-F091RC STM32F091RCT6
|
|
||||||
NUCLEO-F103RB STM32F103RBT6
|
|
||||||
NUCLEO-F302R8 STM32F302R8T6
|
|
||||||
NUCLEO-F303RE STM32F303RET6
|
|
||||||
NUCLEO-F334R8 STM32F334R8T6
|
|
||||||
NUCLEO-F401RE STM32F401RET6
|
|
||||||
NUCLEO-F410RB STM32F410RBT6
|
|
||||||
NUCLEO-F411RE STM32F411RET6
|
|
||||||
NUCLEO-F446RE STM32F446RET6
|
|
||||||
NUCLEO-L053R8 STM32L053R8T6
|
|
||||||
NUCLEO-L073RZ STM32L073RZT6
|
|
||||||
NUCLEO-L152RE STM32L152RET6
|
|
||||||
NUCLEO-L452RE STM32L452RET6
|
|
||||||
NUCLEO-L476RG STM32L476RGT6
|
|
||||||
|
|
||||||
Hardware
|
|
||||||
========
|
|
||||||
|
|
||||||
Buttons
|
|
||||||
-------
|
|
||||||
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
|
||||||
microcontroller.
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
----
|
|
||||||
The Nucleo F410RB provide a single user LED, LD2. LD2
|
|
||||||
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
|
||||||
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
|
||||||
|
|
||||||
- When the I/O is HIGH value, the LED is on.
|
|
||||||
- When the I/O is LOW, the LED is off.
|
|
||||||
|
|
||||||
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
|
||||||
defined. In that case, the usage by the board port is defined in
|
|
||||||
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
|
||||||
events as follows when the red LED (PE24) is available:
|
|
||||||
|
|
||||||
SYMBOL Meaning LD2
|
|
||||||
------------------- ----------------------- -----------
|
|
||||||
LED_STARTED NuttX has been started OFF
|
|
||||||
LED_HEAPALLOCATE Heap has been allocated OFF
|
|
||||||
LED_IRQSENABLED Interrupts enabled OFF
|
|
||||||
LED_STACKCREATED Idle stack created ON
|
|
||||||
LED_INIRQ In an interrupt No change
|
|
||||||
LED_SIGNAL In a signal handler No change
|
|
||||||
LED_ASSERTION An assertion failed No change
|
|
||||||
LED_PANIC The system has crashed Blinking
|
|
||||||
LED_IDLE MCU is is sleep mode Not used
|
|
||||||
|
|
||||||
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
|
||||||
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
|
||||||
has been detected and the system has halted.
|
|
||||||
|
|
||||||
Serial Consoles
|
|
||||||
===============
|
|
||||||
|
|
||||||
USART1
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA11 CN10 pin 14
|
|
||||||
PB7 CN7 pin 21
|
|
||||||
TXD: PA10 CN9 pin 3, CN10 pin 33
|
|
||||||
PB6 CN5 pin 3, CN10 pin 17
|
|
||||||
|
|
||||||
NOTE: You may need to edit the include/board.h to select different USART1
|
|
||||||
pin selections.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F410RB
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
To configure USART1 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART1=y
|
|
||||||
CONFIG_USART1_SERIALDRIVER=y
|
|
||||||
CONFIG_USART1_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART1_RXBUFSIZE=256
|
|
||||||
CONFIG_USART1_TXBUFSIZE=256
|
|
||||||
CONFIG_USART1_BAUD=115200
|
|
||||||
CONFIG_USART1_BITS=8
|
|
||||||
CONFIG_USART1_PARITY=0
|
|
||||||
CONFIG_USART1_2STOP=0
|
|
||||||
|
|
||||||
USART2
|
|
||||||
-----
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
|
||||||
PD6
|
|
||||||
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
|
||||||
PD5
|
|
||||||
|
|
||||||
UART2 is the default in all of these configurations.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F410RB
|
|
||||||
----------- ------------
|
|
||||||
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 2 PA2 USART2_TX some RS-232 converters
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
|
||||||
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
|
||||||
as USART signals. Thus SB13 and SB14 should be OFF.
|
|
||||||
|
|
||||||
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
disconnected to PA3 and PA2 on STM32 MCU.
|
|
||||||
|
|
||||||
To configure USART2 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART2=y
|
|
||||||
CONFIG_USART2_SERIALDRIVER=y
|
|
||||||
CONFIG_USART2_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART2_RXBUFSIZE=256
|
|
||||||
CONFIG_USART2_TXBUFSIZE=256
|
|
||||||
CONFIG_USART2_BAUD=115200
|
|
||||||
CONFIG_USART2_BITS=8
|
|
||||||
CONFIG_USART2_PARITY=0
|
|
||||||
CONFIG_USART2_2STOP=0
|
|
||||||
|
|
||||||
USART6
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PC7 CN5 pin2, CN10 pin 19
|
|
||||||
PA12 CN10, pin 12
|
|
||||||
TXD: PC6 CN10, pin 4
|
|
||||||
PA11 CN10, pin 14
|
|
||||||
|
|
||||||
To configure USART6 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART6=y
|
|
||||||
CONFIG_USART6_SERIALDRIVER=y
|
|
||||||
CONFIG_USART6_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART6_RXBUFSIZE=256
|
|
||||||
CONFIG_USART6_TXBUFSIZE=256
|
|
||||||
CONFIG_USART6_BAUD=115200
|
|
||||||
CONFIG_USART6_BITS=8
|
|
||||||
CONFIG_USART6_PARITY=0
|
|
||||||
CONFIG_USART6_2STOP=0
|
|
||||||
|
|
||||||
Virtual COM Port
|
|
||||||
----------------
|
|
||||||
Yet another option is to use UART2 and the USB virtual COM port. This
|
|
||||||
option may be more convenient for long term development, but is painful
|
|
||||||
to use during board bring-up.
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
|
||||||
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
|
||||||
connector CN10.
|
|
||||||
|
|
||||||
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
|
||||||
between them. Thus SB61, SB62 and SB63 should be OFF.
|
|
||||||
|
|
||||||
Configuring USART2 is the same as given above.
|
|
||||||
|
|
||||||
Question: What BAUD should be configure to interface with the Virtual
|
|
||||||
COM port? 115200 8N1?
|
|
||||||
|
|
||||||
Default
|
|
||||||
-------
|
|
||||||
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
|
||||||
virtual COM port is enabled.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
---------
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
|
||||||
Nucleo-F410RB board. The Configuration enables the serial interfaces
|
|
||||||
on UART2. Support for builtin applications is enabled, but in the base
|
|
||||||
configuration no builtin applications are selected (see NOTES below).
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
@ -1,662 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the ST
|
|
||||||
NucleoF446RE boards from ST Micro. See
|
|
||||||
|
|
||||||
https://www.st.com/en/evaluation-tools/nucleo-f446re.html
|
|
||||||
|
|
||||||
NucleoF446RE:
|
|
||||||
|
|
||||||
Microprocessor: 32-bit ARM Cortex M4 at 180MHz STM32F446RE
|
|
||||||
Memory: 512 KB Flash and 128 KB SRAM
|
|
||||||
(todo)
|
|
||||||
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
|
||||||
DMA: 16-stream DMA controllers with FIFOs and burst support
|
|
||||||
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
|
||||||
watchdog timers, and a SysTick timer
|
|
||||||
GPIO: Up to 81 I/O ports with interrupt capability
|
|
||||||
I2C: Up to 3 × I2C interfaces
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
SPIs: Up to 4 SPIs (2 I2S)
|
|
||||||
SDIO interface
|
|
||||||
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
|
||||||
CRC calculation unit
|
|
||||||
RTC
|
|
||||||
|
|
||||||
The NucleoF446RE also has additional DMA and SPI peripheral capabilities.
|
|
||||||
|
|
||||||
Board features, however, are identical:
|
|
||||||
|
|
||||||
Peripherals: 1 led, 1 push button
|
|
||||||
Debug: Serial wire debug and JTAG interfaces
|
|
||||||
Expansion I/F Ardino and Morpho Headers
|
|
||||||
|
|
||||||
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
|
||||||
OpenOcd FTDI function - USB to JTAG front-end.
|
|
||||||
|
|
||||||
See https://os.mbed.com/platforms/ST-Nucleo-F446RE/ for more
|
|
||||||
information about this board.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Nucleo-64 Boards
|
|
||||||
- Development Environment
|
|
||||||
- GNU Toolchain Options
|
|
||||||
- IDEs
|
|
||||||
- NuttX EABI "buildroot" Toolchain
|
|
||||||
- NXFLAT Toolchain
|
|
||||||
- Hardware
|
|
||||||
- Button
|
|
||||||
- LED
|
|
||||||
- USARTs and Serial Consoles
|
|
||||||
- LQFP64
|
|
||||||
- mbed
|
|
||||||
- Shields
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
Nucleo-64 Boards
|
|
||||||
================
|
|
||||||
|
|
||||||
The Nucleo-F446RE board is a member of the Nucleo-64 board family. The
|
|
||||||
Nucleo-64 is a standard board for use with several STM32 parts in the
|
|
||||||
LQFP64 package. Variants include
|
|
||||||
|
|
||||||
Order code Targeted STM32
|
|
||||||
------------- --------------
|
|
||||||
NUCLEO-F030R8 STM32F030R8T6
|
|
||||||
NUCLEO-F070RB STM32F070RBT6
|
|
||||||
NUCLEO-F072RB STM32F072RBT6
|
|
||||||
NUCLEO-F091RC STM32F091RCT6
|
|
||||||
NUCLEO-F103RB STM32F103RBT6
|
|
||||||
NUCLEO-F302R8 STM32F302R8T6
|
|
||||||
NUCLEO-F303RE STM32F303RET6
|
|
||||||
NUCLEO-F334R8 STM32F334R8T6
|
|
||||||
NUCLEO-F401RE STM32F401RET6
|
|
||||||
NUCLEO-F410RB STM32F410RBT6
|
|
||||||
NUCLEO-F411RE STM32F411RET6
|
|
||||||
NUCLEO-F446RE STM32F446RET6
|
|
||||||
NUCLEO-L053R8 STM32L053R8T6
|
|
||||||
NUCLEO-L073RZ STM32L073RZT6
|
|
||||||
NUCLEO-L152RE STM32L152RET6
|
|
||||||
NUCLEO-L452RE STM32L452RET6
|
|
||||||
NUCLEO-L476RG STM32L476RGT6
|
|
||||||
|
|
||||||
Development Environment
|
|
||||||
=======================
|
|
||||||
|
|
||||||
Either Linux or Cygwin on Windows can be used for the development environment.
|
|
||||||
The source has been built only using the GNU toolchain (see below). Other
|
|
||||||
toolchains will likely cause problems.
|
|
||||||
|
|
||||||
GNU Toolchain Options
|
|
||||||
=====================
|
|
||||||
|
|
||||||
Toolchain Configurations
|
|
||||||
------------------------
|
|
||||||
The NuttX make system has been modified to support the following different
|
|
||||||
toolchain options.
|
|
||||||
|
|
||||||
1. The NuttX buildroot Toolchain (see below), or
|
|
||||||
2. Any generic arm-none-eabi GNU toolchain.
|
|
||||||
|
|
||||||
All testing has been conducted using the NuttX Codesourcery toolchain. To use
|
|
||||||
a different toolchain, you simply need to modify the configuration. As an
|
|
||||||
example:
|
|
||||||
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
|
|
||||||
|
|
||||||
IDEs
|
|
||||||
====
|
|
||||||
|
|
||||||
NuttX is built using command-line make. It can be used with an IDE, but some
|
|
||||||
effort will be required to create the project.
|
|
||||||
|
|
||||||
Makefile Build
|
|
||||||
--------------
|
|
||||||
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
|
|
||||||
simply use the NuttX makefile to build the system. That is almost for free
|
|
||||||
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
|
|
||||||
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
|
|
||||||
there is a lot of help on the internet).
|
|
||||||
|
|
||||||
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
|
|
||||||
Download and install the latest version (as of this writing it was
|
|
||||||
sourceryg++-2013.05-64-arm-none-eabi)
|
|
||||||
|
|
||||||
Import the project from git.
|
|
||||||
File->import->Git-URI, then import a Exiting code as a Makefile progject
|
|
||||||
from the working directory the git clone was done to.
|
|
||||||
|
|
||||||
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
|
|
||||||
build, before the make will work in CodeBench.
|
|
||||||
|
|
||||||
Native Build
|
|
||||||
------------
|
|
||||||
Here are a few tips before you start that effort:
|
|
||||||
|
|
||||||
1) Select the toolchain that you will be using in your .config file
|
|
||||||
2) Start the NuttX build at least one time from the Cygwin command line
|
|
||||||
before trying to create your project. This is necessary to create
|
|
||||||
certain auto-generated files and directories that will be needed.
|
|
||||||
3) Set up include paths: You will need include/, arch/arm/src/stm32,
|
|
||||||
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
|
|
||||||
4) All assembly files need to have the definition option -D __ASSEMBLY__
|
|
||||||
on the command line.
|
|
||||||
|
|
||||||
Startup files will probably cause you some headaches. The NuttX startup file
|
|
||||||
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
|
|
||||||
one time from the Cygwin command line in order to obtain the pre-built
|
|
||||||
startup object needed by RIDE.
|
|
||||||
|
|
||||||
NuttX EABI "buildroot" Toolchain
|
|
||||||
================================
|
|
||||||
|
|
||||||
A GNU GCC-based toolchain is assumed. The PATH environment variable should
|
|
||||||
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
|
|
||||||
different from the default in your PATH variable).
|
|
||||||
|
|
||||||
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
|
|
||||||
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
|
|
||||||
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
|
||||||
|
|
||||||
1. You must have already configured NuttX in <some-dir>/nuttx.
|
|
||||||
|
|
||||||
$ tools/configure.sh nucleo-f446re:nsh
|
|
||||||
$ make qconfig
|
|
||||||
$ V=1 make context all 2>&1 | tee mout
|
|
||||||
|
|
||||||
2. Download the latest buildroot package into <some-dir>
|
|
||||||
|
|
||||||
3. unpack the buildroot tarball. The resulting directory may
|
|
||||||
have versioning information on it like buildroot-x.y.z. If so,
|
|
||||||
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
|
|
||||||
|
|
||||||
4. cd <some-dir>/buildroot
|
|
||||||
|
|
||||||
5. cp boards/cortexm3-eabi-defconfig-4.6.3 .config
|
|
||||||
|
|
||||||
6. make oldconfig
|
|
||||||
|
|
||||||
7. make
|
|
||||||
|
|
||||||
8. Make sure that the PATH variable includes the path to the newly built
|
|
||||||
binaries.
|
|
||||||
|
|
||||||
See the file boards/README.txt in the buildroot source tree. That has more
|
|
||||||
details PLUS some special instructions that you will need to follow if you are
|
|
||||||
building a Cortex-M3 toolchain for Cygwin under Windows.
|
|
||||||
|
|
||||||
NOTE: Unfortunately, the 4.6.3 EABI toolchain is not compatible with the
|
|
||||||
the NXFLAT tools. See the top-level TODO file (under "Binary loaders") for
|
|
||||||
more information about this problem. If you plan to use NXFLAT, please do not
|
|
||||||
use the GCC 4.6.3 EABI toolchain; instead use the GCC 4.3.3 EABI toolchain.
|
|
||||||
|
|
||||||
NXFLAT Toolchain
|
|
||||||
================
|
|
||||||
|
|
||||||
If you are *not* using the NuttX buildroot toolchain and you want to use
|
|
||||||
the NXFLAT tools, then you will still have to build a portion of the buildroot
|
|
||||||
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
|
|
||||||
be downloaded from the NuttX Bitbucket download site
|
|
||||||
(https://bitbucket.org/nuttx/nuttx/downloads/).
|
|
||||||
|
|
||||||
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
|
||||||
|
|
||||||
1. You must have already configured NuttX in <some-dir>/nuttx.
|
|
||||||
|
|
||||||
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
|
|
||||||
|
|
||||||
2. Download the latest buildroot package into <some-dir>
|
|
||||||
|
|
||||||
3. unpack the buildroot tarball. The resulting directory may
|
|
||||||
have versioning information on it like buildroot-x.y.z. If so,
|
|
||||||
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
|
|
||||||
|
|
||||||
4. cd <some-dir>/buildroot
|
|
||||||
|
|
||||||
5. cp boards/cortexm3-defconfig-nxflat .config
|
|
||||||
|
|
||||||
6. make oldconfig
|
|
||||||
|
|
||||||
7. make
|
|
||||||
|
|
||||||
8. Make sure that the PATH variable includes the path to the newly built
|
|
||||||
NXFLAT binaries.
|
|
||||||
|
|
||||||
mbed
|
|
||||||
====
|
|
||||||
|
|
||||||
The Nucleo-F401RE includes boot loader from mbed:
|
|
||||||
|
|
||||||
https://mbed.org/platforms/ST-Nucleo-F401RE/
|
|
||||||
https://mbed.org/handbook/Homepage
|
|
||||||
|
|
||||||
Using the mbed loader:
|
|
||||||
|
|
||||||
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
|
|
||||||
2. A new file system will appear called NUCLEO; open it with Windows
|
|
||||||
Explorer (assuming that you are using Windows).
|
|
||||||
3. Drag and drop nuttx.bin into the MBED window. This will load the
|
|
||||||
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
|
|
||||||
close then re-open and the Nucleo-F4x1RE will be running the new code.
|
|
||||||
|
|
||||||
Hardware
|
|
||||||
========
|
|
||||||
|
|
||||||
GPIO
|
|
||||||
----
|
|
||||||
SERIAL_TX=PA_2 USER_BUTTON=PC_13
|
|
||||||
SERIAL_RX=PA_3 LED1 =PA_5
|
|
||||||
|
|
||||||
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
|
|
||||||
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
|
|
||||||
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
|
|
||||||
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
|
|
||||||
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
|
|
||||||
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
|
|
||||||
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
|
|
||||||
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
|
|
||||||
|
|
||||||
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
|
|
||||||
|
|
||||||
Buttons
|
|
||||||
-------
|
|
||||||
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
|
||||||
microcontroller.
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
----
|
|
||||||
The Nucleo F446RE provides a single user LED, LD2. LD2
|
|
||||||
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
|
||||||
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
|
||||||
|
|
||||||
- When the I/O is HIGH value, the LED is on.
|
|
||||||
- When the I/O is LOW, the LED is off.
|
|
||||||
|
|
||||||
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
|
||||||
defined. In that case, the usage by the board port is defined in
|
|
||||||
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
|
||||||
events as follows when the red LED (PE24) is available:
|
|
||||||
|
|
||||||
SYMBOL Meaning LD2
|
|
||||||
------------------- ----------------------- -----------
|
|
||||||
LED_STARTED NuttX has been started OFF
|
|
||||||
LED_HEAPALLOCATE Heap has been allocated OFF
|
|
||||||
LED_IRQSENABLED Interrupts enabled OFF
|
|
||||||
LED_STACKCREATED Idle stack created ON
|
|
||||||
LED_INIRQ In an interrupt No change
|
|
||||||
LED_SIGNAL In a signal handler No change
|
|
||||||
LED_ASSERTION An assertion failed No change
|
|
||||||
LED_PANIC The system has crashed Blinking
|
|
||||||
LED_IDLE MCU is is sleep mode Not used
|
|
||||||
|
|
||||||
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
|
||||||
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
|
||||||
has been detected and the system has halted.
|
|
||||||
|
|
||||||
Serial Consoles
|
|
||||||
===============
|
|
||||||
|
|
||||||
USART1
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA11 CN10 pin 14
|
|
||||||
PB7 CN7 pin 21
|
|
||||||
TXD: PA10 CN9 pin 3, CN10 pin 33
|
|
||||||
PB6 CN5 pin 3, CN10 pin 17
|
|
||||||
|
|
||||||
NOTE: You may need to edit the include/board.h to select different USART1
|
|
||||||
pin selections.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F4x1RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
To configure USART1 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART1=y
|
|
||||||
CONFIG_USART1_SERIALDRIVER=y
|
|
||||||
CONFIG_USART1_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART1_RXBUFSIZE=256
|
|
||||||
CONFIG_USART1_TXBUFSIZE=256
|
|
||||||
CONFIG_USART1_BAUD=115200
|
|
||||||
CONFIG_USART1_BITS=8
|
|
||||||
CONFIG_USART1_PARITY=0
|
|
||||||
CONFIG_USART1_2STOP=0
|
|
||||||
|
|
||||||
USART2
|
|
||||||
-----
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
|
||||||
PD6
|
|
||||||
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
|
||||||
PD5
|
|
||||||
|
|
||||||
UART2 is the default in all of these configurations.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F4x1RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 2 PA2 USART2_TX some RS-232 converters
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
|
||||||
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
|
||||||
as USART signals. Thus SB13 and SB14 should be OFF.
|
|
||||||
|
|
||||||
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
disconnected to PA3 and PA2 on STM32 MCU.
|
|
||||||
|
|
||||||
To configure USART2 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART2=y
|
|
||||||
CONFIG_USART2_SERIALDRIVER=y
|
|
||||||
CONFIG_USART2_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART2_RXBUFSIZE=256
|
|
||||||
CONFIG_USART2_TXBUFSIZE=256
|
|
||||||
CONFIG_USART2_BAUD=115200
|
|
||||||
CONFIG_USART2_BITS=8
|
|
||||||
CONFIG_USART2_PARITY=0
|
|
||||||
CONFIG_USART2_2STOP=0
|
|
||||||
|
|
||||||
USART6
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PC7 CN5 pin2, CN10 pin 19
|
|
||||||
PA12 CN10, pin 12
|
|
||||||
TXD: PC6 CN10, pin 4
|
|
||||||
PA11 CN10, pin 14
|
|
||||||
|
|
||||||
To configure USART6 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART6=y
|
|
||||||
CONFIG_USART6_SERIALDRIVER=y
|
|
||||||
CONFIG_USART6_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART6_RXBUFSIZE=256
|
|
||||||
CONFIG_USART6_TXBUFSIZE=256
|
|
||||||
CONFIG_USART6_BAUD=115200
|
|
||||||
CONFIG_USART6_BITS=8
|
|
||||||
CONFIG_USART6_PARITY=0
|
|
||||||
CONFIG_USART6_2STOP=0
|
|
||||||
|
|
||||||
Virtual COM Port
|
|
||||||
----------------
|
|
||||||
Yet another option is to use UART2 and the USB virtual COM port. This
|
|
||||||
option may be more convenient for long term development, but is painful
|
|
||||||
to use during board bring-up.
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
|
||||||
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
|
||||||
connector CN10.
|
|
||||||
|
|
||||||
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
|
||||||
between them. Thus SB61, SB62 and SB63 should be OFF.
|
|
||||||
|
|
||||||
Configuring USART2 is the same as given above.
|
|
||||||
|
|
||||||
Question: What BAUD should be configure to interface with the Virtual
|
|
||||||
COM port? 115200 8N1?
|
|
||||||
|
|
||||||
Default
|
|
||||||
-------
|
|
||||||
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
|
||||||
virtual COM port is enabled.
|
|
||||||
|
|
||||||
Shields
|
|
||||||
=======
|
|
||||||
|
|
||||||
RS-232 from Cutedigi.com
|
|
||||||
------------------------
|
|
||||||
Supports a single RS-232 connected via
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F4x1RE Cutedigi
|
|
||||||
----------- ------------ --------
|
|
||||||
Pin 1 PA3 USART2_RX RXD
|
|
||||||
Pin 2 PA2 USART2_TX TXD
|
|
||||||
|
|
||||||
Support for this shield is enabled by selecting USART2 and configuring
|
|
||||||
SB13, 14, 62, and 63 as described above under "Serial Consoles"
|
|
||||||
|
|
||||||
Itead Joystick Shield
|
|
||||||
---------------------
|
|
||||||
See http://imall.iteadstudio.com/im120417014.html for more information
|
|
||||||
about this joystick.
|
|
||||||
|
|
||||||
Itead Joystick Connection:
|
|
||||||
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
ARDUINO ITEAD NUCLEO-F4x1
|
|
||||||
PIN NAME SIGNAL SIGNAL
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
D3 Button E Output PB3
|
|
||||||
D4 Button D Output PB5
|
|
||||||
D5 Button C Output PB4
|
|
||||||
D6 Button B Output PB10
|
|
||||||
D7 Button A Output PA8
|
|
||||||
D8 Button F Output PA9
|
|
||||||
D9 Button G Output PC7
|
|
||||||
A0 Joystick Y Output PA0 ADC1_0
|
|
||||||
A1 Joystick X Output PA1 ADC1_1
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
|
|
||||||
All buttons are pulled on the shield. A sensed low value indicates
|
|
||||||
when the button is pressed.
|
|
||||||
|
|
||||||
NOTE: Button F cannot be used with the default USART1 configuration
|
|
||||||
because PA9 is configured for USART1_RX by default. Use select
|
|
||||||
different USART1 pins in the board.h file or select a different
|
|
||||||
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
|
|
||||||
eliminate all but buttons A, B, and C.
|
|
||||||
|
|
||||||
Itead Joystick Signal interpretation:
|
|
||||||
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
BUTTON TYPE NUTTX ALIAS
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
Button A Large button A JUMP/BUTTON 3
|
|
||||||
Button B Large button B FIRE/BUTTON 2
|
|
||||||
Button C Joystick select button SELECT/BUTTON 1
|
|
||||||
Button D Tiny Button D BUTTON 6
|
|
||||||
Button E Tiny Button E BUTTON 7
|
|
||||||
Button F Large Button F BUTTON 4
|
|
||||||
Button G Large Button G BUTTON 5
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
|
|
||||||
Itead Joystick configuration settings:
|
|
||||||
|
|
||||||
System Type -> STM32 Peripheral Support
|
|
||||||
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
|
|
||||||
|
|
||||||
Drivers
|
|
||||||
CONFIG_ANALOG=y : Should be automatically selected
|
|
||||||
CONFIG_ADC=y : Should be automatically selected
|
|
||||||
CONFIG_INPUT=y : Select input device support
|
|
||||||
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
|
|
||||||
|
|
||||||
There is nothing in the configuration that currently uses the joystick.
|
|
||||||
For testing, you can add the following configuration options to enable the
|
|
||||||
analog joystick example at apps/examples/ajoystick:
|
|
||||||
|
|
||||||
CONFIG_NSH_ARCHINIT=y
|
|
||||||
CONFIG_EXAMPLES_AJOYSTICK=y
|
|
||||||
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
2014-12-04:
|
|
||||||
- Without ADC DMA support, it is not possible to sample both X and Y
|
|
||||||
with a single ADC. Right now, only one axis is being converted.
|
|
||||||
- There is conflicts with some of the Arduino data pins and the
|
|
||||||
default USART1 configuration. I am currently running with USART1
|
|
||||||
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
|
|
||||||
conflict.
|
|
||||||
- Current showstopper: I appear to be getting infinite interrupts as
|
|
||||||
soon as joystick button interrupts are enabled.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
----
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
|
||||||
Nucleo-F446RE board. The Configuration enables the serial interfaces
|
|
||||||
on UART2. Support for builtin applications is enabled, but in the base
|
|
||||||
configuration no builtin applications are selected (see NOTES below).
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
|
|
||||||
2. By default, this configuration uses the ARM EABI toolchain
|
|
||||||
for Linux. That can easily be reconfigured, of course.
|
|
||||||
|
|
||||||
CONFIG_HOST_LINUX=y : Builds under Linux
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
|
|
||||||
|
|
||||||
3. Although the default console is USART2 (which would correspond to
|
|
||||||
the Virtual COM port) I have done all testing with the console
|
|
||||||
device configured for USART1 (see instruction above under "Serial
|
|
||||||
Consoles). I have been using a TTL-to-RS-232 converter connected
|
|
||||||
as shown below:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F446RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
can:
|
|
||||||
----
|
|
||||||
This is basically an nsh configuration (see above) with added support
|
|
||||||
for CAN driver. Both CAN 1 (RX: PB_8, TX: PB_9) and CAN 2 (RX: PB_5, TX: PB_6)
|
|
||||||
are turn on.
|
|
||||||
|
|
||||||
Functionality of CAN driver can be tested by calling application
|
|
||||||
"can" in NuttShell. This application sends 100 messages over CAN 1.
|
|
||||||
|
|
||||||
dac:
|
|
||||||
----
|
|
||||||
This is an nsh configuration (see above) with added support
|
|
||||||
for digital analog converter driver.
|
|
||||||
|
|
||||||
Functionality of DAC driver can be tested by calling application
|
|
||||||
"dac" in NuttShell. GPIO_DAC1_OUT1 pin is set on PA_4.
|
|
||||||
|
|
||||||
gpio:
|
|
||||||
-----
|
|
||||||
This is an nsh configuration (see above) with added support for GPIO
|
|
||||||
driver and GPIO test application "gpio". Three pins are configured for
|
|
||||||
testing purposes:
|
|
||||||
|
|
||||||
PA_7 - GPIO_INPUT
|
|
||||||
PB_6 - GPIO_OUTPUT
|
|
||||||
PC_7 - GPIO_INPUT_INTERRUPT
|
|
||||||
|
|
||||||
ihm08m1_f32 and ihm08m1_b16:
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
These examples are dedicated for the X-NUCLEO-IHM08M1 expansion board with
|
|
||||||
L6398 gate drivers and discrete transistors.
|
|
||||||
|
|
||||||
WARNING: L6398 gate drivers require channel 2 negative polarisation and
|
|
||||||
negative sign for the deadtime. Make sure that your gate drivers logic
|
|
||||||
is compatible with this configuration.
|
|
||||||
|
|
||||||
X-NUCLEO-IHM08M1 must be configured to work with FOC and 3-shunt
|
|
||||||
resistors. See ST documentation for details.
|
|
||||||
|
|
||||||
Pin configuration for the X-NUCLEO-IHM08M1 (TIM1 configuration):
|
|
||||||
|
|
||||||
Board Function Chip Function Chip Pin Number
|
|
||||||
------------- ---------------- -----------------
|
|
||||||
Phase U high TIM1_CH1 PA8
|
|
||||||
Phase U low TIM1_CH1N PA7
|
|
||||||
Phase V high TIM1_CH2 PA9
|
|
||||||
Phase V low TIM1_CH2N PB0
|
|
||||||
Phase W high TIM1_CH3 PA10
|
|
||||||
Phase W low TIM1_CH3N PB1
|
|
||||||
Current U ADC1_IN0 PA0
|
|
||||||
Current V ADC1_IN11 PC1
|
|
||||||
Current W ADC1_IN10 PC0
|
|
||||||
Temperature ADC1_IN12 PC2
|
|
||||||
VBUS ADC1_IN1 PA1
|
|
||||||
BEMF1 (NU) PC3
|
|
||||||
BEMF2 (NU) PC4
|
|
||||||
BEMF3 (NU) PC5
|
|
||||||
LED GPIO_PB2 PB2
|
|
||||||
+3V3 (CN7_16)
|
|
||||||
GND (CN7_20)
|
|
||||||
GPIO_BEMF (NU) PC9
|
|
||||||
ENCO_A/HALL_H1 TIM2_CH1 PA15
|
|
||||||
ENCO_B/HALL_H2 TIM2_CH2 PB3
|
|
||||||
ENCO_Z/HALL_H3 TIM2_CH3 PB10
|
|
||||||
DAC (NU) PA5
|
|
||||||
GPIO3 (NU) PB13
|
|
||||||
CPOUT (NU) PA12
|
|
||||||
BKIN1 (NU) PA6
|
|
||||||
BKIN2 (NU) PA11
|
|
||||||
BKIN3 (NU) PB14
|
|
||||||
POT/DAC DAC1_CH1/ADC1_IN4 PA4
|
|
||||||
CURR_REF (NU) PB4
|
|
||||||
DEBUG0 GPIO PB12
|
|
||||||
DEBUG1 GPIO PB9
|
|
||||||
DEBUG2 GPIO PC6
|
|
||||||
DEBUG3 GPIO PB5
|
|
||||||
DEBUG4 GPIO PC8
|
|
||||||
|
|
||||||
Current shunt resistance = 0.01
|
|
||||||
Current sense gain = -5.18 (inverted current)
|
|
||||||
Vbus sense gain = 9.31k/(9.31k+169k) = 0.0522
|
|
||||||
Vbus min = 10V
|
|
||||||
Vbus max = 48V
|
|
||||||
Iout max = 15A RMS
|
|
||||||
|
|
||||||
IPHASE_RATIO = 1/(R_shunt*gain) = -19.3
|
|
||||||
VBUS_RATIO = 1/VBUS_gain = 19.152
|
|
||||||
|
|
||||||
For now only 3-shunt resistors configuration is supported.
|
|
||||||
|
|
||||||
lcd:
|
|
||||||
----
|
|
||||||
This is basically an nsh configuration (see above) with added support
|
|
||||||
of ILI9225 176x220 TFT display and test framebuffer application.
|
|
||||||
|
|
||||||
Display connection is set to SPI 3 and pinout is following:
|
|
||||||
|
|
||||||
CS D8
|
|
||||||
RST D6
|
|
||||||
RS D7
|
|
||||||
SDA D4
|
|
||||||
CLK D3
|
|
||||||
|
|
||||||
Framebuffer application can be started from terminal by typing "fb".
|
|
||||||
|
|
||||||
pwm:
|
|
||||||
----
|
|
||||||
This is an nsh configuration (see above) with added capability of pulse width
|
|
||||||
modulation. PWM output is on Timer 3 channel 1, which is pin PA_6 (D12) on
|
|
||||||
Nucleo board. Example program can be stared by "pwm" command.
|
|
||||||
@ -1,580 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
This README discusses issues unique to NuttX configurations for the ST
|
|
||||||
NucleoF401RE and NucleoF411RE boards from ST Micro. See
|
|
||||||
|
|
||||||
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1810/PF258797
|
|
||||||
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049
|
|
||||||
|
|
||||||
These two boards are very similar, both supporting STM32 "Dynamic Efficiency
|
|
||||||
Line" parts but differing in the specific STM32 chip mounted on board. The
|
|
||||||
chips themselves are also very similar with the STM32F411RE having some
|
|
||||||
additional capability:
|
|
||||||
|
|
||||||
NucleoF401RE:
|
|
||||||
|
|
||||||
Microprocessor: 32-bit ARM Cortex M4 at 84MHz STM32F104RE
|
|
||||||
Memory: 512 KB Flash and 96 KB SRAM
|
|
||||||
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
|
||||||
DMA: 16-stream DMA controllers with FIFOs and burst support
|
|
||||||
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
|
||||||
watchdog timers, and a SysTick timer
|
|
||||||
GPIO: Up to 81 I/O ports with interrupt capability
|
|
||||||
I2C: Up to 3 × I2C interfaces
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
SPIs: Up to 4 SPIs (2 I2S)
|
|
||||||
SDIO interface
|
|
||||||
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
|
||||||
CRC calculation unit
|
|
||||||
RTC
|
|
||||||
|
|
||||||
NucleoF411RE:
|
|
||||||
|
|
||||||
Microprocessor: 32-bit ARM Cortex M4 at 100MHz STM32F411RE
|
|
||||||
Memory: 512 KB Flash and 128 KB SRAM
|
|
||||||
ADC: 1×12-bit, 2.4 MSPS A/D converter: up to 10 channels
|
|
||||||
DMA: 16-stream DMA controllers with FIFOs and burst support
|
|
||||||
Timers: Up to 11 timers: up to six 16-bit, two 32-bit timers, two
|
|
||||||
watchdog timers, and a SysTick timer
|
|
||||||
GPIO: Up to 81 I/O ports with interrupt capability
|
|
||||||
I2C: Up to 3 × I2C interfaces
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
USARTs: Up to 3 USARTs
|
|
||||||
SPIs: Up to 4 SPIs (2 I2S)
|
|
||||||
SDIO interface
|
|
||||||
USB: USB 2.0 full-speed device/host/OTG controller with on-chip PHY
|
|
||||||
CRC calculation unit
|
|
||||||
RTC
|
|
||||||
|
|
||||||
The NucleoF411RE also has additional DMA and SPI peripheral capabilities.
|
|
||||||
|
|
||||||
Board features, however, are identical:
|
|
||||||
|
|
||||||
Peripherals: 1 led, 1 push button
|
|
||||||
Debug: Serial wire debug and JTAG interfaces
|
|
||||||
Expansion I/F Ardino and Morpho Headers
|
|
||||||
|
|
||||||
Uses a STM32F103 to provide a ST-Link for programming, debug similar to the
|
|
||||||
OpenOcd FTDI function - USB to JTAG front-end.
|
|
||||||
|
|
||||||
See http://mbed.org/platforms/ST-Nucleo-F401RE and
|
|
||||||
http://developer.mbed.org/platforms/ST-Nucleo-F411RE for more
|
|
||||||
information about these boards.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Nucleo-64 Boards
|
|
||||||
- Development Environment
|
|
||||||
- GNU Toolchain Options
|
|
||||||
- IDEs
|
|
||||||
- NuttX EABI "buildroot" Toolchain
|
|
||||||
- NXFLAT Toolchain
|
|
||||||
- Hardware
|
|
||||||
- Button
|
|
||||||
- LED
|
|
||||||
- USARTs and Serial Consoles
|
|
||||||
- LQFP64
|
|
||||||
- mbed
|
|
||||||
- Shields
|
|
||||||
- Configurations
|
|
||||||
|
|
||||||
Nucleo-64 Boards
|
|
||||||
================
|
|
||||||
|
|
||||||
The Nucleo-F4x1RE boards are members of the Nucleo-64 board family. The
|
|
||||||
Nucleo-64 is a standard board for use with several STM32 parts in the
|
|
||||||
LQFP64 package. Variants include
|
|
||||||
|
|
||||||
Order code Targeted STM32
|
|
||||||
------------- --------------
|
|
||||||
NUCLEO-F030R8 STM32F030R8T6
|
|
||||||
NUCLEO-F070RB STM32F070RBT6
|
|
||||||
NUCLEO-F072RB STM32F072RBT6
|
|
||||||
NUCLEO-F091RC STM32F091RCT6
|
|
||||||
NUCLEO-F103RB STM32F103RBT6
|
|
||||||
NUCLEO-F302R8 STM32F302R8T6
|
|
||||||
NUCLEO-F303RE STM32F303RET6
|
|
||||||
NUCLEO-F334R8 STM32F334R8T6
|
|
||||||
NUCLEO-F401RE STM32F401RET6
|
|
||||||
NUCLEO-F410RB STM32F410RBT6
|
|
||||||
NUCLEO-F411RE STM32F411RET6
|
|
||||||
NUCLEO-F446RE STM32F446RET6
|
|
||||||
NUCLEO-L053R8 STM32L053R8T6
|
|
||||||
NUCLEO-L073RZ STM32L073RZT6
|
|
||||||
NUCLEO-L152RE STM32L152RET6
|
|
||||||
NUCLEO-L452RE STM32L452RET6
|
|
||||||
NUCLEO-L476RG STM32L476RGT6
|
|
||||||
|
|
||||||
Development Environment
|
|
||||||
=======================
|
|
||||||
|
|
||||||
Either Linux or Cygwin on Windows can be used for the development environment.
|
|
||||||
The source has been built only using the GNU toolchain (see below). Other
|
|
||||||
toolchains will likely cause problems.
|
|
||||||
|
|
||||||
GNU Toolchain Options
|
|
||||||
=====================
|
|
||||||
|
|
||||||
Toolchain Configurations
|
|
||||||
------------------------
|
|
||||||
The NuttX make system has been modified to support the following different
|
|
||||||
toolchain options.
|
|
||||||
|
|
||||||
1. The NuttX buildroot Toolchain (see below), or
|
|
||||||
2. Any generic arm-none-eabi GNU toolchain.
|
|
||||||
|
|
||||||
All testing has been conducted using the NuttX Codesourcery toolchain. To use
|
|
||||||
a different toolchain, you simply need to modify the configuration. As an
|
|
||||||
example:
|
|
||||||
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI : Generic arm-none-eabi toolchain
|
|
||||||
|
|
||||||
IDEs
|
|
||||||
====
|
|
||||||
|
|
||||||
NuttX is built using command-line make. It can be used with an IDE, but some
|
|
||||||
effort will be required to create the project.
|
|
||||||
|
|
||||||
Makefile Build
|
|
||||||
--------------
|
|
||||||
Under Eclipse, it is pretty easy to set up an "empty makefile project" and
|
|
||||||
simply use the NuttX makefile to build the system. That is almost for free
|
|
||||||
under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty
|
|
||||||
makefile project in order to work with Windows (Google for "Eclipse Cygwin" -
|
|
||||||
there is a lot of help on the internet).
|
|
||||||
|
|
||||||
Using Sourcery CodeBench from http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/overview
|
|
||||||
Download and install the latest version (as of this writing it was
|
|
||||||
sourceryg++-2013.05-64-arm-none-eabi)
|
|
||||||
|
|
||||||
Import the project from git.
|
|
||||||
File->import->Git-URI, then import a Exiting code as a Makefile progject
|
|
||||||
from the working directory the git clone was done to.
|
|
||||||
|
|
||||||
Select the Sourcery CodeBench for ARM EABI. N.B. You must do one command line
|
|
||||||
build, before the make will work in CodeBench.
|
|
||||||
|
|
||||||
Native Build
|
|
||||||
------------
|
|
||||||
Here are a few tips before you start that effort:
|
|
||||||
|
|
||||||
1) Select the toolchain that you will be using in your .config file
|
|
||||||
2) Start the NuttX build at least one time from the Cygwin command line
|
|
||||||
before trying to create your project. This is necessary to create
|
|
||||||
certain auto-generated files and directories that will be needed.
|
|
||||||
3) Set up include paths: You will need include/, arch/arm/src/stm32,
|
|
||||||
arch/arm/src/common, arch/arm/src/armv7-m, and sched/.
|
|
||||||
4) All assembly files need to have the definition option -D __ASSEMBLY__
|
|
||||||
on the command line.
|
|
||||||
|
|
||||||
Startup files will probably cause you some headaches. The NuttX startup file
|
|
||||||
is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX
|
|
||||||
one time from the Cygwin command line in order to obtain the pre-built
|
|
||||||
startup object needed by RIDE.
|
|
||||||
|
|
||||||
NuttX EABI "buildroot" Toolchain
|
|
||||||
================================
|
|
||||||
|
|
||||||
A GNU GCC-based toolchain is assumed. The PATH environment variable should
|
|
||||||
be modified to point to the correct path to the Cortex-M3 GCC toolchain (if
|
|
||||||
different from the default in your PATH variable).
|
|
||||||
|
|
||||||
If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX
|
|
||||||
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
|
|
||||||
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
|
||||||
|
|
||||||
1. You must have already configured NuttX in <some-dir>/nuttx.
|
|
||||||
|
|
||||||
$ tools/configure.sh nucleo-f4x1re:f401-nsh
|
|
||||||
$ make qconfig
|
|
||||||
$ V=1 make context all 2>&1 | tee mout
|
|
||||||
|
|
||||||
Use the f411-nsh configuration if you have the Nucleo-F411RE board.
|
|
||||||
|
|
||||||
2. Download the latest buildroot package into <some-dir>
|
|
||||||
|
|
||||||
3. unpack the buildroot tarball. The resulting directory may
|
|
||||||
have versioning information on it like buildroot-x.y.z. If so,
|
|
||||||
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
|
|
||||||
|
|
||||||
4. cd <some-dir>/buildroot
|
|
||||||
|
|
||||||
5. cp boards/cortexm3-eabi-defconfig-4.6.3 .config
|
|
||||||
|
|
||||||
6. make oldconfig
|
|
||||||
|
|
||||||
7. make
|
|
||||||
|
|
||||||
8. Make sure that the PATH variable includes the path to the newly built
|
|
||||||
binaries.
|
|
||||||
|
|
||||||
See the file boards/README.txt in the buildroot source tree. That has more
|
|
||||||
details PLUS some special instructions that you will need to follow if you are
|
|
||||||
building a Cortex-M3 toolchain for Cygwin under Windows.
|
|
||||||
|
|
||||||
NOTE: Unfortunately, the 4.6.3 EABI toolchain is not compatible with the
|
|
||||||
the NXFLAT tools. See the top-level TODO file (under "Binary loaders") for
|
|
||||||
more information about this problem. If you plan to use NXFLAT, please do not
|
|
||||||
use the GCC 4.6.3 EABI toolchain; instead use the GCC 4.3.3 EABI toolchain.
|
|
||||||
|
|
||||||
NXFLAT Toolchain
|
|
||||||
================
|
|
||||||
|
|
||||||
If you are *not* using the NuttX buildroot toolchain and you want to use
|
|
||||||
the NXFLAT tools, then you will still have to build a portion of the buildroot
|
|
||||||
tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can
|
|
||||||
be downloaded from the NuttX Bitbucket download site
|
|
||||||
(https://bitbucket.org/nuttx/nuttx/downloads/).
|
|
||||||
|
|
||||||
This GNU toolchain builds and executes in the Linux or Cygwin environment.
|
|
||||||
|
|
||||||
1. You must have already configured NuttX in <some-dir>/nuttx.
|
|
||||||
|
|
||||||
tools/configure.sh lpcxpresso-lpc1768:<sub-dir>
|
|
||||||
|
|
||||||
2. Download the latest buildroot package into <some-dir>
|
|
||||||
|
|
||||||
3. unpack the buildroot tarball. The resulting directory may
|
|
||||||
have versioning information on it like buildroot-x.y.z. If so,
|
|
||||||
rename <some-dir>/buildroot-x.y.z to <some-dir>/buildroot.
|
|
||||||
|
|
||||||
4. cd <some-dir>/buildroot
|
|
||||||
|
|
||||||
5. cp boards/cortexm3-defconfig-nxflat .config
|
|
||||||
|
|
||||||
6. make oldconfig
|
|
||||||
|
|
||||||
7. make
|
|
||||||
|
|
||||||
8. Make sure that the PATH variable includes the path to the newly built
|
|
||||||
NXFLAT binaries.
|
|
||||||
|
|
||||||
mbed
|
|
||||||
====
|
|
||||||
|
|
||||||
The Nucleo-F401RE includes boot loader from mbed:
|
|
||||||
|
|
||||||
https://mbed.org/platforms/ST-Nucleo-F401RE/
|
|
||||||
https://mbed.org/handbook/Homepage
|
|
||||||
|
|
||||||
Using the mbed loader:
|
|
||||||
|
|
||||||
1. Connect the Nucleo-F4x1RE to the host PC using the USB connector.
|
|
||||||
2. A new file system will appear called NUCLEO; open it with Windows
|
|
||||||
Explorer (assuming that you are using Windows).
|
|
||||||
3. Drag and drop nuttx.bin into the MBED window. This will load the
|
|
||||||
nuttx.bin binary into the Nucleo-F4x1RE. The NUCLEO window will
|
|
||||||
close then re-open and the Nucleo-F4x1RE will be running the new code.
|
|
||||||
|
|
||||||
Hardware
|
|
||||||
========
|
|
||||||
|
|
||||||
GPIO
|
|
||||||
----
|
|
||||||
SERIAL_TX=PA_2 USER_BUTTON=PC_13
|
|
||||||
SERIAL_RX=PA_3 LED1 =PA_5
|
|
||||||
|
|
||||||
A0=PA_0 USART2RX D0=PA_3 D8 =PA_9
|
|
||||||
A1=PA_1 USART2TX D1=PA_2 D9 =PC_7
|
|
||||||
A2=PA_4 D2=PA_10 WIFI_CS=D10=PB_6 SPI_CS
|
|
||||||
A3=PB_0 WIFI_INT=D3=PB_3 D11=PA_7 SPI_MOSI
|
|
||||||
A4=PC_1 SDCS=D4=PB_5 D12=PA_6 SPI_MISO
|
|
||||||
A5=PC_0 WIFI_EN=D5=PB_4 LED1=D13=PA_5 SPI_SCK
|
|
||||||
LED2=D6=PB_10 I2C1_SDA=D14=PB_9 Probe
|
|
||||||
D7=PA_8 I2C1_SCL=D15=PB_8 Probe
|
|
||||||
|
|
||||||
From: https://mbed.org/platforms/ST-Nucleo-F401RE/
|
|
||||||
|
|
||||||
Buttons
|
|
||||||
-------
|
|
||||||
B1 USER: the user button is connected to the I/O PC13 (pin 2) of the STM32
|
|
||||||
microcontroller.
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
----
|
|
||||||
The Nucleo F401RE and Nucleo F411RE provide a single user LED, LD2. LD2
|
|
||||||
is the green LED connected to Arduino signal D13 corresponding to MCU I/O
|
|
||||||
PA5 (pin 21) or PB13 (pin 34) depending on the STM32target.
|
|
||||||
|
|
||||||
- When the I/O is HIGH value, the LED is on.
|
|
||||||
- When the I/O is LOW, the LED is off.
|
|
||||||
|
|
||||||
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
|
|
||||||
defined. In that case, the usage by the board port is defined in
|
|
||||||
include/board.h and src/sam_leds.c. The LEDs are used to encode OS-related
|
|
||||||
events as follows when the red LED (PE24) is available:
|
|
||||||
|
|
||||||
SYMBOL Meaning LD2
|
|
||||||
------------------- ----------------------- -----------
|
|
||||||
LED_STARTED NuttX has been started OFF
|
|
||||||
LED_HEAPALLOCATE Heap has been allocated OFF
|
|
||||||
LED_IRQSENABLED Interrupts enabled OFF
|
|
||||||
LED_STACKCREATED Idle stack created ON
|
|
||||||
LED_INIRQ In an interrupt No change
|
|
||||||
LED_SIGNAL In a signal handler No change
|
|
||||||
LED_ASSERTION An assertion failed No change
|
|
||||||
LED_PANIC The system has crashed Blinking
|
|
||||||
LED_IDLE MCU is is sleep mode Not used
|
|
||||||
|
|
||||||
Thus if LD2, NuttX has successfully booted and is, apparently, running
|
|
||||||
normally. If LD2 is flashing at approximately 2Hz, then a fatal error
|
|
||||||
has been detected and the system has halted.
|
|
||||||
|
|
||||||
Serial Consoles
|
|
||||||
===============
|
|
||||||
|
|
||||||
USART1
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA11 CN10 pin 14
|
|
||||||
PB7 CN7 pin 21
|
|
||||||
TXD: PA10 CN9 pin 3, CN10 pin 33
|
|
||||||
PB6 CN5 pin 3, CN10 pin 17
|
|
||||||
|
|
||||||
NOTE: You may need to edit the include/board.h to select different USART1
|
|
||||||
pin selections.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F4x1RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
To configure USART1 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART1=y
|
|
||||||
CONFIG_USART1_SERIALDRIVER=y
|
|
||||||
CONFIG_USART1_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART1_RXBUFSIZE=256
|
|
||||||
CONFIG_USART1_TXBUFSIZE=256
|
|
||||||
CONFIG_USART1_BAUD=115200
|
|
||||||
CONFIG_USART1_BITS=8
|
|
||||||
CONFIG_USART1_PARITY=0
|
|
||||||
CONFIG_USART1_2STOP=0
|
|
||||||
|
|
||||||
USART2
|
|
||||||
-----
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PA3 CN9 pin 1 (See SB13, 14, 62, 63). CN10 pin 37
|
|
||||||
PD6
|
|
||||||
TXD: PA2 CN9 pin 2(See SB13, 14, 62, 63). CN10 pin 35
|
|
||||||
PD5
|
|
||||||
|
|
||||||
UART2 is the default in all of these configurations.
|
|
||||||
|
|
||||||
TTL to RS-232 converter connection:
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F4x1RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 1 PA3 USART2_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 2 PA2 USART2_TX some RS-232 converters
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Closed: PA2 and PA3 on STM32 MCU are connected to D1 and D0
|
|
||||||
(pin 7 and pin 8) on Arduino connector CN9 and ST Morpho connector CN10
|
|
||||||
as USART signals. Thus SB13 and SB14 should be OFF.
|
|
||||||
|
|
||||||
- SB13 and SB14 Open: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
disconnected to PA3 and PA2 on STM32 MCU.
|
|
||||||
|
|
||||||
To configure USART2 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART2=y
|
|
||||||
CONFIG_USART2_SERIALDRIVER=y
|
|
||||||
CONFIG_USART2_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART2_RXBUFSIZE=256
|
|
||||||
CONFIG_USART2_TXBUFSIZE=256
|
|
||||||
CONFIG_USART2_BAUD=115200
|
|
||||||
CONFIG_USART2_BITS=8
|
|
||||||
CONFIG_USART2_PARITY=0
|
|
||||||
CONFIG_USART2_2STOP=0
|
|
||||||
|
|
||||||
USART6
|
|
||||||
------
|
|
||||||
Pins and Connectors:
|
|
||||||
|
|
||||||
RXD: PC7 CN5 pin2, CN10 pin 19
|
|
||||||
PA12 CN10, pin 12
|
|
||||||
TXD: PC6 CN10, pin 4
|
|
||||||
PA11 CN10, pin 14
|
|
||||||
|
|
||||||
To configure USART6 as the console:
|
|
||||||
|
|
||||||
CONFIG_STM32_USART6=y
|
|
||||||
CONFIG_USART6_SERIALDRIVER=y
|
|
||||||
CONFIG_USART6_SERIAL_CONSOLE=y
|
|
||||||
CONFIG_USART6_RXBUFSIZE=256
|
|
||||||
CONFIG_USART6_TXBUFSIZE=256
|
|
||||||
CONFIG_USART6_BAUD=115200
|
|
||||||
CONFIG_USART6_BITS=8
|
|
||||||
CONFIG_USART6_PARITY=0
|
|
||||||
CONFIG_USART6_2STOP=0
|
|
||||||
|
|
||||||
Virtual COM Port
|
|
||||||
----------------
|
|
||||||
Yet another option is to use UART2 and the USB virtual COM port. This
|
|
||||||
option may be more convenient for long term development, but is painful
|
|
||||||
to use during board bring-up.
|
|
||||||
|
|
||||||
Solder Bridges. This configuration requires:
|
|
||||||
|
|
||||||
- SB62 and SB63 Open: PA2 and PA3 on STM32 MCU are disconnected to D1
|
|
||||||
and D0 (pin 7 and pin 8) on Arduino connector CN9 and ST Morpho
|
|
||||||
connector CN10.
|
|
||||||
|
|
||||||
- SB13 and SB14 Closed: PA2 and PA3 on STM32F103C8T6 (ST-LINK MCU) are
|
|
||||||
connected to PA3 and PA2 on STM32 MCU to have USART communication
|
|
||||||
between them. Thus SB61, SB62 and SB63 should be OFF.
|
|
||||||
|
|
||||||
Configuring USART2 is the same as given above.
|
|
||||||
|
|
||||||
Question: What BAUD should be configure to interface with the Virtual
|
|
||||||
COM port? 115200 8N1?
|
|
||||||
|
|
||||||
Default
|
|
||||||
-------
|
|
||||||
As shipped, SB62 and SB63 are open and SB13 and SB14 closed, so the
|
|
||||||
virtual COM port is enabled.
|
|
||||||
|
|
||||||
Shields
|
|
||||||
=======
|
|
||||||
|
|
||||||
RS-232 from Cutedigi.com
|
|
||||||
------------------------
|
|
||||||
Supports a single RS-232 connected via
|
|
||||||
|
|
||||||
Nucleo CN9 STM32F4x1RE Cutedigi
|
|
||||||
----------- ------------ --------
|
|
||||||
Pin 1 PA3 USART2_RX RXD
|
|
||||||
Pin 2 PA2 USART2_TX TXD
|
|
||||||
|
|
||||||
Support for this shield is enabled by selecting USART2 and configuring
|
|
||||||
SB13, 14, 62, and 63 as described above under "Serial Consoles"
|
|
||||||
|
|
||||||
Itead Joystick Shield
|
|
||||||
---------------------
|
|
||||||
See http://imall.iteadstudio.com/im120417014.html for more information
|
|
||||||
about this joystick.
|
|
||||||
|
|
||||||
Itead Joystick Connection:
|
|
||||||
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
ARDUINO ITEAD NUCLEO-F4x1
|
|
||||||
PIN NAME SIGNAL SIGNAL
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
D3 Button E Output PB3
|
|
||||||
D4 Button D Output PB5
|
|
||||||
D5 Button C Output PB4
|
|
||||||
D6 Button B Output PB10
|
|
||||||
D7 Button A Output PA8
|
|
||||||
D8 Button F Output PA9
|
|
||||||
D9 Button G Output PC7
|
|
||||||
A0 Joystick Y Output PA0 ADC1_0
|
|
||||||
A1 Joystick X Output PA1 ADC1_1
|
|
||||||
--------- ----------------- ---------------------------------
|
|
||||||
|
|
||||||
All buttons are pulled on the shield. A sensed low value indicates
|
|
||||||
when the button is pressed.
|
|
||||||
|
|
||||||
NOTE: Button F cannot be used with the default USART1 configuration
|
|
||||||
because PA9 is configured for USART1_RX by default. Use select
|
|
||||||
different USART1 pins in the board.h file or select a different
|
|
||||||
USART or select CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS which will
|
|
||||||
eliminate all but buttons A, B, and C.
|
|
||||||
|
|
||||||
Itead Joystick Signal interpretation:
|
|
||||||
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
BUTTON TYPE NUTTX ALIAS
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
Button A Large button A JUMP/BUTTON 3
|
|
||||||
Button B Large button B FIRE/BUTTON 2
|
|
||||||
Button C Joystick select button SELECT/BUTTON 1
|
|
||||||
Button D Tiny Button D BUTTON 6
|
|
||||||
Button E Tiny Button E BUTTON 7
|
|
||||||
Button F Large Button F BUTTON 4
|
|
||||||
Button G Large Button G BUTTON 5
|
|
||||||
--------- ----------------------- ---------------------------
|
|
||||||
|
|
||||||
Itead Joystick configuration settings:
|
|
||||||
|
|
||||||
System Type -> STM32 Peripheral Support
|
|
||||||
CONFIG_STM32_ADC1=y : Enable ADC1 driver support
|
|
||||||
|
|
||||||
Drivers
|
|
||||||
CONFIG_ANALOG=y : Should be automatically selected
|
|
||||||
CONFIG_ADC=y : Should be automatically selected
|
|
||||||
CONFIG_INPUT=y : Select input device support
|
|
||||||
CONFIG_INPUT_AJOYSTICK=y : Select analog joystick support
|
|
||||||
|
|
||||||
There is nothing in the configuration that currently uses the joystick.
|
|
||||||
For testing, you can add the following configuration options to enable the
|
|
||||||
analog joystick example at apps/examples/ajoystick:
|
|
||||||
|
|
||||||
CONFIG_NSH_ARCHINIT=y
|
|
||||||
CONFIG_EXAMPLES_AJOYSTICK=y
|
|
||||||
CONFIG_EXAMPLES_AJOYSTICK_DEVNAME="/dev/ajoy0"
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
2014-12-04:
|
|
||||||
- Without ADC DMA support, it is not possible to sample both X and Y
|
|
||||||
with a single ADC. Right now, only one axis is being converted.
|
|
||||||
- There is conflicts with some of the Arduino data pins and the
|
|
||||||
default USART1 configuration. I am currently running with USART1
|
|
||||||
but with CONFIG_NUCLEO_F401RE_AJOY_MINBUTTONS to eliminate the
|
|
||||||
conflict.
|
|
||||||
- Current showstopper: I appear to be getting infinite interrupts as
|
|
||||||
soon as joystick button interrupts are enabled.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
f401-nsh:
|
|
||||||
---------
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh for the
|
|
||||||
Nucleo-F401RE board. The Configuration enables the serial interfaces
|
|
||||||
on UART2. Support for builtin applications is enabled, but in the base
|
|
||||||
configuration no builtin applications are selected (see NOTES below).
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configuration using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
|
|
||||||
2. By default, this configuration uses the ARM EABI toolchain
|
|
||||||
for Linux. That can easily be reconfigured, of course.
|
|
||||||
|
|
||||||
CONFIG_HOST_LINUX=y : Builds under Linux
|
|
||||||
CONFIG_ARM_TOOLCHAIN_GNU_EABI=y : GNU EABI toolchain for Linux
|
|
||||||
|
|
||||||
3. Although the default console is USART2 (which would correspond to
|
|
||||||
the Virtual COM port) I have done all testing with the console
|
|
||||||
device configured for USART1 (see instruction above under "Serial
|
|
||||||
Consoles). I have been using a TTL-to-RS-232 converter connected
|
|
||||||
as shown below:
|
|
||||||
|
|
||||||
Nucleo CN10 STM32F4x1RE
|
|
||||||
----------- ------------
|
|
||||||
Pin 21 PA9 USART1_RX *Warning you make need to reverse RX/TX on
|
|
||||||
Pin 33 PA10 USART1_TX some RS-232 converters
|
|
||||||
Pin 20 GND
|
|
||||||
Pin 8 U5V
|
|
||||||
|
|
||||||
f411-nsh
|
|
||||||
--------
|
|
||||||
This configuration is the same as the f401-nsh configuration, except
|
|
||||||
that it is configured to support the Nucleo-F411RE.
|
|
||||||
@ -1,196 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
The Olimex STM32-E407 configuration is based on the configuration
|
|
||||||
olimex-stm32-h407 and stm32f4discovery.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
Instantiating Configurations
|
|
||||||
----------------------------
|
|
||||||
Each Olimex-STM32-E407 configuration is maintained in a sub-directory and
|
|
||||||
can be selected as follow:
|
|
||||||
|
|
||||||
tools/configure.sh [OPTIONS] olimex-stm32-e407:<subdir>
|
|
||||||
|
|
||||||
Typical options include -l for a Linux host platform or -c for Cygwin
|
|
||||||
host platform. See 'tools/configure.sh -h' for other options. And
|
|
||||||
<subdir> is one of the sub-directories listed below.
|
|
||||||
|
|
||||||
Compile Firmware
|
|
||||||
----------------
|
|
||||||
Once you've set the proper configuration, you just need to execute the next
|
|
||||||
command:
|
|
||||||
|
|
||||||
make
|
|
||||||
|
|
||||||
If everything goes find, it should return the next two files:
|
|
||||||
|
|
||||||
nuttx.hex
|
|
||||||
nuttx.bin
|
|
||||||
|
|
||||||
You can return more kinds of files by setting on menuconfig.
|
|
||||||
|
|
||||||
Flashing the Board
|
|
||||||
-----------------
|
|
||||||
You can flash this board in different ways, but the easiest way is using
|
|
||||||
ARM-USB-TINY-H JTAG flasher device.
|
|
||||||
Connect this device to the JTAG connector and type the next command:
|
|
||||||
|
|
||||||
openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
|
|
||||||
|
|
||||||
Configuration Directories
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
---
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
|
||||||
configuration enables a console on UART2. Support for
|
|
||||||
builtin applications is enabled, but in the base configuration no
|
|
||||||
builtin applications are selected.
|
|
||||||
|
|
||||||
usbnsh:
|
|
||||||
------
|
|
||||||
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
|
||||||
configuration enables a console on USB_OTG1. Support for
|
|
||||||
builtin applications is enabled, but in the base configuration no
|
|
||||||
builtin applications are selected.
|
|
||||||
|
|
||||||
netnsh:
|
|
||||||
------
|
|
||||||
Configures the NuttShell (nsh) located at examples/nsh. This
|
|
||||||
configuration is focused on network testing.
|
|
||||||
|
|
||||||
bmp180:
|
|
||||||
------
|
|
||||||
This is a configuration example for the BMP180 barometer sensor. This
|
|
||||||
sensor works with I2C, you need to do the next connections:
|
|
||||||
|
|
||||||
BMP180 VIN -> Board 3.3V
|
|
||||||
BMP180 GND -> Board GND
|
|
||||||
BMP180 SCL -> Board PB6 (Arduino header D1)
|
|
||||||
BMP180 SDA -> Board PB7 (Arduino header D0)
|
|
||||||
|
|
||||||
This example is configured to work with the USBNSH instead of UART NSH, so
|
|
||||||
the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
On the console, type "ls /dev " and if the registration process goes fine,
|
|
||||||
you should see a device called "press0". Now execute the app
|
|
||||||
BMP180 to see the ambient pressure value.
|
|
||||||
|
|
||||||
dac:
|
|
||||||
---
|
|
||||||
This is a configuration example to use the DAC1 of the board. The DAC1
|
|
||||||
is attached to the PA4 pin (Arduino header D10).
|
|
||||||
|
|
||||||
This example is configured to work with the USBNSH instead of UART NSH, so
|
|
||||||
the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
On the console, type "ls /dev " and if the registration process goes fine,
|
|
||||||
you should see a device called "dac0". Now execute the app
|
|
||||||
dac put a value at the output.
|
|
||||||
|
|
||||||
ina219:
|
|
||||||
------
|
|
||||||
This is a configuration example for the INA219 DC current sensor. This
|
|
||||||
sensor works with I2C, you need to do the next connections:
|
|
||||||
|
|
||||||
INA219 VIN -> Board 3.3V
|
|
||||||
INA219 GND -> Board GND
|
|
||||||
INA219 SCL -> Board PB6 (Arduino header D1)
|
|
||||||
INA219 SDA -> Board PB7 (Arduino header D0)
|
|
||||||
|
|
||||||
This example is configured to work with the USBNSH instead of UART NSH, so
|
|
||||||
the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
On the console, type "ls /dev " and if the registration process goes fine,
|
|
||||||
you should see a device called "ina219". Now execute the app
|
|
||||||
ina219 to see the ambient pressure value.
|
|
||||||
|
|
||||||
timer:
|
|
||||||
-----
|
|
||||||
This configuration set the proper configuration to use the timer1 of the
|
|
||||||
board. This example is configured to work with the USBNSH instead of
|
|
||||||
UART NSH, so the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
On the console, type "ls /dev " and if the registration process goes fine,
|
|
||||||
you should see a device called "timer1".
|
|
||||||
|
|
||||||
mrf24j40-mac:
|
|
||||||
------------
|
|
||||||
This configuration set the proper configuration to set the 802.15.4
|
|
||||||
communication layer with the MRF24J40 radio. This radio works with
|
|
||||||
SPI, you need to do the next connections:
|
|
||||||
|
|
||||||
MRF24J40 VCC -> Board 3.3V
|
|
||||||
MRF24J40 GND -> Board GND
|
|
||||||
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
|
|
||||||
MRF24J40 MISO -> Board PA6 (Arduino header D12)
|
|
||||||
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
|
|
||||||
MRF24J40 CS -> Board PA4 (Arduino header D10)
|
|
||||||
MRF24J40 INT -> Board PG12 (Arduino header D8)
|
|
||||||
|
|
||||||
This example is configured to work with the USBNSH instead of UART NSH,
|
|
||||||
so the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
Once you're on the console, you need to check if the initialization
|
|
||||||
process was fine. To do so, you need to type "ls /dev" and you should
|
|
||||||
see a device call "ieee0". At this point we need to set-up the network,
|
|
||||||
follow the next steps:
|
|
||||||
|
|
||||||
This is an example of how to configure a coordinator:
|
|
||||||
i8sak /dev/ieee0 startpan cd:ab
|
|
||||||
i8sak set chan 11
|
|
||||||
i8sak set saddr 42:01
|
|
||||||
i8sak acceptassoc
|
|
||||||
|
|
||||||
This is an example of how to configure the endpoint:
|
|
||||||
i8sak /dev/ieee0
|
|
||||||
i8sak set chan 11
|
|
||||||
i8sak set panid cd:ab
|
|
||||||
i8sak set saddr 42:02
|
|
||||||
i8sak set ep_saddr 42:01
|
|
||||||
i8sak assoc
|
|
||||||
|
|
||||||
mrf24j40-6lowpan:
|
|
||||||
----------------
|
|
||||||
This configuration set the proper configuration to use 6lowpan protocol with the MRF24J40
|
|
||||||
radio. This radio works with SPI, you need to do the next connections:
|
|
||||||
|
|
||||||
MRF24J40 VCC -> Board 3.3V
|
|
||||||
MRF24J40 GND -> Board GND
|
|
||||||
MRF24J40 SCLK -> Board PA5 (Arduino header D13)
|
|
||||||
MRF24J40 MISO -> Board PA6 (Arduino header D12)
|
|
||||||
MRF24J40 MOSI -> Board PB5 (Arduino header D11)
|
|
||||||
MRF24J40 CS -> Board PA4 (Arduino header D10)
|
|
||||||
MRF24J40 INT -> Board PG12 (Arduino header D8)
|
|
||||||
|
|
||||||
This example is configured to work with the USBNSH instead of UART NSH, so
|
|
||||||
the console will be shown over the USB_OTG1 connector.
|
|
||||||
|
|
||||||
Once you're on the console, you need to check if the initialization process
|
|
||||||
was fine. To do so, you need to type "ls /dev" and you should see a device
|
|
||||||
call "ieee0". At this point we need to set-up the network, follow the next steps:
|
|
||||||
|
|
||||||
This is an example of how to configure a coordinator:
|
|
||||||
i8sak wpan0 startpan cd:ab
|
|
||||||
i8sak set chan 11
|
|
||||||
i8sak set saddr 42:01
|
|
||||||
i8sak acceptassoc
|
|
||||||
|
|
||||||
When the association was complete, you need to bring-up the network:
|
|
||||||
ifup wpan0
|
|
||||||
|
|
||||||
This is an example of how to configure the endpoint:
|
|
||||||
i8sak wpan0
|
|
||||||
i8sak set chan 11
|
|
||||||
i8sak set panid cd:ab
|
|
||||||
i8sak set saddr 42:02
|
|
||||||
i8sak set ep_saddr 42:01
|
|
||||||
i8sak assoc
|
|
||||||
|
|
||||||
When the association was complete, you need to bring-up the network:
|
|
||||||
ifup wpan0
|
|
||||||
|
|
||||||
If you execute the command "ifconfig", you will be able to see the info of the WPAN0 interface
|
|
||||||
and see the assigned IP. This interface can be use with an UDP or TCP server/client application.
|
|
||||||
@ -1,655 +0,0 @@
|
|||||||
README
|
|
||||||
======
|
|
||||||
|
|
||||||
The NuttX configuration for the Olimex STM32-P407 is derives more or less
|
|
||||||
directly from the Olimex STM32-P207 board support. The P207 and P407 seem
|
|
||||||
to share the same board design. Other code comes from the STM3240G board
|
|
||||||
support (which has the same crystal and clocking) and from the STM32 F4
|
|
||||||
Discovery (which has the same STM32 part)
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
o Board Support
|
|
||||||
o microSD Card Interface
|
|
||||||
o OTGFS Host
|
|
||||||
o Protect Mode Build
|
|
||||||
o Configurations
|
|
||||||
|
|
||||||
Board Support
|
|
||||||
=============
|
|
||||||
|
|
||||||
The following peripherals are available in this configuration.
|
|
||||||
|
|
||||||
- LEDs: Show the system status
|
|
||||||
|
|
||||||
- Buttons: TAMPER-button, WKUP-button, J1-Joystick (consists of RIGHT-,
|
|
||||||
UP-, LEFT-, DOWN-, and CENTER-button).
|
|
||||||
|
|
||||||
- ADC: ADC1 samples the red trim potentiometer AN_TR
|
|
||||||
Built in app 'adc' works.
|
|
||||||
|
|
||||||
- USB-FS-OTG: There is a USB-A-connector (host) connected to the full
|
|
||||||
speed STM32 OTG inputs.
|
|
||||||
|
|
||||||
- USB-HS-OTG: The other connector (device) is connected to the high speed
|
|
||||||
STM32 OTG inputs.
|
|
||||||
|
|
||||||
- CAN: Built in app 'can' works, but apart from that not really
|
|
||||||
tested.
|
|
||||||
|
|
||||||
- Ethernet: Ping to other station on the network works.
|
|
||||||
|
|
||||||
- microSD: Not fully functional. See below.
|
|
||||||
|
|
||||||
- LCD: Nokia 6610. This is similar the Nokia 6100 LCD used on other
|
|
||||||
Olimex boards. There is a driver for that LCD at
|
|
||||||
Obsoleted/nuttx/drivers/lcd/nokia6100.c, however, it was removed
|
|
||||||
because it was not properly integrated. It uses a 9-bit SPI
|
|
||||||
interface which is difficult to get working properly.
|
|
||||||
|
|
||||||
- External Support is included for the onboard SRAM. It uses SRAM
|
|
||||||
SRAM: settings from another board that might need to be tweaked.
|
|
||||||
Difficult to test because the SRAM conflicts with both
|
|
||||||
RS232 ports.
|
|
||||||
|
|
||||||
- Other: Buzzer, Camera, Temperature sensor, audio have not been
|
|
||||||
tested.
|
|
||||||
|
|
||||||
If so, then it requires a 9-bit
|
|
||||||
|
|
||||||
microSD Card Interface
|
|
||||||
======================
|
|
||||||
|
|
||||||
microSD Connector
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
----------------- ----------------- ------------------------
|
|
||||||
SD/MMC CONNECTOR BOARD GPIO CONFIGURATION(s
|
|
||||||
PIN SIGNAL SIGNAL (no remapping)
|
|
||||||
--- ------------- ----------------- -------------------------
|
|
||||||
1 DAT2/RES SD_D2/USART3_TX/ PC10 GPIO_SDIO_D2
|
|
||||||
SPI3_SCK
|
|
||||||
2 CD/DAT3/CS SD_D3/USART3_RX/ PC11 GPIO_SDIO_D3
|
|
||||||
SPI3_MISO
|
|
||||||
3 CMD/DI SD_CMD PD2 GPIO_SDIO_CMD
|
|
||||||
4 VDD N/A N/A
|
|
||||||
5 CLK/SCLK SD_CLK/SPI3_MOSI PC12 GPIO_SDIO_CK
|
|
||||||
6 VSS N/A N/A
|
|
||||||
7 DAT0/D0 SD_D0/DCMI_D2 PC8 GPIO_SDIO_D0
|
|
||||||
8 DAT1/RES SD_D1/DCMI_D3 PC9 GPIO_SDIO_D1
|
|
||||||
--- ------------- ----------------- -------------------------
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
1. DAT4, DAT4, DAT6, and DAT7 not connected.
|
|
||||||
2. There are no alternative pin selections.
|
|
||||||
3. There is no card detect (CD) GPIO input so we will not
|
|
||||||
sense if there is a card in the SD slot or not. This will
|
|
||||||
make usage very awkward.
|
|
||||||
|
|
||||||
Configuration
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Enabling SDIO-based MMC/SD support:
|
|
||||||
|
|
||||||
System Type->STM32 Peripheral Support
|
|
||||||
CONFIG_STM32_SDIO=y : Enable SDIO support
|
|
||||||
CONFIG_STM32_DMA2=y : DMA2 is needed by the driver
|
|
||||||
|
|
||||||
Device Drivers -> MMC/SD Driver Support
|
|
||||||
CONFIG_MMCSD=y : Enable MMC/SD support
|
|
||||||
CONFIG_MMSCD_NSLOTS=1 : One slot per driver instance
|
|
||||||
# CONFIG_MMCSD_HAVE_CARDDETECT is not set : No card-detect GPIO
|
|
||||||
# CONFIG_MMCSD_MMCSUPPORT is not set : Interferes with some SD cards
|
|
||||||
# CONFIG_MMCSD_SPI is not set : No SPI-based MMC/SD support
|
|
||||||
CONFIG_MMCSD_SDIO=y : SDIO-based MMC/SD support
|
|
||||||
CONFIG_MMCSD_MULTIBLOCK_LIMIT=1 : Disable to keep things simple
|
|
||||||
CONFIG_SDIO_DMA=y : Use SDIO DMA
|
|
||||||
# CONFIG_SDIO_BLOCKSETUP is not set : (not implemented)
|
|
||||||
|
|
||||||
Library Routines
|
|
||||||
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
|
|
||||||
|
|
||||||
Application Configuration -> NSH Library
|
|
||||||
CONFIG_NSH_ARCHINIT=y : NSH board-initialization
|
|
||||||
|
|
||||||
Using the SD card
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
1. Since there is no CD GPIO pin, the firmware sill not know if there is
|
|
||||||
a card in the SD slot or not. It will assume that there is and attempt
|
|
||||||
to mount the SD card on power-up. If there is no SD card in the card
|
|
||||||
slot, there will be a long delay during initialization as the firmware
|
|
||||||
attempts to query the non-existent card, timeout, and retry.
|
|
||||||
|
|
||||||
2. After booting, an SDIO device will appear as /dev/mmcsd0
|
|
||||||
|
|
||||||
3. If you try mounting an SD card with nothing in the slot, the
|
|
||||||
mount will fail:
|
|
||||||
|
|
||||||
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
|
|
||||||
nsh: mount: mount failed: 19
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
-------
|
|
||||||
2017-01-28: There is no card communication. All commands to the SD card timeout.
|
|
||||||
|
|
||||||
OTGFS Host
|
|
||||||
==========
|
|
||||||
STM32 USB OTG FS Host Board Support
|
|
||||||
-----------------------------------
|
|
||||||
A USB-A-connector (host) is connected to the full speed STM32 inputs. These
|
|
||||||
are the pins supported by the STM32:
|
|
||||||
|
|
||||||
PIN SIGNAL DIRECTION
|
|
||||||
---- ----------- ----------
|
|
||||||
PA8 OTG_FS_SOF SOF clock output
|
|
||||||
PA9 OTG_FS_VBUS VBUS input for device, Driven by external regulator by
|
|
||||||
host (not an alternate function)
|
|
||||||
PA10 OTG_FS_ID OTG ID pin (only needed in Dual mode)
|
|
||||||
PA11 OTG_FS_DM D- I/O
|
|
||||||
PA12 OTG_FS_DP D+ I/O
|
|
||||||
|
|
||||||
These are the signals available on-board:
|
|
||||||
|
|
||||||
OTG_FS_VBUS Used host VBUS sensing (device input only)
|
|
||||||
OTG_FS_DM Data minus
|
|
||||||
OTG_FS_DP Dta plus
|
|
||||||
|
|
||||||
NOTE: PA10 is currently used for DCMI_D1. The USB OTGFS host will
|
|
||||||
configure this as the ID input.
|
|
||||||
|
|
||||||
VBUS power is provided via an LM3526 and driven by USB_FS_VBUSON:
|
|
||||||
|
|
||||||
USB_FS_VBUSON PC2 power on output to LM3526 #ENA
|
|
||||||
USB_FS_FAULT PB10 overcurrent input from LM3526 FLAG_A.
|
|
||||||
|
|
||||||
STM32 USB OTG FS Host Driver Configuration
|
|
||||||
------------------------------------------
|
|
||||||
Pre-requisites
|
|
||||||
|
|
||||||
CONFIG_USBDEV - Enable USB device support
|
|
||||||
CONFIG_USBHOST - Enable USB host support
|
|
||||||
CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block
|
|
||||||
CONFIG_STM32_SYSCFG - Needed
|
|
||||||
CONFIG_SCHED_WORKQUEUE - Worker thread support is required
|
|
||||||
|
|
||||||
STM32 Options:
|
|
||||||
|
|
||||||
CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words.
|
|
||||||
Default 128 (512 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO
|
|
||||||
in 32-bit words. Default 96 (384 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit
|
|
||||||
words. Default 96 (384 bytes)
|
|
||||||
CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128
|
|
||||||
CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever
|
|
||||||
want to do that?
|
|
||||||
CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access
|
|
||||||
debug. Depends on CONFIG_DEBUG_FEATURES.
|
|
||||||
CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB
|
|
||||||
packets. Depends on CONFIG_DEBUG_FEATURES.
|
|
||||||
|
|
||||||
Olimex STM32 P407 Configuration:
|
|
||||||
|
|
||||||
CONFIG_STM32F_OLIMEXP407_PRIO - Priority of the USB host watier
|
|
||||||
thread (default 100).
|
|
||||||
CONFIG_STM32_OLIMEXP407_STACKSIZE - Stacksize of the USB host
|
|
||||||
waiter thread (default 1024)
|
|
||||||
|
|
||||||
Class Driver Configuration
|
|
||||||
--------------------------
|
|
||||||
Individual class drivers have additional configuration requirements. The
|
|
||||||
USB mass storage class, for example, requires FAT file system support.
|
|
||||||
|
|
||||||
CONFIG_USBHOST_MSC=y
|
|
||||||
|
|
||||||
CONFIG_FS_FAT=y
|
|
||||||
CONFIG_FAT_LCNAMES=y
|
|
||||||
CONFIG_FAT_LFN=y
|
|
||||||
CONFIG_FAT_MAXFNAME=32
|
|
||||||
|
|
||||||
This will enable USB HID keyboard support:
|
|
||||||
|
|
||||||
CONFIG_USBHOST_HIDKBD=y
|
|
||||||
CONFIG_HIDKBD_BUFSIZE=64
|
|
||||||
CONFIG_HIDKBD_DEFPRIO=50
|
|
||||||
CONFIG_HIDKBD_POLLUSEC=100000
|
|
||||||
CONFIG_HIDKBD_STACKSIZE=1024
|
|
||||||
|
|
||||||
And this will enable the USB keyboard example:
|
|
||||||
|
|
||||||
CONFIG_EXAMPLES_HIDKBD=y
|
|
||||||
CONFIG_EXAMPLES_HIDKBD_DEFPRIO=50
|
|
||||||
CONFIG_EXAMPLES_HIDKBD_DEVNAME="/dev/kbda"
|
|
||||||
CONFIG_EXAMPLES_HIDKBD_STACKSIZE=1024
|
|
||||||
|
|
||||||
STATUS: The MSC configurations seems fully functional. The HIDKBD seems rather
|
|
||||||
flaky. Sometimes the LEDs become very bright (indicating that it is being
|
|
||||||
swamped with interrupts). Data input is not clean with apps/examples/hidkbd:
|
|
||||||
There are missing characters and sometimes duplicated characters. This implies
|
|
||||||
some logic issues, probably in drivers/usbhost/usbhost_hidkbd.c, with polling
|
|
||||||
and data filtering.
|
|
||||||
|
|
||||||
Protected Mode Build
|
|
||||||
====================
|
|
||||||
|
|
||||||
The "protected" mode build uses the Cormtex-M4 MPU to separate the FLASH and
|
|
||||||
SRAM into kernel-mode and user-mode regions. The kernel mode regions are
|
|
||||||
then protected from any errant or mischievous behavior from user-space
|
|
||||||
applications.
|
|
||||||
|
|
||||||
Common notes for all protected mode builds follow:
|
|
||||||
|
|
||||||
1. It is recommends to use a special make command; not just 'make' but make
|
|
||||||
with the following two arguments:
|
|
||||||
|
|
||||||
make pass1 pass2
|
|
||||||
|
|
||||||
In the normal case (just 'make'), make will attempt to build both user-
|
|
||||||
and kernel-mode blobs more or less interleaved. That actual works!
|
|
||||||
However, for me it is very confusing so I prefer the above make command:
|
|
||||||
Make the user-space binaries first (pass1), then make the kernel-space
|
|
||||||
binaries (pass2)
|
|
||||||
|
|
||||||
2. At the end of the build, there will be several files in the top-level
|
|
||||||
NuttX build directory:
|
|
||||||
|
|
||||||
PASS1:
|
|
||||||
nuttx_user.elf - The pass1 user-space ELF file
|
|
||||||
nuttx_user.hex - The pass1 Intel HEX format file (selected in defconfig)
|
|
||||||
User.map - Symbols in the user-space ELF file
|
|
||||||
|
|
||||||
PASS2:
|
|
||||||
nuttx - The pass2 kernel-space ELF file
|
|
||||||
nuttx.hex - The pass2 Intel HEX file (selected in defconfig)
|
|
||||||
System.map - Symbols in the kernel-space ELF file
|
|
||||||
|
|
||||||
The J-Link programmer will except files in .hex, .mot, .srec, and .bin
|
|
||||||
formats.
|
|
||||||
|
|
||||||
3. Combining .hex files. If you plan to use the .hex files with your
|
|
||||||
debugger or FLASH utility, then you may need to combine the two hex
|
|
||||||
files into a single .hex file. Here is how you can do that.
|
|
||||||
|
|
||||||
a. The 'tail' of the nuttx.hex file should look something like this
|
|
||||||
(with my comments added):
|
|
||||||
|
|
||||||
$ tail nuttx.hex
|
|
||||||
# 00, data records
|
|
||||||
...
|
|
||||||
:10 9DC0 00 01000000000800006400020100001F0004
|
|
||||||
:10 9DD0 00 3B005A0078009700B500D400F300110151
|
|
||||||
:08 9DE0 00 30014E016D0100008D
|
|
||||||
# 05, Start Linear Address Record
|
|
||||||
:04 0000 05 0800 0419 D2
|
|
||||||
# 01, End Of File record
|
|
||||||
:00 0000 01 FF
|
|
||||||
|
|
||||||
Use an editor such as vi to remove the 05 and 01 records.
|
|
||||||
|
|
||||||
b. The 'head' of the nuttx_user.hex file should look something like
|
|
||||||
this (again with my comments added):
|
|
||||||
|
|
||||||
$ head nuttx_user.hex
|
|
||||||
# 04, Extended Linear Address Record
|
|
||||||
:02 0000 04 0801 F1
|
|
||||||
# 00, data records
|
|
||||||
:10 8000 00 BD89 01084C800108C8110208D01102087E
|
|
||||||
:10 8010 00 0010 00201C1000201C1000203C16002026
|
|
||||||
:10 8020 00 4D80 01085D80010869800108ED83010829
|
|
||||||
...
|
|
||||||
|
|
||||||
Nothing needs to be done here. The nuttx_user.hex file should
|
|
||||||
be fine.
|
|
||||||
|
|
||||||
c. Combine the edited nuttx.hex and un-edited nuttx_user.hex
|
|
||||||
file to produce a single combined hex file:
|
|
||||||
|
|
||||||
$ cat nuttx.hex nuttx_user.hex >combined.hex
|
|
||||||
|
|
||||||
Then use the combined.hex file with the to write the FLASH image. With
|
|
||||||
GDB this would be:
|
|
||||||
|
|
||||||
gdb> mon reset
|
|
||||||
gdb> mon halt
|
|
||||||
gdb> mon clrbp
|
|
||||||
gdb> load combined.hex
|
|
||||||
|
|
||||||
If you do this a lot, you will probably want to invest a little time
|
|
||||||
to develop a tool to automate these steps.
|
|
||||||
|
|
||||||
Configurations
|
|
||||||
==============
|
|
||||||
|
|
||||||
Information Common to All Configurations
|
|
||||||
----------------------------------------
|
|
||||||
Each Olimex STM32-P407 configuration is maintained in a sub-directory and can be
|
|
||||||
selected as follow:
|
|
||||||
|
|
||||||
tools/configure.sh olimex-stm32-p407:<subdir>
|
|
||||||
|
|
||||||
Where <subdir> is one of the configuration sub-directories listed in the
|
|
||||||
following section.
|
|
||||||
|
|
||||||
Before building, make sure the PATH environment variable includes the
|
|
||||||
correct path to the directory than holds your toolchain binaries.
|
|
||||||
|
|
||||||
And then build NuttX by simply typing the following. At the conclusion of
|
|
||||||
the make, the nuttx binary will reside in an ELF file called, simply, nuttx.
|
|
||||||
|
|
||||||
make oldconfig
|
|
||||||
make
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. This configuration uses the mconf-based configuration tool. To
|
|
||||||
change this configurations using that tool, you should:
|
|
||||||
|
|
||||||
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
|
|
||||||
see additional README.txt files in the NuttX tools repository.
|
|
||||||
|
|
||||||
b. Execute 'make menuconfig' in nuttx/ in order to start the
|
|
||||||
reconfiguration process.
|
|
||||||
|
|
||||||
2. Serial Output
|
|
||||||
|
|
||||||
This configuraiont produces all of its test output on the serial
|
|
||||||
console. This configuration has USART3 enabled as a serial console.
|
|
||||||
This is the connector labeled RS232_2. This can easily be changed
|
|
||||||
by reconfiguring with 'make menuconfig'.
|
|
||||||
|
|
||||||
3. Toolchain
|
|
||||||
|
|
||||||
By default, the host platform is set to be Linux using the NuttX
|
|
||||||
buildroot toolchain. The host and/or toolchain selection can easily
|
|
||||||
be changed with 'make menuconfig'.
|
|
||||||
|
|
||||||
4. Note that CONFIG_STM32_DISABLE_IDLE_SLEEP_DURING_DEBUG is enabled so
|
|
||||||
that the JTAG connection is not disconnected by the idle loop.
|
|
||||||
|
|
||||||
Configuration sub-directories
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
The <subdir> that is provided above as an argument to the tools/configure.sh
|
|
||||||
must be is one of the following.
|
|
||||||
|
|
||||||
dhtxx:
|
|
||||||
|
|
||||||
Configuration added by Abdelatif Guettouche for testing the the DHTxx
|
|
||||||
sensor. This configuration expects this setup:
|
|
||||||
|
|
||||||
DHTXX_PIN_OUTPUT PG9
|
|
||||||
DHTXX_PIN_INPUT PG9
|
|
||||||
|
|
||||||
The STM32 free-running timer is also required.
|
|
||||||
|
|
||||||
hidkbd
|
|
||||||
|
|
||||||
This is another NSH configuration that supports a USB HID Keyboard
|
|
||||||
device and the HID keyboard example at apps/examples/hidkbd.
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
2018-10-07: Not all keyboards will connect successfully. I have not
|
|
||||||
looked into the details but it may be that those keyboards are not
|
|
||||||
compatible with the driver (which only accepts "boot" keyboards).
|
|
||||||
Also, when typing input into the HID keyboard, characters are often
|
|
||||||
missing and sometimes duplicated. This is like some issue with the
|
|
||||||
read logic of drivers/usbhost_hidkbc.c.
|
|
||||||
|
|
||||||
kelf:
|
|
||||||
|
|
||||||
This is a protected mode version of the apps/examples/elf test of
|
|
||||||
loadable ELF programs. This version is unique because the ELF programs
|
|
||||||
are loaded into user space.
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. See build recommendations and instructions for combining the .hex
|
|
||||||
files under the section entitled "Protected Mode Build" above.
|
|
||||||
|
|
||||||
2. Unlike other versions of apps/examples/elf configurations, the test
|
|
||||||
ELF programs are not provided internally on a ROMFS or CROMFS file
|
|
||||||
system. This is due to the fact that those file systems are built in
|
|
||||||
user space and there is no mechanism in the build system to easily
|
|
||||||
get them into the kernel space.
|
|
||||||
|
|
||||||
Instead, the programs must be copied to a USB FLASH drive from your
|
|
||||||
host PC. The programs can be found at apps/examples/elf/tests/romfs.
|
|
||||||
All of those files should be copied to the USB FLASH drive. The
|
|
||||||
apps/example/elf will wait on power up until the USB FLASH drive
|
|
||||||
has been inserted and initialized.
|
|
||||||
|
|
||||||
kmodule:
|
|
||||||
|
|
||||||
This is a protected mode version of the apps/examples/module test of
|
|
||||||
loadable ELF kernel modules. This version is unique because the ELF
|
|
||||||
programs are loaded into the protected kernel space.
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. See build recommendations and instructions for combining the .hex
|
|
||||||
files under the section entitled "Protected Mode Build" above.
|
|
||||||
|
|
||||||
2. Unlike other versions of apps/examples/module configurations, the test
|
|
||||||
ELF modules are not provided internally on a ROMFS or CROMFS file
|
|
||||||
system. This is due to the fact that those file systems are built in
|
|
||||||
user space and there is no mechanism in the build system to easily
|
|
||||||
get them into the kernel space.
|
|
||||||
|
|
||||||
Instead, the module(s) must be copied to a USB FLASH drive from your
|
|
||||||
host PC. The module(s) can be found at apps/examples/module/driver/fsroot.
|
|
||||||
All of those file(s) should be copied to the USB FLASH drive. Like the
|
|
||||||
kelf configuration, the logic in apps/example/module will wait on power
|
|
||||||
up until the USB FLASH drive has been inserted and initialized.
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
2018-08-07: After some struggle, the configuration appears to be
|
|
||||||
working correctly.
|
|
||||||
|
|
||||||
knsh:
|
|
||||||
|
|
||||||
This is identical to the nsh configuration below except that NuttX
|
|
||||||
is built as a PROTECTED mode, monolithic module and the user applications
|
|
||||||
are built separately.
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. See build recommendations and instructions for combining the .hex
|
|
||||||
files under the section entitled "Protected Mode Build" above.
|
|
||||||
|
|
||||||
module:
|
|
||||||
|
|
||||||
A simple stripped down NSH configuration that was used for testing NuttX
|
|
||||||
OS modules using the test at apps/examples/module. Key difference from
|
|
||||||
the nsh configuration include these additions to the configuration file:
|
|
||||||
|
|
||||||
CONFIG_BOARDCTL_OS_SYMTAB=y
|
|
||||||
CONFIG_EXAMPLES_MODULE=y
|
|
||||||
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
|
|
||||||
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
|
|
||||||
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
|
|
||||||
CONFIG_FS_ROMFS=y
|
|
||||||
CONFIG_LIBC_ARCH_ELF=y
|
|
||||||
CONFIG_MODULE=y
|
|
||||||
CONFIG_LIBC_MODLIB=y
|
|
||||||
CONFIG_MODLIB_MAXDEPEND=2
|
|
||||||
CONFIG_MODLIB_ALIGN_LOG2=2
|
|
||||||
CONFIG_MODLIB_BUFFERSIZE=128
|
|
||||||
CONFIG_MODLIB_BUFFERINCR=32
|
|
||||||
|
|
||||||
The could be followed may be added for testing shared libraries in the
|
|
||||||
FLAT build using apps/examples/sotest (assuming that you also have SD
|
|
||||||
card support enabled and that the SD card is mount at /mnt/sdcard):
|
|
||||||
|
|
||||||
CONFIG_LIBC_DLFCN=y
|
|
||||||
CONFIG_EXAMPLES_SOTEST=y
|
|
||||||
CONFIG_EXAMPLES_SOTEST_BINDIR="/mnt/sdcard"
|
|
||||||
|
|
||||||
NOTE: You must always have:
|
|
||||||
|
|
||||||
CONFIG_STM32_CCMEXCLUDE=y
|
|
||||||
|
|
||||||
because code cannot be executed from CCM memory.
|
|
||||||
|
|
||||||
STATUS:
|
|
||||||
2018-06-01: Configuration added. Works perfectly.
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
|
|
||||||
This is the NuttShell (NSH) using the NSH startup logic at
|
|
||||||
apps/examples/nsh
|
|
||||||
|
|
||||||
NOTES:
|
|
||||||
|
|
||||||
1. USB host support for USB FLASH sticks is enabled. See the notes
|
|
||||||
above under "OTGFS Host".
|
|
||||||
|
|
||||||
STATUS: I have seen this work with some FLASH sticks but not with
|
|
||||||
others. I have not studied the failure case carefully. They seem
|
|
||||||
to fail because the request is NAKed. That is not a failure, however,
|
|
||||||
that is normal behavior when the FLASH is not ready.
|
|
||||||
|
|
||||||
There have been other cases like this with the STM32 host drivers:
|
|
||||||
in the event of NAKs, other drivers retry and wait for the data. The
|
|
||||||
STM32 does not but returns the NAK failure immediately. My guess is
|
|
||||||
that there needs to be be some retry logic to the driver 100%
|
|
||||||
reliable.
|
|
||||||
|
|
||||||
2. Kernel Modules / Shared Libraries
|
|
||||||
|
|
||||||
I used this configuration for testing NuttX kernel modules in the
|
|
||||||
FLAT build with the following configuration additions to the
|
|
||||||
configuration file:
|
|
||||||
|
|
||||||
CONFIG_BOARDCTL_OS_SYMTAB=y
|
|
||||||
CONFIG_EXAMPLES_MODULE=y
|
|
||||||
CONFIG_EXAMPLES_MODULE_BUILTINFS=y
|
|
||||||
CONFIG_EXAMPLES_MODULE_DEVMINOR=0
|
|
||||||
CONFIG_EXAMPLES_MODULE_DEVPATH="/dev/ram0"
|
|
||||||
CONFIG_FS_ROMFS=y
|
|
||||||
CONFIG_LIBC_ARCH_ELF=y
|
|
||||||
CONFIG_MODULE=y
|
|
||||||
CONFIG_LIBC_MODLIB=y
|
|
||||||
CONFIG_MODLIB_ALIGN_LOG2=2
|
|
||||||
CONFIG_MODLIB_BUFFERINCR=32
|
|
||||||
CONFIG_MODLIB_BUFFERSIZE=128
|
|
||||||
|
|
||||||
Add the following for testing shared libraries in the FLAT
|
|
||||||
build:
|
|
||||||
|
|
||||||
CONFIG_LIBC_DLFCN=y
|
|
||||||
CONFIG_EXAMPLES_SOTEST=y
|
|
||||||
CONFIG_EXAMPLES_SOTEST_BUILTINFS=y
|
|
||||||
CONFIG_EXAMPLES_SOTEST_DEVMINOR=1
|
|
||||||
CONFIG_EXAMPLES_SOTEST_DEVPATH="/dev/ram1"
|
|
||||||
|
|
||||||
zmodem:
|
|
||||||
|
|
||||||
This configuration was used to test the zmodem utilities at
|
|
||||||
apps/system/zmodem. Two serial ports are used in this configuration:
|
|
||||||
|
|
||||||
1. USART6 (RS232_1) is the serial console (because it does not support
|
|
||||||
hardware flow control). It is configured 115200 8N1.
|
|
||||||
2. USART3 (RS232_2) is the zmodem port and does require that hardware
|
|
||||||
flow control be enabled for use. It is configured 9600 8N1.
|
|
||||||
|
|
||||||
On the target these will correspond to /dev/ttyS0 and /dev/ttyS1,
|
|
||||||
respectively.
|
|
||||||
|
|
||||||
It is possible to configure a system without hardware flow control and
|
|
||||||
using the same USART for both the serial console and for zmodem.
|
|
||||||
However, you would have to take extreme care with buffering and data
|
|
||||||
throughput considerations to assure that there is no Rx data overrun.
|
|
||||||
|
|
||||||
General usage instructions:
|
|
||||||
|
|
||||||
1. Common Setup
|
|
||||||
|
|
||||||
[on target]
|
|
||||||
nsh> mount -t vfat /dev/sda /mnt
|
|
||||||
|
|
||||||
[on Linux host]
|
|
||||||
$ sudo stty -F /dev/ttyS0 9600
|
|
||||||
$ sudo stty -F /dev/ttyS0 crtscts *
|
|
||||||
$ sudo stty -F /dev/ttyS0 raw
|
|
||||||
$ sudo stty -F /dev/ttyS0
|
|
||||||
|
|
||||||
* Because hardware flow control will be enabled on the target side
|
|
||||||
in this configuration.
|
|
||||||
|
|
||||||
2. Host-to-Target File Transfer
|
|
||||||
|
|
||||||
[on target]
|
|
||||||
nsh> rz
|
|
||||||
|
|
||||||
[on host]
|
|
||||||
$ sudo sz <filename> [-l nnnn] </dev/ttyS0 >/dev/ttyS0
|
|
||||||
|
|
||||||
Where <filename> is the file that you want to transfer. If -l nnnn is
|
|
||||||
not specified, then there will likely be packet buffer overflow errors.
|
|
||||||
nnnn should be set to a strictly less than CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE.
|
|
||||||
All testing was performed with -l 512.
|
|
||||||
|
|
||||||
If you are using the NuttX implementation of rz and sz on the Linux host,
|
|
||||||
then the last command simplifies to just:
|
|
||||||
|
|
||||||
[on host]
|
|
||||||
$ cp README.txt /tmp/.
|
|
||||||
$ sudo ./sz -d /dev/ttyS1 README.txt
|
|
||||||
|
|
||||||
Assuming that /dev/ttyS0 is the serial and /dev/ttyS1 is the zmodem port
|
|
||||||
on the Linux host as well. NOTE: By default, files will be transferred
|
|
||||||
to and from the /tmp directory only.
|
|
||||||
|
|
||||||
Refer to the README file at apps/examples/zmodem for detailed information
|
|
||||||
about building rz/sz for the host and about zmodem usage in general.
|
|
||||||
|
|
||||||
3. Target-to-Host File Transfer
|
|
||||||
|
|
||||||
[on host]
|
|
||||||
$ rz </dev/ttyS0 >/dev/ttyS0
|
|
||||||
|
|
||||||
The transferred file will end up in the current directory.
|
|
||||||
|
|
||||||
If you are using the NuttX implementation of rz and sz on the Linux host,
|
|
||||||
then the last command simplifies to just:
|
|
||||||
|
|
||||||
[on host]
|
|
||||||
$ ./rz
|
|
||||||
|
|
||||||
The transferred file will lie in the /tmp directory.
|
|
||||||
|
|
||||||
Then on the target side:
|
|
||||||
|
|
||||||
[on target]
|
|
||||||
nsh sz <filename>
|
|
||||||
|
|
||||||
Where <filename> is the file that you want to transfer.
|
|
||||||
|
|
||||||
STATUS
|
|
||||||
======
|
|
||||||
|
|
||||||
2016-12-21: This board configuration was ported from the Olimex STM32 P207
|
|
||||||
port. Note that none of the above features have been verified. USB, CAN,
|
|
||||||
ADC, and Ethernet are disabled in the base NSH configuration until they
|
|
||||||
can be verified. These features should be functional but may required
|
|
||||||
some tweaks due to the different clock configurations. The Olimex STM32
|
|
||||||
P207 nsh/defconfig would be a good starting place for restoring these
|
|
||||||
feature configurations.
|
|
||||||
|
|
||||||
CCM memory is not included in the heap (CONFIG_STM32_CCMEXCLUDE=y) because
|
|
||||||
it does not support DMA, leaving only 128KiB for program usage.
|
|
||||||
|
|
||||||
2017-01-23: Added the knsh configuration and support for the PROTECTED
|
|
||||||
build mode.
|
|
||||||
|
|
||||||
2018-05-27: Added the zmodem configuration. Verified correct operation
|
|
||||||
with host-to-target transfers (using Linux sz command). There appears
|
|
||||||
to be a problem using the NuttX sz command running on the host???
|
|
||||||
|
|
||||||
2018-05-28: Verified correct operation with target-to-host transfers (using
|
|
||||||
Linux rz command). There appears to be a problem using the NuttX rz
|
|
||||||
command running on the host???
|
|
||||||
|
|
||||||
2018-06-01: Added the module configuration. Works perfectly.
|
|
||||||
@ -1,80 +0,0 @@
|
|||||||
OMNIBUSF4 Target Support README
|
|
||||||
===============================
|
|
||||||
|
|
||||||
"OmnibusF4" is not a product name per se, but rather a design spec
|
|
||||||
that many product vendors within the drone flight management unit
|
|
||||||
(FMU) community adhere to. The spec defines the major components, and
|
|
||||||
how those components are wired into the STM32F405RGT6 microcontroller.
|
|
||||||
|
|
||||||
Airbot is one such vendor, and they publish a schematic here:
|
|
||||||
|
|
||||||
http://bit.ly/obf4pro
|
|
||||||
|
|
||||||
Other software that supports the OmnibusF4 family include Betaflight,
|
|
||||||
iNAV, and many others. PX4 recently added support as well. No code
|
|
||||||
from any of those sources is included in this port.
|
|
||||||
|
|
||||||
Since OmnibusF4 is a drone FMU, most of its IO is already allocated to
|
|
||||||
FMU-specific tasks. As such, we don't need to make the board support
|
|
||||||
package as flexible as, say, an STM32F4 Discovery board.
|
|
||||||
|
|
||||||
The following are some of the committed IO pins. Most of the pins not
|
|
||||||
mentioned here are inaccessible, the details vary by board vendor:
|
|
||||||
|
|
||||||
io peripheral signal notes
|
|
||||||
==================================
|
|
||||||
XIN 8MHz crystal oscillator
|
|
||||||
|
|
||||||
PB0 TIM3 CH3 S1_OUT motor 1 PWM output
|
|
||||||
PB1 TIM3 CH4 S2_OUT motor 2 PWM output
|
|
||||||
PA3 TIM2 CH4 S3_OUT motor 3 PWM output
|
|
||||||
PA2 TIM2 CH3 S4_OUT motor 4 PWM output
|
|
||||||
PA1 TIM2 CH2 S5_OUT motor 5 PWM output
|
|
||||||
PA8 TIM1 CH4 S6_OUT motor 6 PWM output
|
|
||||||
|
|
||||||
PA4 SPI1 SPI1_NSS mpu6000
|
|
||||||
PA5 SPI1 SPI1_SCL
|
|
||||||
PA6 SPI1 SPI1_MISO
|
|
||||||
PA7 SPI1 SPI1_MOSI
|
|
||||||
|
|
||||||
PC4 GPIO GYRO_INT mpu6000 EXTI
|
|
||||||
|
|
||||||
PB10 UART3/I2C UART3_TX ttl UART tx or i2c_scl (used as console)
|
|
||||||
PB11 UART3/I2C UART3_RX ttl UART rx or i2c_sda (used as console)
|
|
||||||
|
|
||||||
PB9 RC_CH2 (rx pwm input)
|
|
||||||
PB8 RC_CH1 (rx pwm input)
|
|
||||||
PC9 RC_CH6 (rx pwm input)
|
|
||||||
PC8 RC_CH5 (rx pwm input)
|
|
||||||
PC7 RC_CH4 or USART6_RX (ttl)
|
|
||||||
PC6 RC_CH3 or USART6_TX (ttl)
|
|
||||||
|
|
||||||
PB7 GPIO SD_DET SD card detection pin (low when card inserted)
|
|
||||||
PB5 GPIO STAT LED output (active low)
|
|
||||||
PB4 GPIO BUZZER buzzer output (active low)
|
|
||||||
|
|
||||||
PD2 GPIO LED_STRIP one-wire interface for LED strips
|
|
||||||
|
|
||||||
PC12 SPI3 SPI3_MOSI bmp280 barometer (if populated) and/or max7456 OSD
|
|
||||||
PC11 SPI3 SPI3_MISO
|
|
||||||
PC10 SPI3 SPI3_SCL
|
|
||||||
PA15 GPIO SPI3_NSS OSD NSS
|
|
||||||
PB3 GPIO BARO_CS bmp280 NSS (if populated)
|
|
||||||
|
|
||||||
PA12 OTG USB_DP
|
|
||||||
PA11 OTG USB_DN
|
|
||||||
|
|
||||||
PA10 UART1 USART1_RX SBUS_IN (through inverter) or PPM
|
|
||||||
PA9 UART1 USART1_TX
|
|
||||||
|
|
||||||
PB15 SPI2 SPI2_MOSI sd/mmc card interface
|
|
||||||
PB14 SPI2 SPI2_MISO
|
|
||||||
PB13 SPI2 SPI2_SCLK
|
|
||||||
PB12 SPI2 SPI2_NSS
|
|
||||||
|
|
||||||
Build Instructions
|
|
||||||
==================
|
|
||||||
|
|
||||||
The boards/arm/stm32/omnibusf4/nsh/defconfig file creates a basic setup, and
|
|
||||||
includes drivers for all supported onboard chips. The console and
|
|
||||||
command prompt are sent to USART3.
|
|
||||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,105 +0,0 @@
|
|||||||
README.txt
|
|
||||||
==========
|
|
||||||
|
|
||||||
STM32F429I-DISCO LTDC Framebuffer demo example
|
|
||||||
|
|
||||||
Configure and build
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
cd tools
|
|
||||||
./configure -a <appdir> stm32f429i-disco/fb
|
|
||||||
cd ..
|
|
||||||
make
|
|
||||||
|
|
||||||
Framebuffer calculation
|
|
||||||
----------------------
|
|
||||||
|
|
||||||
Use the helper script boards/stm32f429i-disco/tools/fbcalc.sh for calculating
|
|
||||||
the heap2 and framebuffer memory region. The script assumes that all overlay
|
|
||||||
buffers (LTDC and DMA2D) located in heap2 memory region starting at address
|
|
||||||
0xD0000000. When changing the display size (when using a custom display), DMA2D
|
|
||||||
overlay size or the pixel format you have to recalculate the heap2 settings.
|
|
||||||
In this configuration all overlays (LTDC and DMA2D) positioned at the end of
|
|
||||||
heap2.
|
|
||||||
|
|
||||||
LTDC hardware acceleration
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
The LTDC driver provides two 2 LTDC overlays and supports the following hardware
|
|
||||||
acceleration and features:
|
|
||||||
|
|
||||||
Configured at build time
|
|
||||||
- background color
|
|
||||||
- default color (outside visible screen)
|
|
||||||
|
|
||||||
Configurable by nuttx framebuffer interface
|
|
||||||
- cmap support (color table is shared by both LTDC overlays and DMA2D when
|
|
||||||
enabled)
|
|
||||||
|
|
||||||
Configurable via the nuttx framebuffer interface (for each layer separately)
|
|
||||||
- chromakey
|
|
||||||
- transparency (const alpha and pixel alpha)
|
|
||||||
- blank
|
|
||||||
- color (if DMA2D is enabled and cmap is disabled)
|
|
||||||
- blit (if DMA2D is enabled)
|
|
||||||
- blend (if DMA2D is enabled and cmap is disabled)
|
|
||||||
|
|
||||||
LTDC overlays are similar to a non-destructive overlay. Both LTDC overlays will
|
|
||||||
be permanently blended in the order (background -> overlay 0 -> overlay 1) and
|
|
||||||
converted to a resulting video signal by the LTDC controller. That means each
|
|
||||||
operation with a LTDC overlay (Overlay 0 and Overlay 1) via nuttx framebuffer
|
|
||||||
interface will be visible immediately.
|
|
||||||
Think about continuous blending between both overlays.
|
|
||||||
|
|
||||||
DMA2D hardware acceleration
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
The DMA2D driver implements the following hardware acceleration:
|
|
||||||
|
|
||||||
Configurable via the nuttx framebuffer interface
|
|
||||||
- cmap support (color table is shared by all DMA2D overlays and LTDC overlays)
|
|
||||||
|
|
||||||
Configurable via the nuttx framebuffer interface (for each layer separately)
|
|
||||||
|
|
||||||
- color (fill memory region with a specific ARGB8888 color immediately), if
|
|
||||||
cmap is disabled
|
|
||||||
- blit (copy memory region to another memory region with pixel format
|
|
||||||
conversion if necessary)
|
|
||||||
- blend (blend two memory regions and copy the result to a third memory region
|
|
||||||
with pixel format conversion if necessary), if cmap is disabled
|
|
||||||
|
|
||||||
Blit and blend operation using a fixes memory size defined by the background
|
|
||||||
layer. DMA2D controller doesn't support scaling.
|
|
||||||
|
|
||||||
DMA2D overlays are similar to destructive overlays. They are invisible. They can
|
|
||||||
be used for image preprocessing. The memory region affected by the operations
|
|
||||||
(color, blit, blend) can be addressed by the area control command before. The
|
|
||||||
configured overlay transparency of DMA2D overlays will be used for subsequently
|
|
||||||
blend operation and is valid for the whole overlay.
|
|
||||||
|
|
||||||
Configuration
|
|
||||||
------------
|
|
||||||
|
|
||||||
This configuration provides 2 LTDC (visible overlays) and 2 DMA2D overlays with
|
|
||||||
pixel format RGB565 and a resolution of 240x320.
|
|
||||||
|
|
||||||
Loading
|
|
||||||
-------
|
|
||||||
|
|
||||||
st-flash write nuttx.bin 0x8000000
|
|
||||||
|
|
||||||
Executing
|
|
||||||
---------
|
|
||||||
|
|
||||||
The ltdc is initialized during boot up. Interaction with NSH is via the serial
|
|
||||||
console at 115200 8N1 baud. From the nsh comandline execute the fb example:
|
|
||||||
|
|
||||||
nsh> fb
|
|
||||||
|
|
||||||
The test will put a pattern of concentric squares in the framebuffer and
|
|
||||||
terminate.
|
|
||||||
|
|
||||||
You can also test overlay hardware acceleration functionality by executing the
|
|
||||||
following command (shows a commandline help):
|
|
||||||
|
|
||||||
nsh> fboverlay
|
|
||||||
File diff suppressed because it is too large
Load Diff
@ -1,75 +0,0 @@
|
|||||||
Nucleo-WL55JC README
|
|
||||||
====================
|
|
||||||
|
|
||||||
This README file discusses the port of NuttX to the STMicro Nucleo-WL55JC
|
|
||||||
board. That board features the STM32WL55JCI7 MCU with 256KiB of FLASH and
|
|
||||||
64KiB of SRAM. This is dual CPU (not core) chip. There is integrated LORA
|
|
||||||
hardware on board which is only available via CPU0.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- Status
|
|
||||||
- LEDs
|
|
||||||
- Buttons
|
|
||||||
- Serial Console
|
|
||||||
- Configurations
|
|
||||||
- Flashing
|
|
||||||
|
|
||||||
Status
|
|
||||||
======
|
|
||||||
|
|
||||||
2022.06.07: Board boots and nsh works without problems. Both arduino and
|
|
||||||
virtual com port UARTs work.
|
|
||||||
|
|
||||||
LEDs
|
|
||||||
====
|
|
||||||
|
|
||||||
There are user controlled 3 LEDs. Blue (PB15), Green(PB9) and Red(PB11).
|
|
||||||
To turn on the LED, GPIO has to be driven to HIGH state.
|
|
||||||
|
|
||||||
Green and Red LEDs are used by the system at boot to show system state.
|
|
||||||
Once system is booted these LEDs are for user to control. When
|
|
||||||
CONFIG_ARCH_LEDS is set, Blue LED is reserved by OS for reporting system
|
|
||||||
status. When CONFIG_ARCH_LEDS is not set, OS state won't be reported on
|
|
||||||
any of the LEDs and all 3 LEDs are available for user right from the start.
|
|
||||||
|
|
||||||
Buttons
|
|
||||||
=======
|
|
||||||
|
|
||||||
There are 3 buttons that are available for the user to program, and one
|
|
||||||
reset button.
|
|
||||||
|
|
||||||
Serial Console
|
|
||||||
==============
|
|
||||||
|
|
||||||
There are 2 serial ports - USART1 and LPUART1.
|
|
||||||
|
|
||||||
USART1 is connected to arduino D0/D1 pin and LPUART is connected to
|
|
||||||
stlink that provides virtual serial port.
|
|
||||||
|
|
||||||
NSH is configured to use LPUART and virtual serial port. After flashing
|
|
||||||
you can open /dev/ttyACM0 (may change depending on your system) and nsh
|
|
||||||
prompt will be waiting for you there. Serial device does not disappear
|
|
||||||
when flashing and resetting board - it can be left opened and flashing
|
|
||||||
will work without problems.
|
|
||||||
|
|
||||||
Configuration
|
|
||||||
=============
|
|
||||||
|
|
||||||
Configuration sub-directories
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
nsh:
|
|
||||||
|
|
||||||
Configures the NuttShell (nsh) located at examples/nsh. NSH is will
|
|
||||||
work on virtual serial port over usb.
|
|
||||||
|
|
||||||
Flashing
|
|
||||||
========
|
|
||||||
|
|
||||||
Easiest way to flash nucleo is to use openocd tool. Openocd supports
|
|
||||||
stlink v3 which is on the board. It's as easy as running:
|
|
||||||
|
|
||||||
openocd -f interface/stlink.cfg -f target/stm32wlx.cfg \
|
|
||||||
-c "program nuttx.bin exit 0x08000000"
|
|
||||||
Loading…
x
Reference in New Issue
Block a user