mirror of
https://github.com/apache/nuttx.git
synced 2026-08-01 20:28:58 +00:00
BREAKING: In an effort to simplify NuttX initialization, NSH_ARCHINIT is removed. board_app_initialize is also removed. BOARD_LATE_INITIALIZE now performs all board initialization logic, and is by default enabled. All references to these symbols are removed. BOARDIOC_INIT remains, but will result in -ENOTTY when called. It is to be removed in a later commit. Quick fix: Boards relying on NSH_ARCHINIT should now enable CONFIG_BOARD_LATE_INITIALIZE instead. If the application needs fine-grained control over board initialization from userspace, the logic performed by BOARDIOC_INIT may be copied to the board_finalinitialize function and used instead via BOARDIOC_FINALINIT. All board_app_initialize logic provided by NuttX is now moved to board_late_initialize, and the same should be done for out-of-tree boards. Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
1441 lines
50 KiB
ReStructuredText
1441 lines
50 KiB
ReStructuredText
========
|
|
SAM4E-EK
|
|
========
|
|
|
|
This README discusses issues unique to NuttX configurations for the Atmel
|
|
SAM4E-EK development. This board features the SAM4E16 MCU running at 96 or
|
|
120MHz.
|
|
|
|
Atmel Studio 6.1
|
|
================
|
|
|
|
You can use Atmel Studio 6.1 to load and debug code.
|
|
|
|
* To load code into FLASH:
|
|
|
|
Tools menus: Tools -> Device Programming.
|
|
|
|
Configure the debugger and chip and you are in business.
|
|
|
|
* Debugging the NuttX Object File:
|
|
|
|
1. Rename object file from ``nuttx`` to ``nuttx.elf``. That is an extension
|
|
that will be recognized by the file menu.
|
|
|
|
2. Select the project name, the full path to the NuttX object (called just
|
|
``nuttx`` with no extension), and chip. Take the time to resolve all of the
|
|
source file linkages or else you will not have source level debug!
|
|
|
|
File menu: File -> Open -> Open object file for debugging
|
|
|
|
* Select nuttx.elf object file
|
|
* Select AT91SAM4E16
|
|
* Select files for symbols as desired
|
|
* Select debugger
|
|
|
|
3. Debug menu: Debug -> Start debugging and break
|
|
|
|
* This will reload the nuttx.elf file into FLASH
|
|
|
|
.. warning::
|
|
|
|
At this point, Atmel Studio 6.1 claims that my object files are not readable.
|
|
A little more needs to be done to wring out this procedure.
|
|
|
|
Loading Code with J-Link
|
|
========================
|
|
|
|
Loading code with the Segger tools and GDB
|
|
------------------------------------------
|
|
|
|
1. Change directories into the directory where you built NuttX.
|
|
|
|
2. Start the GDB server and wait until it is ready to accept GDB
|
|
connections.
|
|
|
|
3. Then run GDB like this:
|
|
|
|
.. code:: console
|
|
|
|
$ arm-none-eabi-gdb
|
|
(gdb) target remote localhost:2331
|
|
(gdb) mon reset
|
|
(gdb) load nuttx
|
|
(gdb) ... start debugging ...
|
|
|
|
Loading code using J-Link Commander
|
|
-----------------------------------
|
|
|
|
.. code:: console
|
|
|
|
J-Link> r
|
|
J-Link> loadbin <file> <address>
|
|
J-Link> setpc <address of __start>
|
|
J-Link> ... start debugging ...
|
|
|
|
.. warning::
|
|
|
|
As of this writing, I have not been successful writing to FLASH using the GDB
|
|
server; the write succeeds with no complaints, but the contents of the FLASH
|
|
memory remain unchanged. This may be because of issues with GPNVM1 settings
|
|
and flash lock bits? In any event, the GDB server works great for debugging
|
|
after writing the program to FLASH using SAM-BA.
|
|
|
|
Loading Code OpenOCD
|
|
====================
|
|
|
|
OpenOCD scripts are available in the ``boards/sam4e-ek/tools`` directory. These
|
|
scripts were used with OpenOCD 0.8.0. If you use a version after OpenOCD 0.8.0,
|
|
then you should comment out the following lines in the ``openocd.cfg`` file:
|
|
|
|
.. code:: cfg
|
|
|
|
# set CHIPNAME SAM4E16E
|
|
# source [find target/at91sam4sXX.cfg]
|
|
|
|
And uncomment this line:
|
|
|
|
.. code:: cfg
|
|
|
|
source [find board/atmel_sam4e_ek.cfg]
|
|
|
|
This have been reported to work under Linux, but I have not been
|
|
successful using it under Windows OpenOCD 0.8.0 with libUSB. I get:
|
|
|
|
.. code:: console
|
|
|
|
Open On-Chip Debugger 0.8.0 (2014-04-28-08:42)
|
|
...
|
|
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
|
|
Error: Cannot find jlink Interface! Please check connection and permissions.
|
|
...
|
|
|
|
This is telling me that the Segger J-Link USB driver is incompatible with
|
|
libUSB. It may be necessary to replace the Segger J-Link driver with the driver
|
|
from ``libusb-win32-device-bin`` on sourceforge.
|
|
|
|
* Go into Control Panel/System/Device Manager and update the J-Link driver to
|
|
point at the new ``jlink.inf`` file made with the ``libusb-win32/bin
|
|
inf-wizard``. Browse to the unsigned driver pointed to by the inf, libusb0.dll
|
|
from the ``libusb-win32-device-bin`` distribution to complete the
|
|
installation.
|
|
|
|
* The Segger driver appeared under "Universal Serial Bus Controllers"
|
|
in Device Manager (winXP) while the libusb-win32 driver appears as
|
|
new top level Dev Mgr category "LibUSB-Win32 Devices".
|
|
|
|
Writing to FLASH using SAM-BA
|
|
=============================
|
|
|
|
Assumed starting configuration:
|
|
|
|
1. You have installed the J-Link USB driver
|
|
|
|
Using SAM-BA to write to FLASH:
|
|
|
|
1. Start the SAM-BA application, selecting (1) the SAM-ICE/J-Link
|
|
port, and (2) board = at91sam4e16-ek.
|
|
2. The SAM-BA menu should appear.
|
|
3. Select the FLASH tab and enable FLASH access
|
|
4. "Send" the file to flash
|
|
5. Enable "Boot from Flash (GPNVM1)
|
|
6. Reset the board.
|
|
|
|
LEDs
|
|
====
|
|
|
|
The SAM4E-EK board has three, user-controllable LEDs labelled D2 (blue), D3
|
|
(amber), and D4 (green) on the board. Usage of these LEDs is defined in
|
|
``include/board.h`` and ``src/up_leds.c``. They are encoded as follows:
|
|
|
|
=================== ================================= ======= ======= =======
|
|
SYMBOL Meaning D3 D2 D4
|
|
=================== ================================= ======= ======= =======
|
|
LED_STARTED NuttX has been started OFF OFF OFF
|
|
LED_HEAPALLOCATE Heap has been allocated OFF OFF ON
|
|
LED_IRQSENABLED Interrupts enabled OFF ON OFF
|
|
LED_STACKCREATED Idle stack created OFF ON ON
|
|
LED_INIRQ In an interrupt (note 2) N/C FLASH N/C
|
|
LED_SIGNAL In a signal handler (note 3) N/C N/C FLASH
|
|
LED_ASSERTION An assertion failed FLASH N/C N/C
|
|
LED_PANIC The system has crashed FLASH N/C N/C
|
|
=================== ================================= ======= ======= =======
|
|
|
|
.. note::
|
|
|
|
If D2 and D4 are statically on, then NuttX probably failed to boot and these
|
|
LEDs will give you some indication of where the failure was
|
|
|
|
.. note::
|
|
|
|
The normal state is D3=OFF, D4=ON and D2 faintly glowing. This faint glow is
|
|
because of timer interrupts that result in the LED being illuminated on a
|
|
small proportion of the time.
|
|
|
|
.. note::
|
|
|
|
D4 may also flicker normally if signals are processed.
|
|
|
|
Serial Console
|
|
==============
|
|
|
|
By default, all of these configurations use UART0 for the NuttX serial
|
|
console. UART0 corresponds to the DB-9 connector J17 labelled "DBGU".
|
|
This is a male connector and will require a female-to-female, NUL modem
|
|
cable to connect to a PC.
|
|
|
|
An alternate is USART1 which connects to the other DB-9 connector labelled
|
|
"USART1". USART1 is not enabled by default unless specifically noted
|
|
otherwise in the configuration description. A NUL modem cable must be
|
|
used with the port as well.
|
|
|
|
.. note::
|
|
|
|
To avoid any electrical conflict, the RS232 and RS485 transceiver are
|
|
isolated from the receiving line PA21.
|
|
|
|
* Chose RS485 channel: Close 1-2 pins on JP11 and set PA23 to high level
|
|
* Chose RS232 channel: Close 2-3 pins on JP11 and set PA23 to low level
|
|
|
|
By default serial console is configured for 115000, 8-bit, 1 stop bit, and
|
|
no parity.
|
|
|
|
Networking Support
|
|
==================
|
|
|
|
Networking support via the can be added to NSH by selecting the following
|
|
configuration options.
|
|
|
|
Selecting the EMAC peripheral
|
|
-----------------------------
|
|
|
|
System Type -> SAM34 Peripheral Support
|
|
|
|
* ``CONFIG_SAM34_EMAC=y``: Enable the EMAC peripheral
|
|
|
|
System Type -> EMAC device driver options
|
|
|
|
* ``CONFIG_SAM34_EMAC_NRXBUFFERS=16``: Set aside some RS and TX buffers
|
|
* ``CONFIG_SAM34_EMAC_NTXBUFFERS=4``
|
|
* ``CONFIG_SAM34_EMAC_PHYADDR=1``: KSZ8051 PHY is at address 1
|
|
* ``CONFIG_SAM34_EMAC_AUTONEG=y``: Use autonegotiation
|
|
* ``CONFIG_SAM34_EMAC_MII=y``: Only the MII interface is supported
|
|
* ``CONFIG_SAM34_EMAC_PHYSR=30``: Address of PHY status register on KSZ8051
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_ALTCONFIG=y``: Needed for KSZ8051
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_ALTMODE=0x7``
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_10HD=0x1``
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_100HD=0x2``
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_10FD=0x5``
|
|
* ``CONFIG_SAM34_EMAC_PHYSR_100FD=0x6``
|
|
|
|
PHY selection. Later in the configuration steps, you will need to select
|
|
the KSZ8051 PHY for EMAC (See below)
|
|
|
|
Networking Support
|
|
|
|
* ``CONFIG_NET=y``: Enable Neworking
|
|
* ``CONFIG_NET_SOCKOPTS=y``: Enable socket operations
|
|
* ``CONFIG_NET_ETH_PKTSIZE=562``: Maximum packet size 1518 is more standard
|
|
* ``CONFIG_NET_TCP=y``: Enable TCP/IP networking
|
|
* ``CONFIG_NET_TCPBACKLOG=y``: Support TCP/IP backlog
|
|
* ``CONFIG_NET_UDP=y``: Enable UDP networking
|
|
* ``CONFIG_NET_BROADCAST=y``: Needed for DNS name resolution
|
|
* ``CONFIG_NET_ICMP=y``: Enable ICMP networking
|
|
* ``CONFIG_NET_ICMP_SOCKET=y``: Needed for NSH ping command
|
|
|
|
Defaults should be okay for other options.
|
|
|
|
Device drivers -> Network Device/PHY Support
|
|
|
|
* ``CONFIG_NETDEVICES=y``: Enabled PHY selection
|
|
* ``CONFIG_ETH0_PHY_KSZ8051=y``: Select the KSZ8051 PHY (for EMAC)
|
|
|
|
Application Configuration -> Network Utilities
|
|
|
|
* ``CONFIG_NETDB_DNSCLIENT=y``: Enable host address resolution
|
|
* ``CONFIG_NETUTILS_TELNETD=y``: Enable the Telnet daemon
|
|
* ``CONFIG_NETUTILS_TFTPC=y``: Enable TFTP data file transfers for get and put commands
|
|
* ``CONFIG_NETUTILS_NETLIB=y``: Network library support is needed
|
|
* ``CONFIG_NETUTILS_WEBCLIENT=y``: Needed for wget support
|
|
|
|
Defaults should be okay for other options
|
|
|
|
Application Configuration -> NSH Library
|
|
|
|
* ``CONFIG_NSH_TELNET=y``: Enable NSH session via Telnet
|
|
* ``CONFIG_NSH_IPADDR=0x0a000002``: Select a fixed IP address
|
|
* ``CONFIG_NSH_DRIPADDR=0x0a000001``: IP address of gateway/host PC
|
|
* ``CONFIG_NSH_NETMASK=0xffffff00``: Netmask
|
|
* ``CONFIG_NSH_NOMAC=y``: Need to make up a bogus MAC address
|
|
|
|
Defaults should be okay for other options
|
|
|
|
You can also enable enable the DHCPC client for networks that use dynamically
|
|
assigned address:
|
|
|
|
Application Configuration -> Network Utilities
|
|
|
|
* ``CONFIG_NETUTILS_DHCPC=y``: Enables the DHCP client
|
|
|
|
Networking Support
|
|
|
|
* ``CONFIG_NET_UDP=y``: Depends on broadcast UDP
|
|
|
|
Application Configuration -> NSH Library
|
|
|
|
* ``CONFIG_NET_BROADCAST=y``
|
|
* ``CONFIG_NSH_DHCPC=y``: Tells NSH to use DHCPC, not the fixed addresses
|
|
|
|
Using the network with NSH
|
|
--------------------------
|
|
|
|
So what can you do with this networking support? First you see that NSH has
|
|
several new network related commands:
|
|
|
|
* ``ifconfig``, ``ifdown``, ``ifup``: Commands to help manage your network
|
|
* ``get`` and ``put``: TFTP file transfers
|
|
* ``wget``: HTML file transfers
|
|
* ``ping``: Check for access to peers on the network
|
|
* Telnet console: You can access the NSH remotely via telnet.
|
|
|
|
You can also enable other add on features like full FTP or a Web Server or XML
|
|
RPC and others. There are also other features that you can enable like DHCP
|
|
client (or server) or network name resolution.
|
|
|
|
By default, the IP address of the SAM4E-EK will be ``10.0.0.2`` and it will
|
|
assume that your host is the gateway and has the IP address ``10.0.0.1``.
|
|
|
|
.. code:: console
|
|
|
|
nsh> ifconfig
|
|
eth0 HWaddr 00:e0:de:ad:be:ef at UP
|
|
IPaddr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0
|
|
|
|
You can use ping to test for connectivity to the host (Careful, Window firewalls
|
|
usually block ping-related ICMP traffic). On the target side, you can:
|
|
|
|
.. code:: console
|
|
|
|
nsh> ping 10.0.0.1
|
|
PING 10.0.0.1 56 bytes of data
|
|
56 bytes from 10.0.0.1: icmp_seq=1 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=2 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=3 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=4 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=5 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=6 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=7 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=8 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=9 time=0 ms
|
|
56 bytes from 10.0.0.1: icmp_seq=10 time=0 ms
|
|
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
|
|
|
|
|
|
.. note::
|
|
|
|
In this configuration is is normal to have packet loss > 0% the first time
|
|
you ping due to the default handling of the ARP
|
|
table.
|
|
|
|
On the host side, you should also be able to ping the SAM4E-EK:
|
|
|
|
.. code:: console
|
|
|
|
$ ping 10.0.0.2
|
|
|
|
You can also log into the NSH from the host PC like this:
|
|
|
|
.. code:: console
|
|
|
|
$ telnet 10.0.0.2
|
|
Trying 10.0.0.2...
|
|
Connected to 10.0.0.2.
|
|
Escape character is '^]'.
|
|
sh_telnetmain: Session [3] Started
|
|
|
|
NuttShell (NSH) NuttX-6.31
|
|
nsh> help
|
|
help usage: help [-v] [<cmd>]
|
|
|
|
[ echo ifconfig mkdir mw sleep
|
|
? exec ifdown mkfatfs ping test
|
|
cat exit ifup mkfifo ps umount
|
|
cp free kill mkrd put usleep
|
|
cmp get losetup mh rm wget
|
|
dd help ls mount rmdir xd
|
|
df hexdump mb mv source
|
|
|
|
Builtin Apps:
|
|
nsh>
|
|
|
|
.. note::
|
|
|
|
If you enable this feature, you experience a delay on booting. That is
|
|
because the start-up logic waits for the network connection to be established
|
|
before starting NuttX. In a real application, you would probably want to do
|
|
the network bringup on a separate thread so that access to the NSH prompt is
|
|
not delayed.
|
|
|
|
This delay will be especially long if the board is not connected to a network
|
|
because additional time will be required to fail with timeout errors.
|
|
|
|
This delay will be especially long if the board is not connected to a
|
|
network. On the order of a minute! You will probably think that NuttX has
|
|
crashed! And then, when it finally does come up, the network will not be
|
|
available.
|
|
|
|
Network Initialization Thread
|
|
-----------------------------
|
|
|
|
There is a configuration option enabled by ``CONFIG_NSH_NETINIT_THREAD`` that
|
|
will do the NSH network bring-up asynchronously in parallel on a separate
|
|
thread. This eliminates the (visible) networking delay altogether. This current
|
|
implementation, however, has some limitations:
|
|
|
|
* If no network is connected, the network bring-up will fail and the network
|
|
initialization thread will simply exit. There are no retries and no
|
|
mechanism to know if the network initialization was successful (it could
|
|
perform a network Ioctl to see if the link is up and it now, keep trying,
|
|
but it does not do that now).
|
|
|
|
* Furthermore, there is currently no support for detecting loss of network
|
|
connection and recovery of the connection (similarly, this thread could poll
|
|
periodically for network status, but does not).
|
|
|
|
Both of these shortcomings could be eliminated by enabling the network
|
|
monitor. See the SAMA5 configurations for a description of what it would
|
|
take to incorporate the network monitor feature.
|
|
|
|
AT25 Serial FLASH
|
|
=================
|
|
|
|
Connections
|
|
-----------
|
|
|
|
Both the SAM4E-EK include an Atmel AT25DF321A, 32-megabit, 2.7-volt
|
|
SPI serial flash. The SPI
|
|
connection is as follows:
|
|
|
|
====== ======= ===============
|
|
SAM4E AT25 SAM4E
|
|
GPIO PIN FUNCTION
|
|
====== ======= ===============
|
|
PA13 SI MOSI
|
|
PA12 SO MIS0
|
|
PA14 SCK SPCK
|
|
PA5 /CS NPCS3 (pulled high externally)
|
|
====== ======= ===============
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
Support for the serial FLASH can be enabled in these configurations. These are
|
|
the relevant configuration settings. These settings (1) Enable SPI0, (2) Enable
|
|
DMAC0 to support DMA transfers on SPI for best performance, (3) Enable the AT25
|
|
Serial FLASH, and (3) Set up NuttX to configure the file system on the AT25
|
|
FLASH:
|
|
|
|
System Type -> ATSAM3/4 Peripheral Support
|
|
|
|
* ``CONFIG_SAM34_SPI0=y``: Enable SPI0
|
|
* ``CONFIG_SAM34_DMAC0=y``: Enable DMA controller 0
|
|
|
|
System Type -> SPI device driver options
|
|
|
|
* ``CONFIG_SAM34_SPI_DMA=y``: Use DMA for SPI transfers
|
|
* ``CONFIG_SAM34_SPI_DMATHRESHOLD=4``: Don't DMA for small transfers
|
|
|
|
Device Drivers -> SPI Driver Support
|
|
|
|
* ``CONFIG_SPI=y``: Enable SPI support
|
|
* ``CONFIG_SPI_EXCHANGE=y``: Support the exchange method
|
|
|
|
Device Drivers -> Memory Technology Device (MTD) Support
|
|
|
|
* ``CONFIG_MTD=y``: Enable MTD support
|
|
* ``CONFIG_MTD_AT25=y``: Enable the AT25 driver
|
|
* ``CONFIG_AT25_SPIMODE=0``: Use SPI mode 0
|
|
* ``CONFIG_AT25_SPIFREQUENCY=20000000``: Use SPI frequency 12MHz
|
|
|
|
The AT25 is capable of operation at 20MHz. However, if you experience any
|
|
issues with the AT25, then lower this frequency may give more predictable
|
|
performance.
|
|
|
|
File Systems -> FAT
|
|
|
|
* ``CONFIG_FS_FAT=y``: Enable and configure FAT
|
|
* ``CONFIG_FAT_LCNAMES=y``: Upper/lower case names
|
|
* ``CONFIG_FAT_LFN=y``: Long file name support (See NOTE)
|
|
* ``CONFIG_FAT_MAXFNAME=32``: Limit filename sizes to 32 bytes
|
|
|
|
.. warning::
|
|
|
|
Use care if you plan to use FAT long file name feature in a product; There
|
|
are issues with certain Microsoft patents on the long file name technology.
|
|
|
|
Board Selection
|
|
|
|
* ``CONFIG_SAM4EEK_AT25_BLOCKMOUNT=y``: Mounts AT25 for NSH
|
|
* ``CONFIG_SAM4EEK_AT25_FTL=y``: Create block driver for FAT
|
|
|
|
You can then format the AT25 FLASH for a FAT file system and mount the
|
|
file system at ``/mnt/at25`` using these NSH commands:
|
|
|
|
.. code:: console
|
|
|
|
nsh> mkfatfs /dev/mtdblock0
|
|
nsh> mount -t vfat /dev/mtdblock0 /mnt/at25
|
|
|
|
Then you an use the FLASH as a normal FAT file system:
|
|
|
|
.. code:: console
|
|
|
|
nsh> echo "This is a test" >/mnt/at25/atest.txt
|
|
nsh> ls -l /mnt/at25
|
|
/mnt/at25:
|
|
-rw-rw-rw- 16 atest.txt
|
|
nsh> cat /mnt/at25/atest.txt
|
|
This is a test
|
|
|
|
USB Full-Speed Device
|
|
=====================
|
|
|
|
Basic USB Full-Speed Device Configuration
|
|
-----------------------------------------
|
|
|
|
Support the USB full-speed device (UDP) driver can be enabled with these NuttX
|
|
configuration settings.
|
|
|
|
Device Drivers -> USB Device Driver Support
|
|
|
|
* ``CONFIG_USBDEV=y``: Enable USB device support
|
|
* ``CONFIG_USBDEV_DUALSPEED=n``: Device does not support High-Speed
|
|
* ``CONFIG_USBDEV_DMA=n``: Device does not use DMA
|
|
|
|
System Type -> ATSAM3/4 Peripheral Support
|
|
|
|
* ``CONFIG_SAM34_UDP=y``: Enable UDP Full Speed USB device
|
|
|
|
Mass Storage Class
|
|
------------------
|
|
|
|
The Mass Storage Class (MSC) class driver can be selected for use with UDP.
|
|
Note: The following assumes that the internal AT25 Serial FLASH is configured to
|
|
support a FAT file system through an FTL layer as described about under "AT25
|
|
Serial FLASH".
|
|
|
|
Device Drivers -> USB Device Driver Support
|
|
* ``CONFIG_USBMSC=y``: Enable the USB MSC class driver
|
|
* ``CONFIG_USBMSC_EPBULKOUT=1``: Use EP1 for the BULK OUT endpoint
|
|
* ``CONFIG_USBMSC_EPBULKIN=2``: Use EP2 for the BULK IN endpoint
|
|
* ``CONFIG_USBMSC_BULKINREQLEN=64``: (Defaults for full speed)
|
|
* ``CONFIG_USBMSC_BULKOUTREQLEN=64``
|
|
|
|
Defaults for other settings as well?
|
|
|
|
Board Selection
|
|
|
|
* ``CONFIG_SAM4EEK_AT25_BLOCKDEVICE=y``: Export AT25 serial FLASH device
|
|
* ``CONFIG_SAM4EEK_HSMCI_BLOCKDEVICE=n``: Don't export HSMCI SD card
|
|
|
|
.. note::
|
|
|
|
If properly configured, you could export the HSMCI SD card instead of the
|
|
internal AT25 Serial FLASH.
|
|
|
|
The following setting enables an add-on that can can be used to control
|
|
the USB MSC device. It will add two new NSH commands:
|
|
|
|
1. msconn will connect the USB serial device and export the AT25 to the host,
|
|
and
|
|
2. msdis which will disconnect the USB serial device.
|
|
|
|
Application Configuration -> System Add-Ons:
|
|
|
|
* ``CONFIG_SYSTEM_USBMSC=y``: Enable the USBMSC add-on
|
|
* ``CONFIG_SYSTEM_USBMSC_NLUNS=1``: One LUN
|
|
* ``CONFIG_SYSTEM_USBMSC_DEVMINOR1=0``: Minor device zero
|
|
* ``CONFIG_SYSTEM_USBMSC_DEVPATH1="/dev/mtdblock0"`` : Use a single, LUN; the AT25 block driver.
|
|
|
|
1. To prevent file system corruption, make sure that the AT25 is un-
|
|
mounted *before* exporting the mass storage device to the host:
|
|
|
|
.. code:: console
|
|
|
|
nsh> umount /mnt/at25
|
|
nsh> mscon
|
|
|
|
The AT25 can be re-mounted after the mass storage class is disconnected:
|
|
|
|
.. code:: console
|
|
|
|
nsh> msdis
|
|
nsh> mount -t vfat /dev/mtdblock0 /mnt/at25
|
|
|
|
2. If you change the value ``CONFIG_SYSTEM_USBMSC_DEVPATH1``, then you can
|
|
export other file systems:
|
|
|
|
``/dev/mmcsd0`` would export the HSMCI SD slot (not currently available, see
|
|
the "HSMCI" section).
|
|
|
|
``/dev/ram0`` could even be used to export a RAM disk. But you would first
|
|
have to use mkrd to create the RAM disk and ``mkfatfs`` to put a FAT file
|
|
system on it.
|
|
|
|
.. warning::
|
|
|
|
Marginally functional. Very slow to come up. USB analyzer shows several
|
|
resets before the host decides that it is happy with the device. There are
|
|
no obvious errors in the USB data capture. Testing is insufficient. This
|
|
needs to be revisited.
|
|
|
|
Last tested at 96MHz with the CMCC disabled.
|
|
|
|
CDC/ACM Serial Device Class
|
|
---------------------------
|
|
|
|
This will select the CDC/ACM serial device. Defaults for the other options
|
|
should be okay.
|
|
|
|
Device Drivers -> USB Device Driver Support
|
|
|
|
* ``CONFIG_CDCACM=y``: Enable the CDC/ACM device
|
|
* ``CONFIG_CDCACM_EPINTIN=1``: Select endpoint numbers
|
|
* ``CONFIG_CDCACM_EPBULKOUT=2``
|
|
* ``CONFIG_CDCACM_EPBULKIN=3``
|
|
|
|
The following setting enables an example that can can be used to control
|
|
the CDC/ACM device. It will add two new NSH commands:
|
|
|
|
1. ``sercon`` will connect the USB serial device (creating ``/dev/ttyACM0``),
|
|
and
|
|
2. ``serdis`` which will disconnect the USB serial device (destroying
|
|
``/dev/ttyACM0``).
|
|
|
|
Application Configuration -> Examples:
|
|
|
|
* ``CONFIG_SYSTEM_CDCACM=y``: Enable an CDC/ACM example
|
|
* ``CONFIG_SYSTEM_CDCACM_DEVMINOR=0``: Use ``/dev/ttyUSB0``
|
|
|
|
1. You cannot have both the CDC/ACM and the MSC class drivers enabled
|
|
simultaneously in the way described here. If you want to use both, then
|
|
you will need to consider a USB "composite" devices that support supports
|
|
both interfaces. There are no instructures here for setting up the USB
|
|
composite device, but there are other examples in the NuttX board support
|
|
directories that can be used for reference.
|
|
|
|
2. Linux supports the CDC/ACM driver out of the box. Windows, on the other
|
|
than requires that you first install a serial driver (a .inf file).
|
|
|
|
3. There is hand-shaking to pace incoming serial data. As a result, you may
|
|
experience data loss due to RX overrun errors. The overrun errors occur
|
|
when more data is received than can be buffered in memory on the target.
|
|
|
|
At present, the only workaround is to increase the amount of buffering
|
|
in the target. That allow the target to accept short bursts of larger
|
|
volumes of data (but would still fail on sustained, high speed incoming
|
|
data. The following configuration options can be changed to increase
|
|
the buffering.
|
|
|
|
1. RX buffer size. All incoming data is buffered by the serial driver
|
|
until it can be read by the application. The default size of this
|
|
RX buffer is only 256 but can be increased as you see fit:
|
|
|
|
* ``CONFIG_CDCACM_RXBUFSIZE=256``: Default RX buffer size is only 256
|
|
bytes
|
|
|
|
2. Upstream from the RX buffers are USB read request buffers. Each
|
|
buffer is the maximum size of one USB packet (64 byte) and that cannot
|
|
really be changed. But if you want to increase this upstream buffering
|
|
capability, you can increase the number of available read requests.
|
|
The default is four, providing an additional buffering capability of
|
|
of 4*64=256 bytes.
|
|
|
|
Each read request receives data from USB, copies the data into the
|
|
serial RX buffer, and then is available to receive more data. This
|
|
recycling of read requests stalls as soon as the serial RX buffer is
|
|
full. Data loss occurs when there are no available read requests to
|
|
accept the next packet from the host. So increasing the number of
|
|
read requests can also help to minimize RX overrun:
|
|
|
|
* ``CONFIG_CDCACM_NRDREQS=4``: Default is only 4 read requests
|
|
|
|
Debugging USB Device
|
|
--------------------
|
|
|
|
There is normal console debug output available that can be enabled with
|
|
``CONFIG_DEBUG_FEATURES`` + ``CONFIG_DEBUG_USB``. However, USB device operation
|
|
is very time critical and enabling this debug output WILL interfere with the
|
|
operation of the UDP. USB device tracing is a less invasive way to get debug
|
|
information: If tracing is enabled, the USB device will save encoded trace
|
|
output in in-memory buffer; if the USB monitor is also enabled, that trace
|
|
buffer will be periodically emptied and dumped to the system logging device (the
|
|
serial console in this configuration):
|
|
|
|
Device Drivers -> "USB Device Driver Support:
|
|
|
|
* ``CONFIG_USBDEV_TRACE=y``: Enable USB trace feature
|
|
* ``CONFIG_USBDEV_TRACE_NRECORDS=256``: Buffer 256 records in memory
|
|
* ``CONFIG_USBDEV_TRACE_STRINGS=y``: (optional)
|
|
|
|
If you get data loss in the trace buffer, then you may want to increase the
|
|
``CONFIG_USBDEV_TRACE_NRECORDS``. I have used buffers up to 4096 records to
|
|
avoid data loss.
|
|
|
|
Application Configuration -> NSH LIbrary:
|
|
|
|
* ``CONFIG_NSH_USBDEV_TRACE=n``: No builtin tracing from NSH
|
|
|
|
Application Configuration -> System NSH Add-Ons:
|
|
|
|
* ``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=1``: Dump trace data every second
|
|
* ``CONFIG_USBMONITOR_TRACEINIT=y``: Enable TRACE output
|
|
* ``CONFIG_USBMONITOR_TRACECLASS=y``
|
|
* ``CONFIG_USBMONITOR_TRACETRANSFERS=y``
|
|
* ``CONFIG_USBMONITOR_TRACECONTROLLER=y``
|
|
* ``CONFIG_USBMONITOR_TRACEINTERRUPTS=y``
|
|
|
|
.. note::
|
|
|
|
If USB debug output is also enabled, both outputs will appear on the serial
|
|
console. However, the debug output will be asynchronous with the trace
|
|
output and, hence, difficult to interpret.
|
|
|
|
HSMCI
|
|
=====
|
|
|
|
Enabling HSMCI support. The SAM3U-KE provides a an SD memory card slot. Support
|
|
for the SD slot can be enabled with the following settings:
|
|
|
|
System Type->ATSAM3/4 Peripheral Support
|
|
|
|
* ``CONFIG_SAM34_HSMCI=y``: Enable HSMCI support
|
|
* ``CONFIG_SAM34_DMAC0=y``: DMAC support is needed by HSMCI
|
|
|
|
System Type
|
|
|
|
* ``CONFIG_SAM34_GPIO_IRQ=y``: PIO interrupts needed
|
|
* ``CONFIG_SAM34_GPIOA_IRQ=y``: Card detect pin is on PIOA
|
|
|
|
Device Drivers -> MMC/SD Driver Support
|
|
|
|
* ``CONFIG_MMCSD=y``: Enable MMC/SD support
|
|
* ``CONFIG_MMCSD_NSLOTS=1``: One slot per driver instance
|
|
* ``CONFIG_MMCSD_HAVE_CARDDETECT=y``: Supports card-detect PIOs
|
|
* ``CONFIG_MMCSD_SDIO=y``: SDIO-based MMC/SD support
|
|
* ``CONFIG_MMCSD_MULTIBLOCK_LIMIT=1``: Probably works but is untested
|
|
* ``CONFIG_SDIO_DMA=y``: Use SDIO DMA
|
|
* ``CONFIG_SDIO_BLOCKSETUP=y``: Needs to know block sizes
|
|
|
|
Library Routines
|
|
|
|
* ``CONFIG_SCHED_WORKQUEUE=y``: Driver needs work queue support
|
|
|
|
Defaults for other settings okay
|
|
|
|
Application Configuration -> NSH Library
|
|
|
|
* ``CONFIG_NSH_MMCSDSLOTNO=0``: Only one slot, slot 0
|
|
|
|
After an SD card is successfully initialized, the block device ``/dev/mmcsd0``
|
|
will be available. To mount the SD card, use the following NSH command:
|
|
|
|
.. code:: console
|
|
|
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard
|
|
|
|
The SD card contents will then be available under ``/mnt/sdcard``.
|
|
|
|
DMA is not currently functional and without DMA, there may not be reliable data
|
|
transfers at high speeds due to data overrun problems. The current HSMCI driver
|
|
supports DMA via the DMAC. However, the data sheet only discusses PDC-based
|
|
HSMCI DMA (although there is a DMA channel interface definition for HSMCI).
|
|
|
|
.. warning::
|
|
|
|
Bottom line: Untested and probably not usable on the SAM4E-EK in its current
|
|
form.
|
|
|
|
Touchscreen
|
|
===========
|
|
|
|
The NSH configuration can be used to verify the ADS7843E touchscreen on the
|
|
SAM4E-EK LCD. With these modifications, you can include the touchscreen test
|
|
program at ``apps/examples/touchscreen`` as an NSH built-in application. You can
|
|
enable the touchscreen and test by modifying the default configuration in the
|
|
following ways:
|
|
|
|
Device Drivers
|
|
|
|
* ``CONFIG_SPI=y``: Enable SPI support
|
|
* ``CONFIG_SPI_EXCHANGE=y``: The exchange() method is supported
|
|
* ``CONFIG_INPUT=y``: Enable support for input devices
|
|
* ``CONFIG_INPUT_ADS7843E=y``: Enable support for the ADS7843E
|
|
* ``CONFIG_ADS7843E_SPIDEV=0``: Use SPI CS 0 for communication
|
|
* ``CONFIG_ADS7843E_SPIMODE=0``: Use SPI mode 0
|
|
* ``CONFIG_ADS7843E_FREQUENCY=1000000``: SPI BAUD 1MHz
|
|
* ``CONFIG_ADS7843E_SWAPXY=y``: If landscape orientation
|
|
* ``CONFIG_ADS7843E_THRESHX=51``: These will probably need to be tuned
|
|
* ``CONFIG_ADS7843E_THRESHY=39``
|
|
|
|
System Type -> Peripherals:
|
|
|
|
* ``CONFIG_SAM34_SPI0=y``: Enable support for SPI
|
|
|
|
System Type:
|
|
|
|
* ``CONFIG_SAM34_GPIO_IRQ=y``: GPIO interrupt support
|
|
* ``CONFIG_SAM34_GPIOA_IRQ=y``: Enable GPIO interrupts from port A
|
|
|
|
Library Support:
|
|
|
|
* ``CONFIG_SCHED_WORKQUEUE=y``: Work queue support required
|
|
|
|
Application Configuration:
|
|
|
|
* ``CONFIG_EXAMPLES_TOUCHSCREEN=y``: Enable the touchscreen built-in test
|
|
|
|
Defaults should be okay for related touchscreen settings. Touchscreen debug
|
|
output on UART0 can be enabled with:
|
|
|
|
Build Setup:
|
|
|
|
* ``CONFIG_DEBUG_FEATURES=y``: Enable debug features
|
|
* ``CONFIG_DEBUG_INFO=y``: Enable verbose debug output
|
|
* ``CONFIG_DEBUG_INPUT=y``: Enable debug output from input devices
|
|
|
|
ILI9325/41-Based LCD
|
|
====================
|
|
|
|
The SAM4E-EK carries a TFT transmissive LCD module with touch panel,
|
|
FTM280C34D. Its integrated driver IC is either a ILI9325 ILI9342 (the
|
|
original schematics said ILI9325, but I learned the hard way that I had
|
|
an ILI9341-based LCD). The LCD display area is 2.8 inches diagonally
|
|
measured, with a native resolution of 240 x 320
|
|
dots.
|
|
|
|
Connectivity
|
|
------------
|
|
|
|
The SAM4E16 communicates with the LCD through PIOC where an 8-bit parallel
|
|
"8080-like" protocol data bus has to be implemented in software.
|
|
|
|
==== ====== ========= ====================================================
|
|
PIN PIO SIGNAL NOTES
|
|
==== ====== ========= ====================================================
|
|
1 VDD
|
|
2 PC7 DB17
|
|
3 PC6 DB16
|
|
4 PC5 DB15
|
|
5 PC4 DB14
|
|
6 PC3 DB13
|
|
7 PC2 DB12
|
|
8 PC1 DB11
|
|
9 PC0 DB10
|
|
10 DB9 Pulled low
|
|
11 DB8 Pulled low
|
|
12 DB7 Pulled low
|
|
13 DB6 Pulled low
|
|
14 DB5 Pulled low
|
|
15 DB4 Pulled low
|
|
16 DB3 Pulled low
|
|
17 DB2 Pulled low
|
|
18 DB1 Pulled low
|
|
19 DB0 Pulled low
|
|
20 VDD
|
|
21 PC11 RD
|
|
22 PC8 WR
|
|
23 PC19 RS
|
|
24 PD18 CS Via J8, pulled high.
|
|
25 RESET Connects to NSRST
|
|
26 IM0 Pulled high
|
|
27 IM1 Grounded
|
|
28 GND
|
|
29 [PC13] LED-A Backlight controls: PC13 enables AAT3155 charge pump that drives the backlight LEDs
|
|
30 [PC13] LEDK1
|
|
31 [PC13] LEDK2
|
|
32 [PC13] LEDK3
|
|
33 [PC13] LEDK4
|
|
34 [PC13] LEDK1
|
|
35 Y+ These go to the ADS7843 touchscreen controller.
|
|
36 Y-
|
|
37 X+
|
|
38 X-
|
|
39 NC
|
|
==== ====== ========= ====================================================
|
|
|
|
Jumpers
|
|
-------
|
|
|
|
Make sure the JP8 is closed. This connects PD18 as the LCD CS.
|
|
|
|
Backlight
|
|
---------
|
|
|
|
LCD backlight is made of 4 white chip LEDs in parallel, driven by an AAT3155
|
|
charge pump, MN4. The AAT3155 is controlled by the SAM3U4E through a single line
|
|
Simple Serial Control (S2Cwire) interface, which permits to enable, disable, and
|
|
set the LED drive current (LED brightness control) from a 32-level logarithmic
|
|
scale. Four resistors R93/R94/R95/R96 are implemented for optional current
|
|
limitation.
|
|
|
|
Configuration Options
|
|
---------------------
|
|
|
|
This is the basic configuration that enables the ILI9341-based LCD.
|
|
Of course additional settings would be necessary to enable the graphic
|
|
capabilities to do anything with the LCD.
|
|
|
|
System Type -> AT91SAM3/4 Configuration Options
|
|
|
|
* ``CONFIG_SAM34_SMC=y``: SMC support
|
|
|
|
Device Drivers -> LCD Driver Support
|
|
|
|
* ``CONFIG_LCD=y``: Enable LCD support
|
|
* ``CONFIG_LCD_MAXCONTRAST=1``: Value should not matter
|
|
* ``CONFIG_LCD_MAXPOWER=64``: Must be > 16
|
|
* ``CONFIG_LCD_LANDSCAPE=y``: Landscape orientation
|
|
|
|
Board Selection
|
|
|
|
* ``CONFIG_SAM4EEK_LCD_ILI9341=y``: For the ILI9341-based LCD
|
|
* ``CONFIG_SAM4EEK_LCD_RGB565=y``: Color resolution
|
|
* ``CONFIG_SAM4EEK_LCD_BGCOLOR=0x00``: Initial background color
|
|
|
|
.. warning::
|
|
|
|
2014-8-20: Updated. The ILI9341 LCD has some basic functionality. Certainly
|
|
it can transfer and display data fine. But there are some issues with the
|
|
geometry of data that appears on the LCD..
|
|
|
|
The LCD backlight is functional.
|
|
|
|
SAM4E-EK-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_CORTEXM3=y``
|
|
|
|
* ``CONFIG_ARCH_CHIP``: Identifies the ``arch/*/chip`` subdirectory
|
|
|
|
* ``CONFIG_ARCH_CHIP="sam34"``
|
|
|
|
* ``CONFIG_ARCH_CHIP_name``: For use in C code to identify the exact chip:
|
|
|
|
* ``CONFIG_ARCH_CHIP_SAM34``
|
|
* ``CONFIG_ARCH_CHIP_SAM3U``
|
|
* ``CONFIG_ARCH_CHIP_ATSAM3U4``
|
|
|
|
* ``CONFIG_ARCH_BOARD``: Identifies the ``boards/`` subdirectory and hence, the
|
|
board that supports the particular chip or SoC.
|
|
|
|
* ``CONFIG_ARCH_BOARD=sam4e:ek`` (for the SAM4E-EK development board)
|
|
|
|
* ``CONFIG_ARCH_BOARD_name``: For use in C code
|
|
|
|
* ``CONFIG_ARCH_BOARD_SAM4EEK=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=0x00020000`` (128Kb)
|
|
|
|
* ``CONFIG_RAM_START``: The start address of installed DRAM
|
|
|
|
* ``CONFIG_RAM_START=0x20000000``
|
|
|
|
* ``CONFIG_ARCH_LEDS``: Use LEDs to show state. Unique to boards that have LEDs
|
|
|
|
* ``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:
|
|
|
|
* ``CONFIG_SAM34_SPI0``: Serial Peripheral Interface 0 (SPI0)
|
|
* ``CONFIG_SAM34_SPI1``: Serial Peripheral Interface 1 (SPI1)
|
|
* ``CONFIG_SAM34_SSC``: Synchronous Serial Controller (SSC)
|
|
* ``CONFIG_SAM34_TC0``: Timer/Counter 0 (TC0)
|
|
* ``CONFIG_SAM34_TC1``: Timer/Counter 1 (TC1)
|
|
* ``CONFIG_SAM34_TC2``: Timer/Counter 2 (TC2)
|
|
* ``CONFIG_SAM34_TC3``: Timer/Counter 3 (TC3)
|
|
* ``CONFIG_SAM34_TC4``: Timer/Counter 4 (TC4)
|
|
* ``CONFIG_SAM34_TC5``: Timer/Counter 5 (TC5)
|
|
* ``CONFIG_SAM34_TC6``: Timer/Counter 6 (TC6)
|
|
* ``CONFIG_SAM34_TC7``: Timer/Counter 7 (TC6)
|
|
* ``CONFIG_SAM34_TC8``: Timer/Counter 6 (TC8)
|
|
* ``CONFIG_SAM34_PWM``: Pulse Width Modulation (PWM) Controller
|
|
* ``CONFIG_SAM34_TWIM0``: Two-wire Master Interface 0 (TWIM0)
|
|
* ``CONFIG_SAM34_TWIS0``: Two-wire Slave Interface 0 (TWIS0)
|
|
* ``CONFIG_SAM34_TWIM1B``: Two-wire Master Interface 1 (TWIM1)
|
|
* ``CONFIG_SAM34_TWIS1``: Two-wire Slave Interface 1 (TWIS1)
|
|
* ``CONFIG_SAM34_UART0``: UART 0
|
|
* ``CONFIG_SAM34_UART1``: UART 1
|
|
* ``CONFIG_SAM34_USART0``: USART 0
|
|
* ``CONFIG_SAM34_USART1``: USART 1
|
|
* ``CONFIG_SAM34_USART2``: USART 2
|
|
* ``CONFIG_SAM34_USART3``: USART 3
|
|
* ``CONFIG_SAM34_AFEC0``: Analog Front End 0
|
|
* ``CONFIG_SAM34_AFEC1``: Analog Front End 1
|
|
* ``CONFIG_SAM34_DACC``: Digital-to-Analog Converter
|
|
* ``CONFIG_SAM34_ACC``: Analog Comparator
|
|
* ``CONFIG_SAM34_EMAC``: Ethernet MAC
|
|
* ``CONFIG_SAM34_CAN0``: CAN 0
|
|
* ``CONFIG_SAM34_CAN1``: CAN 1
|
|
* ``CONFIG_SAM34_SMC``: Static Memory Controller
|
|
* ``CONFIG_SAM34_NAND``: NAND support
|
|
* ``CONFIG_SAM34_PDCA``: Peripheral DMA controller
|
|
* ``CONFIG_SAM34_DMAC0``: DMA controller
|
|
* ``CONFIG_SAM34_UDP``: USB 2.0 Full-Speed device
|
|
* ``CONFIG_SAM34_CHIPID``: Chip ID
|
|
* ``CONFIG_SAM34_RTC``: Real Time Clock
|
|
* ``CONFIG_SAM34_RTT``: Real Time Timer
|
|
* ``CONFIG_SAM34_WDT``: Watchdog Timer
|
|
* ``CONFIG_SAM34_EIC``: Interrupt controller
|
|
* ``CONFIG_SAM34_HSMCI``: High Speed Multimedia Card Interface
|
|
|
|
Some subsystems can be configured to operate in different ways. The drivers need
|
|
to know how to configure the subsystem.
|
|
|
|
* ``CONFIG_SAM34_GPIOA_IRQ``
|
|
* ``CONFIG_SAM34_GPIOB_IRQ``
|
|
* ``CONFIG_SAM34_GPIOC_IRQ``
|
|
* ``CONFIG_SAM34_GPIOD_IRQ``
|
|
* ``CONFIG_SAM34_GPIOE_IRQ``
|
|
* ``CONFIG_SAM34_GPIOF_IRQ``
|
|
* ``CONFIG_SAM34_GPIOG_IRQ``
|
|
* ``CONFIG_SAM34_GPIOH_IRQ``
|
|
* ``CONFIG_SAM34_GPIOJ_IRQ``
|
|
* ``CONFIG_SAM34_GPIOK_IRQ``
|
|
* ``CONFIG_SAM34_GPIOL_IRQ``
|
|
* ``CONFIG_SAM34_GPIOM_IRQ``
|
|
* ``CONFIG_SAM34_GPION_IRQ``
|
|
* ``CONFIG_SAM34_GPIOP_IRQ``
|
|
* ``CONFIG_SAM34_GPIOQ_IRQ``
|
|
|
|
* ``CONFIG_USART0_SERIALDRIVER``
|
|
* ``CONFIG_USART1_SERIALDRIVER``
|
|
* ``CONFIG_USART2_SERIALDRIVER``
|
|
* ``CONFIG_USART3_SERIALDRIVER``
|
|
|
|
SAM3U specific device driver settings
|
|
|
|
* ``CONFIG_U[S]ARTn_SERIAL_CONSOLE``: selects the USARTn (n=0,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
|
|
|
|
LCD Options. Other than the standard LCD configuration options (see
|
|
boards/README.txt), the SAM4E-EK driver also supports:
|
|
|
|
* ``CONFIG_LCD_LANDSCAPE``: Define for 320x240 display "landscape" support.
|
|
Default is this 320x240 "landscape" orientation
|
|
* ``CONFIG_LCD_RLANDSCAPE``: Define for 320x240 display "reverse landscape"
|
|
support.
|
|
* ``CONFIG_LCD_PORTRAIT``: Define for 240x320 display "portrait" orientation
|
|
support.
|
|
* ``CONFIG_LCD_RPORTRAIT``: Define for 240x320 display "reverse portrait"
|
|
orientation support.
|
|
|
|
Configurations
|
|
==============
|
|
|
|
Each SAM4E-EK configuration is maintained in a sub-directory and can be selected
|
|
as follows:
|
|
|
|
.. code:: console
|
|
|
|
$ tools/configure.sh sam4e-ek:<subdir>
|
|
|
|
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.
|
|
|
|
.. code:: console
|
|
|
|
$ make
|
|
|
|
The ``<subdir>`` that is provided above as an argument to the
|
|
``tools/configure.sh`` must be is one of the following.
|
|
|
|
1. These configurations use the mconf-based configuration tool. To change any
|
|
of these 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. Unless stated otherwise, all configurations generate console
|
|
output on UART0 (J3).
|
|
|
|
3. All of these configurations are set up to build under Linux using the
|
|
EABI buildroot toolchain (unless stated otherwise in the description of
|
|
the configuration). That build selection can easily be reconfigured
|
|
using 'make menuconfig'. Here are the relevant current settings:
|
|
|
|
Build Setup:
|
|
|
|
* ``CONFIG_HOST_LINUX=y``: Linux or other pure POSIX invironment
|
|
|
|
System Type -> Toolchain:
|
|
|
|
* ``CONFIG_ARM_TOOLCHAIN_BUILDROOT=y``: Buildroot toolchain
|
|
* ``CONFIG_ARM_TOOLCHAIN_BUILDROOT_OABI=n``: EABI (Not OABI
|
|
|
|
If you want to use the Atmel GCC toolchain, for example, here are the
|
|
steps to do so:
|
|
|
|
Build Setup:
|
|
|
|
* ``CONFIG_HOST_WINDOWS=y``: Windows
|
|
* ``CONFIG_HOST_CYGWIN=y``: Using Cygwin or other POSIX environment
|
|
|
|
System Type -> Toolchain:
|
|
|
|
* ``CONFIG_ARM_TOOLCHAIN_GNU_EABI=y``: General GCC EABI toolchain under windows
|
|
|
|
Library Routines ->
|
|
|
|
* ``CONFIG_ARCH_SIZET_LONG=n``: size_t is an unsigned int, not long
|
|
|
|
This re-configuration should be done before making NuttX or else the
|
|
subsequent ``make`` will fail. If you have already attempted building
|
|
NuttX then you will have to 1) ``make distclean`` to remove the old
|
|
configuration, 2) ``tools/configure.sh sam4e-ek/ksnh`` to start
|
|
with a fresh configuration, and 3) perform the configuration changes
|
|
above.
|
|
|
|
Also, make sure that your PATH variable has the new path to your Atmel tools.
|
|
Try ``which arm-none-eabi-gcc`` to make sure that you are selecting the right
|
|
tool.
|
|
|
|
See also the "NOTE about Windows native toolchains" in the section call "GNU
|
|
Toolchain Options" above.
|
|
|
|
nsh
|
|
---
|
|
|
|
Configures the NuttShell (nsh) located at ``examples/nsh``. The Configuration
|
|
enables both the serial and telnetd NSH interfaces.
|
|
|
|
1. This configuration runs with a CPU clock of 120MHz and with the
|
|
the CMCC enabled. If you disable these, then you must also
|
|
re-calibrate the delay loop.
|
|
|
|
2. Default stack sizes are large and should really be tuned to reduce
|
|
the RAM footprint:
|
|
|
|
.. code:: text
|
|
|
|
CONFIG_ARCH_INTERRUPTSTACK=2048
|
|
CONFIG_IDLETHREAD_STACKSIZE=1024
|
|
CONFIG_INIT_STACKSIZE=2048
|
|
CONFIG_PTHREAD_STACK_DEFAULT=2048
|
|
... and others ...
|
|
|
|
3. NSH built-in applications are supported.
|
|
|
|
Binary Formats:
|
|
|
|
* ``CONFIG_BUILTIN=y``: Enable support for built-in programs
|
|
|
|
Application Configuration:
|
|
|
|
* ``CONFIG_NSH_BUILTIN_APPS=y``: Enable starting apps from NSH command line
|
|
|
|
4. This configuration has the network enabled by default. This can be easily
|
|
disabled or reconfigured (See see the network related configuration settings
|
|
above in the section entitled "Networking").
|
|
|
|
|
|
.. note::
|
|
|
|
In boot-up sequence is very simple in this example; all initialization is
|
|
done sequentially (vs. in parallel) and so you will not see the NSH prompt
|
|
until all initialization is complete. The network bring-up in particular
|
|
will add some delay before the NSH prompt appears. In a real application,
|
|
you would probably want to do the network bringup on a separate thread so
|
|
that access to the NSH prompt is not delayed.
|
|
|
|
This delay will be especially long if the board is not connected to a
|
|
network because additional time will be required to fail with timeout
|
|
errors. This delay can be eliminated, however, if you enable an NSH
|
|
initialization option as described above in a paragraph entitled, "Network
|
|
Initialization Thread."
|
|
|
|
5. This configuration supports a network with fixed IP address. You
|
|
may have to change these settings for your network:
|
|
|
|
* ``CONFIG_NSH_IPADDR=0x0a000002``: IP address: ``10.0.0.2``
|
|
* ``CONFIG_NSH_DRIPADDR=0x0a000001``: Gateway: ``10.0.0.1``
|
|
* ``CONFIG_NSH_NETMASK=0xffffff00``: Netmask: ``255.255.255.0``
|
|
|
|
You can also enable enable the DHCPC client for networks that use dynamically
|
|
assigned address:
|
|
|
|
* ``CONFIG_NETUTILS_DHCPC=y``: Enables the DHCP client
|
|
* ``CONFIG_NET_UDP=y``: Depends on broadcast UDP
|
|
* ``CONFIG_NET_BROADCAST=y``
|
|
* ``CONFIG_NSH_DHCPC=y``: Tells NSH to use DHCPC, not the fixed addresses
|
|
|
|
6. This configuration has the DMA-based SPI0 and AT25 Serial FLASH support
|
|
enabled by default. This can be easily disabled or reconfigured (See see the
|
|
configuration settings and usage notes above in the section entitled "AT25
|
|
Serial FLASH").
|
|
|
|
To mount the AT25 Serial FLASH as a FAT file system:
|
|
|
|
.. code:: console
|
|
|
|
nsh>mount -t vfat /dev/mtdblock0 /mnt/at25
|
|
|
|
7. USB device support is not enabled in this configuration by default.
|
|
To add USB device support to this configuration, see the instructions
|
|
above under "USB Full-Speed Device."
|
|
|
|
8. Enabling HSMCI support. The SAM3U-KE provides a an SD memory card
|
|
slot. Support for the SD slot can be enabled following the
|
|
instructions provided above in the paragraph entitled "HSMCI."
|
|
|
|
9. This configuration has been used for verifying the touchscreen on
|
|
on the SAM4E-EK LCD module.
|
|
|
|
The NSH configuration can be used to verify the ADS7843E touchscreen on
|
|
the SAM4E-EK LCD. With these modifications, you can include the touchscreen
|
|
test program at apps/examples/touchscreen as an NSH built-in application.
|
|
You can enable the touchscreen and test by modifying the default
|
|
configuration in the following ways:
|
|
|
|
Device Drivers
|
|
|
|
* ``CONFIG_SPI=y``: Enable SPI support
|
|
* ``CONFIG_SPI_EXCHANGE=y``: The exchange() method is supported
|
|
* ``CONFIG_INPUT=y``: Enable support for input devices
|
|
* ``CONFIG_INPUT_ADS7843E=y``: Enable support for the ADS7843E
|
|
* ``CONFIG_ADS7843E_SPIDEV=0``: Use SPI CS 0 for communication
|
|
* ``CONFIG_ADS7843E_SPIMODE=0``: Use SPI mode 0
|
|
* ``CONFIG_ADS7843E_FREQUENCY=1000000``: SPI BAUD 1MHz
|
|
* ``CONFIG_ADS7843E_SWAPXY=y``: If landscape orientation
|
|
* ``CONFIG_ADS7843E_THRESHX=51``: These will probably need to be tuned
|
|
* ``CONFIG_ADS7843E_THRESHY=39``
|
|
|
|
System Type -> Peripherals:
|
|
|
|
* ``CONFIG_SAM34_SPI0=y``: Enable support for SPI
|
|
|
|
System Type:
|
|
|
|
* ``CONFIG_SAM34_GPIO_IRQ=y``: GPIO interrupt support
|
|
* ``CONFIG_SAM34_GPIOA_IRQ=y``: Enable GPIO interrupts from port A
|
|
|
|
Library Support:
|
|
|
|
* ``CONFIG_SCHED_WORKQUEUE=y``: Work queue support required
|
|
|
|
Application Configuration:
|
|
|
|
* ``CONFIG_EXAMPLES_TOUCHSCREEN=y``: Enable the touchscreen built-in test
|
|
|
|
Defaults should be okay for related touchscreen settings. Touchscreen debug
|
|
output on UART0 can be enabled with:
|
|
|
|
Build Setup:
|
|
|
|
* ``CONFIG_DEBUG_FEATURES=y``: Enable debug features
|
|
* ``CONFIG_DEBUG_INFO=y``: Enable verbose debug output
|
|
* ``CONFIG_DEBUG_INPUT=y``: Enable debug output from input devices
|
|
|
|
10. This configuration can be re-configured to test the on-board LCD module.
|
|
|
|
System Type -> AT91SAM3/4 Configuration Options
|
|
|
|
* ``CONFIG_SAM34_SMC=y``: SMC support
|
|
|
|
Device Drivers -> LCD Driver Support
|
|
|
|
* ``CONFIG_LCD=y``: Enable LCD support
|
|
* ``CONFIG_LCD_MAXCONTRAST=1``: Value should not matter
|
|
* ``CONFIG_LCD_MAXPOWER=64``: Must be > 16
|
|
* ``CONFIG_LCD_LANDSCAPE=y``: Landscape orientation
|
|
|
|
Board Selection
|
|
|
|
* ``CONFIG_SAM4EEK_LCD_ILI9341=y``: For the ILI9341-based LCD
|
|
* ``CONFIG_SAM4EEK_LCD_RGB565=y``: Color resolution
|
|
* ``CONFIG_SAM4EEK_LCD_BGCOLOR=0x00``: Initial background color
|
|
|
|
Graphics Support
|
|
|
|
* ``CONFIG_NX=y``: Enable Graphics support
|
|
* ``CONFIG_NX_LCDDRIVER=y``: LCD graphics device
|
|
|
|
Graphics Support -> Supported Pixel Depths
|
|
|
|
* ``CONFIG_NX_DISABLE_1BPP=y``: Only 16BPP supported
|
|
* ``CONFIG_NX_DISABLE_2BPP=y``
|
|
* ``CONFIG_NX_DISABLE_4BPP=y``
|
|
* ``CONFIG_NX_DISABLE_8BPP=y``
|
|
* ``CONFIG_NX_DISABLE_24BPP=y``
|
|
* ``CONFIG_NX_DISABLE_32BPP=y``
|
|
|
|
Graphics Support -> Font Selections
|
|
|
|
* ``CONFIG_NXFONTS_CHARBITS=7``
|
|
* ``CONFIG_NXFONT_SANS23X27=y``
|
|
* ``CONFIG_NXFONT_SANS22X29B=y``
|
|
|
|
Application Configuration -> Examples
|
|
|
|
* ``CONFIG_EXAMPLES_NXLINES=y``
|
|
* ``CONFIG_EXAMPLES_NXLINES_BGCOLOR=0x0320``
|
|
* ``CONFIG_EXAMPLES_NXLINES_LINEWIDTH=16``
|
|
* ``CONFIG_EXAMPLES_NXLINES_LINECOLOR=0xffe0``
|
|
* ``CONFIG_EXAMPLES_NXLINES_BORDERWIDTH=4``
|
|
* ``CONFIG_EXAMPLES_NXLINES_BORDERCOLOR=0xffe0``
|
|
* ``CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR=0xf7bb``
|
|
* ``CONFIG_EXAMPLES_NXLINES_BPP=16``
|
|
|
|
.. warning::
|
|
|
|
2014-08-20: The LCD interface is fully implemented and data appears to be
|
|
transferred okay. However, there are errors in geometry that leave the
|
|
LCD unusable still.
|
|
|
|
The LCD backlight appears to be functional.
|
|
|
|
usbnsh
|
|
------
|
|
|
|
This is another NSH example. If differs from the ``nsh`` configuration in that
|
|
this configurations uses a USB serial device for console I/O.
|
|
|
|
1. See the NOTES in the description of the nsh configuration. Those
|
|
notes all apply here as well. Some additional notes unique to
|
|
the USB console version follow:
|
|
|
|
2. The configuration differences between this configuration and the
|
|
nsh configuration is:
|
|
|
|
a. USB device support is enabled as described in the paragraph
|
|
entitled "USB Full-Speed Device",
|
|
|
|
b. The CDC/ACM serial class is enabled as described in the paragraph
|
|
"CDC/ACM Serial Device Class".
|
|
|
|
c. The serial console is disabled:
|
|
|
|
RTOS Features:
|
|
|
|
* ``CONFIG_DEV_CONSOLE=n``: No console at boot time
|
|
|
|
Driver Support -> USB Device Driver Support
|
|
|
|
* ``CONFIG_UART0_SERIAL_CONSOLE=n``: UART0 is not the console
|
|
* ``CONFIG_NO_SERIAL_CONSOLE=y``: There is no serial console
|
|
|
|
Driver Support -> USB Device Driver Support
|
|
|
|
* ``CONFIG_CDCACM_CONSOLE=y``: USB CDC/ACM console
|
|
|
|
d. Support for debug output on UART0 is provided as described in the
|
|
next note.
|
|
|
|
3. If you send large amounts of data to the target, you may see data
|
|
loss due to RX overrun errors. See the NOTES in the section entitled
|
|
"CDC/ACM Serial Device Class" for an explanation and some possible
|
|
work-arounds.
|
|
|
|
3. This configuration does have UART0 output enabled and set up as
|
|
the system logging device:
|
|
|
|
File Systems -> Advanced SYSLOG Features
|
|
|
|
* ``CONFIG_SYSLOG_CHAR=y``: Use a character device for system logging
|
|
* ``CONFIG_SYSLOG_DEVPATH="/dev/ttyS0"``: UART0 will be /dev/ttyS0
|
|
|
|
However, there is nothing to generate SYSLOG output in the default
|
|
configuration so nothing should appear on UART0 unless you enable
|
|
some debug output or enable the USB monitor.
|
|
|
|
.. note::
|
|
|
|
Using the SYSLOG to get debug output has limitations. Among those are
|
|
that you cannot get debug output from interrupt handlers. So, in
|
|
particularly, debug output is not a useful way to debug the USB device
|
|
controller driver. Instead, use the USB monitor with USB debug off and
|
|
USB trace on (see below).
|
|
|
|
4. Enabling USB monitor SYSLOG output. See the paragraph entitle
|
|
"Debugging USB Device" for a summary of the configuration settings
|
|
needed to enable the USB monitor and get USB debug data out UART0.
|
|
|
|
5. By default, this configuration uses the CDC/ACM serial device to
|
|
provide the USB console. This works out-of-the-box for Linux.
|
|
Windows, on the other hand, will require a CDC/ACM device driver
|
|
(.inf file).
|
|
|
|
5. 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=n``: Disable the CDC/ACM serial device class
|
|
* ``CONFIG_CDCACM_CONSOLE=n``: 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
|
|
|
|
nxwm
|
|
----
|
|
|
|
This is a special configuration setup for the NxWM window manager UnitTest. It
|
|
integrates support for both the SAM4E-EK ILI9341 LCDC and the SAM4E-EK ADS7843E
|
|
touchscreen controller and provides a more advanced graphics demo. It provides
|
|
an interactive windowing experience.
|
|
|
|
The NxWM window manager is a tiny window manager tailored for use with smaller
|
|
LCDs. It supports a task, a start window, and multiple application windows with
|
|
toolbars. However, to make the best use of the visible LCD space, only one
|
|
application window is visible at at time.
|
|
|
|
The NxWM window manager can be found at ``apps/graphics/NxWidgets/nxwm``.
|
|
|
|
The NxWM unit test can be found at ``apps/graphics/NxWidgets/UnitTests/nxwm``
|
|
|
|
.. warning::
|
|
|
|
2014-08-20. I have seen the demo work well but it is not thoroughly
|
|
exercised. I suspect some touchscreen issues.
|
|
|
|
2014-10-11. Today's build crashes in nxwm_main on startup.
|