22cd0d47fa
This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU.
The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's.
Squashed commit of the following:
Trivial update to fix some spacing issues.
net/: Rename several macros containing _MTU to _PKTSIZE.
net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes).
net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2667 lines
110 KiB
Plaintext
2667 lines
110 KiB
Plaintext
README
|
|
======
|
|
|
|
This README file discusses the port of NuttX to the Atmel SAM V71 Xplained
|
|
Ultra Evaluation Kit (SAMV71-XULT). This board features the ATSAMV71Q21 Cortex-M7
|
|
microcontroller.
|
|
|
|
Additional support of provided for the (optional) maXTouch Xplained Pro LCD.
|
|
|
|
Contents
|
|
========
|
|
|
|
- Board Features
|
|
- Status/Open Issues
|
|
- Serial Console
|
|
- SD card
|
|
- Automounter
|
|
- LEDs and Buttons
|
|
- AT24MAC402 Serial EEPROM
|
|
- S25FL116K QuadSPI FLASH
|
|
- Program FLASH Access
|
|
- Networking
|
|
- USBHS Device Controller Driver
|
|
- Audio Interface
|
|
- maXTouch Xplained Pro
|
|
- MCAN1 Loopback Test
|
|
- SPI Slave
|
|
- Click Shield
|
|
- Tickless OS
|
|
- Debugging
|
|
- Configurations
|
|
|
|
Board Features
|
|
==============
|
|
|
|
- ATSAMV71Q21 microcontroller: Cortex-M7, 300MHz, 2MiB FLASH, 384KiB SRAM,
|
|
I/D-caches
|
|
- One mechanical reset button
|
|
- One power switch button
|
|
- Two mechanical user pushbuttons
|
|
- Two yellow user LEDs
|
|
- Supercap backup
|
|
- 12.0 MHz crystal
|
|
- 32.768 kHz crystal
|
|
- 2 MB SDRAM
|
|
- 2 MB QSPI Flash
|
|
- IEEE 802.3az 10Base-T/100Base-TX Ethernet RMII PHY
|
|
- AT24MAC402 256KByte EEPROM with EUI-48 address
|
|
- WM8904 stereo audio codec
|
|
- ATA6561 CAN Transceiver
|
|
- SD Card connector with SDIO support
|
|
- Camera interface connector
|
|
- MediaLB connector
|
|
- Two Xplained Pro extension headers
|
|
- One Xplained Pro LCD header
|
|
- Coresight 20 connector for 4-bit ETM
|
|
- Arduino due compatible shield connectors
|
|
- External debugger connector
|
|
- USB interface, device and host mode
|
|
- Embedded Debugger with Data Gateway Interface and Virtual COM port (CDC)
|
|
- External power input (5-14V) or USB powered
|
|
|
|
See the Atmel website for further information about this board:
|
|
|
|
- http://www.atmel.com/tools/atsamv71-xult.aspx
|
|
|
|
Status/Open Issues
|
|
==================
|
|
|
|
I would characterize the general port as very mature and stable. However,
|
|
there are a number of issues, caveats, and unfinished drivers as detailed in
|
|
the following paragraphs.
|
|
|
|
The BASIC nsh configuration is fully function (as described below under
|
|
"Configurations"). There is also a graphics configuration (mxtxplnd), a
|
|
a configuration for network testing (netnsh), a graphics demo (nxwm), and
|
|
a sample protected mode build (knsh). There are still open issues that need
|
|
to be resolved. General problems are listed below. But see the STATUS
|
|
section associated with each configuration for additional issues specific
|
|
to a particular configuration.
|
|
|
|
1. HSCMI. CONFIG_MMCSD_MULTIBLOCK_DISABLE=y is set to disable multi-block
|
|
transfers only because I have not yet had a chance to verify this. The
|
|
is very low priority to me but might be important to you if you are need
|
|
very high performance SD card accesses.
|
|
|
|
2. HSMCI TX DMA is currently disabled for the SAMV7. There is some
|
|
issue with the TX DMA setup. This is a bug that needs to be resolved.
|
|
|
|
DMA is enabled by these settings in the file arch/arm/src/samv7/sam_hsmci.c:
|
|
|
|
#undef HSCMI_NORXDMA /* Define to disable RX DMA */
|
|
#define HSCMI_NOTXDMA 1 /* Define to disable TX DMA */
|
|
|
|
3. There may also be some issues with removing and re-inserting SD cards
|
|
(of course with appropriate mounting and unmounting). I all not sure
|
|
of this and need to do more testing to characterize if the issue.
|
|
|
|
4. There is a port of the SAMA5D4-EK Ethernet driver to the SAMV71-XULT.
|
|
This driver appears to be 100% functional with the following caveats:
|
|
|
|
- There is a compiler optimization issue. At -O2, there is odd
|
|
behavior on pings and ARP messages. But the behavior is OK with
|
|
optimization set to -O2. This may or may not be a compiler
|
|
optimization issue (it could also be a timing issue or a need
|
|
for some additional volatile qualifiers).
|
|
|
|
Update: I have switch toolchains and no longer see this issue. This
|
|
is probably not a driver-related issue.
|
|
|
|
- I- and D-Caches are enabled but the D-Cache must be enabled in
|
|
write-through mode. This is to work around issues with the RX and TX
|
|
descriptors with are 8-bytes in size. But the D-Cache cache line size
|
|
is 32-bytes. That means that you cannot reload, clean or invalidate a
|
|
descriptor without also effecting three neighboring descriptors.
|
|
Setting write through mode eliminates the need for cleaning the D-Cache.
|
|
If only reloading and invalidating are done, then there is no problem.
|
|
|
|
5. The USBHS device controller driver (DCD) is also fully functional. It
|
|
has only be tested with the CDC/ACM driver as described below. Like
|
|
the Ethernet driver:
|
|
|
|
- This driver does not work reliably with the write back D-Cache. The
|
|
write-through D-Cache must be enabled.
|
|
|
|
- As of this writing (2015-08-22), the USBHS only works in full speed
|
|
mode (aka, USBHS Low-Power mode). When configured in normal mode,
|
|
SETUP packets are no longer received or responded to; the firmware
|
|
only detects bus reset events. This is probably some issue with
|
|
480MHZ high speed clock setup, but I have not yet found the issue.
|
|
|
|
6. The full port for audio support is code complete: WM8904 driver,
|
|
SSC/I2C driver, and CS2100-CP driver. But this code is untested. The
|
|
WM8904 interface was taken directly from the SAMA5D4-EK and may well
|
|
need modification due to differences with the physical WM8904
|
|
interface.
|
|
|
|
7. An MCAN driver as added and verified on 2015-08-08 using the loopback
|
|
test at apps/examples/can. Like the Ethernet driver, the MCAN driver
|
|
does not work if the D-Cache is configured in write-back mode; write-
|
|
through mode is required.
|
|
|
|
8. An SPI slave driver as added on 2015-08-09 but has not been verified
|
|
as of this writing. See discussion in include/nuttx/spi/slave.h and
|
|
in the section entitle "SPI Slave" below.
|
|
|
|
9. A QSPI FLASH driver was added and verifed on 2015-11-10. This driver
|
|
operated in the memory mapped Serial Memory Mode (SMM). See the
|
|
"S25FL116K QuadSPI FLASH" section below for futher information.
|
|
|
|
10. On-chip FLASH support as added and verified on 2015-11-13. See the
|
|
"Program FLASH Access" section below for further information.
|
|
|
|
11. The knsh "protected mode" configuration was added on 2015-11-18. The
|
|
configuration has not been tested as of this writing.
|
|
|
|
Serial Console
|
|
==============
|
|
|
|
The SAMV71-XULT has no on-board RS-232 drivers so it will be necessary to
|
|
use either the VCOM or an external RS-232 driver. Here are some options.
|
|
|
|
- Arduino Serial Shield: One option is to use an Arduino-compatible
|
|
serial shield. This will use the RXD and TXD signals available at pins
|
|
0 an 1, respectively, of the Arduino "Digital Low" connector. On the
|
|
SAMV71-XULT board, this corresponds to UART3:
|
|
|
|
------ ------ ------- ------- --------
|
|
Pin on SAMV71 Arduino Arduino SAMV71
|
|
J503 PIO Name Pin Function
|
|
------ ------ ------- ------- --------
|
|
1 PD28 RX0 0 URXD3
|
|
2 PD30 TX0 1 UTXD3
|
|
------ ------ ------- ------- --------
|
|
|
|
In this configuration, an external RS232 driver can also be used
|
|
instead of the shield. Simply connext as follows:
|
|
|
|
--------- -----------
|
|
Arduino RS-232
|
|
Pin Label Connection
|
|
--------- -----------
|
|
D0 (RXD) RX
|
|
D1 (TXD) TX
|
|
GND GND
|
|
5VO Vcc
|
|
--------- -----------
|
|
|
|
- Arduino Communications. Additional UART/USART connections are available
|
|
on the Arduino Communications connection J505:
|
|
|
|
------ ------ ------- ------- --------
|
|
Pin on SAMV71 Arduino Arduino SAMV71
|
|
J503 PIO Name Pin Function
|
|
------ ------ ------- ------- --------
|
|
3 PD18 RX1 0 URXD4
|
|
4 PD19 TX1 0 UTXD4
|
|
5 PD15 RX2 0 RXD2
|
|
6 PD16 TX2 0 TXD2
|
|
7 PB0 RX3 0 RXD0
|
|
8 PB1 TX3 1 TXD0
|
|
------ ------ ------- ------- --------
|
|
|
|
- SAMV7-XULT EXTn connectors. USART pins are also available the EXTn
|
|
connectors. The following are labelled in the User Guide for USART
|
|
functionality:
|
|
|
|
---- -------- ------ --------
|
|
EXT1 EXTI1 SAMV71 SAMV71
|
|
Pin Name PIO Function
|
|
---- -------- ------ --------
|
|
13 USART_RX PB00 RXD0
|
|
14 USART_TX PB01 TXD0
|
|
|
|
---- -------- ------ --------
|
|
EXT2 EXTI2 SAMV71 SAMV71
|
|
Pin Name PIO Function
|
|
---- -------- ------ --------
|
|
13 USART_RX PA21 RXD1
|
|
14 USART_TX PB04 TXD1
|
|
|
|
- VCOM. The Virtual Com Port gateway is available on USART1:
|
|
|
|
------ --------
|
|
SAMV71 SAMV71
|
|
PIO Function
|
|
------ --------
|
|
PB04 TXD1
|
|
PA21 RXD1
|
|
------ --------
|
|
|
|
Any of these options can be selected as the serial console by:
|
|
|
|
1. Enabling the UART/USART peripheral in the
|
|
"System Type -> Peripheral Selection" menu, then
|
|
2. Configuring the peripheral in the "Drivers -> Serial Configuration"
|
|
menu.
|
|
|
|
NOTE: If USART1 is used (TXD1, RXD1), then PB4 must be reconfigured in the
|
|
SUPC. Normally, PB4 is TDI. When it is reconfigured for use with USART1,
|
|
the capability to debug is lost! If you plan to debug you should most
|
|
certainly not use USART1.
|
|
|
|
SD Card
|
|
=======
|
|
|
|
Card Slot
|
|
---------
|
|
The SAM V71 Xplained Ultra has one standard SD card connector which is
|
|
connected to the High Speed Multimedia Card Interface (HSMCI) of the SAM
|
|
V71. SD card connector:
|
|
|
|
------ ----------------- ---------------------
|
|
SAMV71 SAMV71 Shared functionality
|
|
Pin Function
|
|
------ ----------------- ---------------------
|
|
PA30 MCDA0 (DAT0)
|
|
PA31 MCDA1 (DAT1)
|
|
PA26 MCDA2 (DAT2)
|
|
PA27 MCDA3 (DAT3) Camera
|
|
PA25 MCCK (CLK) Shield
|
|
PA28 MCCDA (CMD)
|
|
PD18 Card Detect (C/D) Shield
|
|
------ ----------------- ---------------------
|
|
|
|
Configuration Settings
|
|
----------------------
|
|
Enabling HSMCI support. The SAMV7-XULT provides a one, full-size SD memory card slots. The full size SD card slot connects via HSMCI0. Support for the SD slots can be enabled with the following settings:
|
|
|
|
System Type->SAMV7 Peripheral Selection
|
|
CONFIG_SAMV7_HSMCI0=y : To enable HSMCI0 support
|
|
CONFIG_SAMV7_XDMAC=y : XDMAC is needed by HSMCI0/1
|
|
|
|
System Type
|
|
CONFIG_SAMV7_GPIO_IRQ=y : PIO interrupts needed
|
|
CONFIG_SAMV7_GPIOD_IRQ=y : Card detect pin is on PD18
|
|
|
|
Device Drivers -> MMC/SD Driver Support
|
|
CONFIG_MMCSD=y : Enable MMC/SD support
|
|
CONFIG_MMSCD_NSLOTS=1 : One slot per driver instance
|
|
CONFIG_MMCSD_MULTIBLOCK_DISABLE=y : (REVISIT)
|
|
CONFIG_MMCSD_HAVE_CARDDETECT=y : Supports card-detect PIOs
|
|
CONFIG_MMCSD_MMCSUPPORT=n : Interferes with some SD cards
|
|
CONFIG_MMCSD_SPI=n : No SPI-based MMC/SD support
|
|
CONFIG_MMCSD_SDIO=y : SDIO-based MMC/SD support
|
|
CONFIG_SDIO_DMA=y : Use SDIO DMA
|
|
CONFIG_SDIO_BLOCKSETUP=y : Needs to know block sizes
|
|
|
|
RTOS Features -> Work Queue Support
|
|
CONFIG_SCHED_WORKQUEUE=y : Driver needs work queue support
|
|
|
|
Application Configuration -> NSH Library
|
|
CONFIG_NSH_ARCHINIT=y : NSH board-initialization, OR
|
|
CONFIG_BOARD_INITIALIZE=y
|
|
|
|
Using the SD card
|
|
-----------------
|
|
|
|
1) After booting, the HSCMI device will appear as /dev/mmcsd0.
|
|
|
|
2) If you try mounting an SD card with nothing in the slot, the mount will
|
|
fail:
|
|
|
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sd0
|
|
nsh: mount: mount failed: 19
|
|
|
|
NSH can be configured to provide errors as strings instead of
|
|
numbers. But in this case, only the error number is reported. The
|
|
error numbers can be found in nuttx/include/errno.h:
|
|
|
|
#define ENODEV 19
|
|
#define ENODEV_STR "No such device"
|
|
|
|
So the mount command is saying that there is no device or, more
|
|
correctly, that there is no card in the SD card slot.
|
|
|
|
3) Inserted the SD card. Then the mount should succeed.
|
|
|
|
nsh> mount -t vfat /dev/mmcsd0 /mnt/sd0
|
|
nsh> ls /mnt/sd1
|
|
/mnt/sd1:
|
|
atest.txt
|
|
nsh> cat /mnt/sd1/atest.txt
|
|
This is a test
|
|
|
|
NOTE: See the next section entitled "Auto-Mounter" for another way
|
|
to mount your SD card.
|
|
|
|
4) Before removing the card, you must umount the file system. This is
|
|
equivalent to "ejecting" or "safely removing" the card on Windows: It
|
|
flushes any cached data to an SD card and makes the SD card unavailable
|
|
to the applications.
|
|
|
|
nsh> umount -t /mnt/sd0
|
|
|
|
It is now safe to remove the card. NuttX provides into callbacks
|
|
that can be used by an application to automatically unmount the
|
|
volume when it is removed. But those callbacks are not used in
|
|
these configurations.
|
|
|
|
Auto-Mounter
|
|
============
|
|
|
|
NuttX implements an auto-mounter than can make working with SD cards
|
|
easier. With the auto-mounter, the file system will be automatically
|
|
mounted when the SD card is inserted into the HSMCI slot and automatically
|
|
unmounted when the SD card is removed.
|
|
|
|
Here is a sample configuration for the auto-mounter:
|
|
|
|
File System Configuration
|
|
CONFIG_FS_AUTOMOUNTER=y
|
|
|
|
Board-Specific Options
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT=y
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT_FSTYPE="vfat"
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT_BLKDEV="/dev/mmcsd0"
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT_MOUNTPOINT="/mnt/sdcard"
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT_DDELAY=1000
|
|
CONFIG_SAMV71XULT_HSMCI0_AUTOMOUNT_UDELAY=2000
|
|
|
|
WARNING: SD cards should never be removed without first unmounting
|
|
them. This is to avoid data and possible corruption of the file
|
|
system. Certainly this is the case if you are writing to the SD card
|
|
at the time of the removal. If you use the SD card for read-only access,
|
|
however, then I cannot think of any reason why removing the card without
|
|
mounting would be harmful.
|
|
|
|
LEDs and Buttons
|
|
================
|
|
|
|
LEDs
|
|
----
|
|
There are two yellow LED available on the SAM V71 Xplained Ultra board that
|
|
can be turned on and off. The LEDs can be activated by driving the
|
|
connected I/O line to GND.
|
|
|
|
------ ----------- ---------------------
|
|
SAMV71 Function Shared functionality
|
|
PIO
|
|
------ ----------- ---------------------
|
|
PA23 Yellow LED0 EDBG GPIO
|
|
PC09 Yellow LED1 LCD, and Shield
|
|
------ ----------- ---------------------
|
|
|
|
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_autoleds.c. The LEDs are used to encode
|
|
OS-related events as follows:
|
|
|
|
------------------- ----------------------- -------- --------
|
|
SYMBOL Meaning LED state
|
|
LED0 LED1
|
|
------------------- ----------------------- -------- --------
|
|
LED_STARTED NuttX has been started OFF OFF
|
|
LED_HEAPALLOCATE Heap has been allocated OFF OFF
|
|
LED_IRQSENABLED Interrupts enabled OFF OFF
|
|
LED_STACKCREATED Idle stack created ON OFF
|
|
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 N/C Blinking
|
|
LED_IDLE MCU is is sleep mode Not used
|
|
------------------- ----------------------- -------- --------
|
|
|
|
Thus if LED0 is statically on, NuttX has successfully booted and is,
|
|
apparently, running normally. If LED1 is flashing at approximately
|
|
2Hz, then a fatal error has been detected and the system has halted.
|
|
|
|
NOTE: That LED0 is not used after completion of booting and may
|
|
be used by other board-specific logic.
|
|
|
|
Buttons
|
|
-------
|
|
SAM V71 Xplained Ultra contains three mechanical buttons. One button is the
|
|
RESET button connected to the SAM V71 reset line and the others are generic
|
|
user configurable buttons. When a button is pressed it will drive the I/O
|
|
line to GND.
|
|
|
|
------ ----------- ---------------------
|
|
SAMV71 Function Shared functionality
|
|
PIO
|
|
------ ----------- ---------------------
|
|
RESET RESET Trace, Shield, and EDBG
|
|
PA09 SW0 EDBG GPIO and Camera
|
|
PB12 SW1 EDBG SWD and Chip Erase
|
|
------ ----------- ---------------------
|
|
|
|
NOTES:
|
|
|
|
- There are no pull-up resistors connected to the generic user buttons so
|
|
it is necessary to enable the internal pull-up in the SAM V71 to use the
|
|
button.
|
|
- PB12 is set up as a system flash ERASE pin when the firmware boots. To
|
|
use the SW1, PB12 has to be configured as a normal regular I/O pin in
|
|
the MATRIX module. For more information see the SAM V71 datasheet.
|
|
|
|
AT24MAC402 Serial EEPROM
|
|
========================
|
|
|
|
Ethernet MAC Address
|
|
--------------------
|
|
The SAM V71 Xplained Ultra features one external AT24MAC402 serial EEPROM
|
|
with a EIA-48 MAC address connected to the SAM V71 through I2C. This device
|
|
contains a MAC address for use with the Ethernet interface.
|
|
|
|
Connectivity:
|
|
|
|
------ -------- -------- ------------------------------------------
|
|
SAMV71 SAMV71 I2C Shared
|
|
Pin Function Function Functionality
|
|
------ -------- -------- ------------------------------------------
|
|
PA03 TWID0 SDA EXT1, EXT2, EDBG I2C, LCD, Camera, Audio,
|
|
MediaLB, and Shield
|
|
PA04 TWICK0 SCL EXT1, EXT2, EDBG I2C, LCD, Camera, Audio,
|
|
MediaLB, and Shield
|
|
------ -------- -------- ------------------------------------------
|
|
|
|
I2C address:
|
|
|
|
The 7-bit addresses of the AT24 part are 0b1010AAA for the normal 2Kbit
|
|
memory and 0b1011aaa for the "extended memory" where aaa is the state of
|
|
the A0, A1, and A3 pins on the part. On the SAMV71-XULT board, these
|
|
are all pulled high so the full, 7-bit address is 0x5f.
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
System Type -> SAMV7 Peripheral Support
|
|
CONFIG_SAMV7_TWIHS0=y : Used to access the EEPROM
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
Device drivers -> Memory Technology Devices
|
|
CONFIG_MTD_AT24XX=y : Enable the AT24 device driver
|
|
CONFIG_AT24XX_SIZE=2 : Normal EEPROM is 2Kbit (256b)
|
|
CONFIG_AT24XX_ADDR=0x57 : Normal EEPROM address */
|
|
CONFIG_AT24XX_EXTENDED=y : Supports an extended memory region
|
|
CONFIG_AT24XX_EXTSIZE=160 : Extended address up to 0x9f
|
|
|
|
MTD Configuration Data
|
|
----------------------
|
|
The AT24 EEPROM can also be used to storage of up to 256 bytes of
|
|
configuration data:
|
|
|
|
Device drivers -> Memory Technology Devices
|
|
|
|
The configuration data device will appear at /dev/config.
|
|
|
|
S25FL116K QuadSPI FLASH
|
|
====================
|
|
|
|
A QSPI FLASH driver was added and verifed on 2015-11-07. This driver
|
|
operated in the memory mapped Serial Memory Mode (SMM). These
|
|
configuration options were enabled to test QSPI:
|
|
|
|
CONFIG_SAMV7_QSPI=y
|
|
CONFIG_SAMV7_QSPI_DLYBCT=0
|
|
CONFIG_SAMV7_QSPI_DLYBS=0
|
|
CONFIG_SAMV7_QSPI_DMA=y
|
|
CONFIG_SAMV7_QSPI_DMATHRESHOLD=8
|
|
|
|
The MPU must be enabled to use QSPI:
|
|
|
|
CONFIG_ARCH_USE_MPU=y
|
|
CONFIG_ARM_MPU=y
|
|
CONFIG_ARM_MPU_NREGIONS=16
|
|
|
|
And there options enable the driver for the on-board S25FL116K QuadSPI
|
|
FLASH:
|
|
|
|
CONFIG_MTD_S25FL1=y
|
|
CONFIG_S25FL1_QSPIMODE=0
|
|
CONFIG_S25FL1_QSPI_FREQUENCY=108000000
|
|
|
|
SmartFS
|
|
-------
|
|
The SmartFS file system is selected with the following settings.
|
|
|
|
CONFIG_FS_SMARTFS=y
|
|
CONFIG_SMARTFS_ERASEDSTATE=0xff
|
|
CONFIG_SMARTFS_MAXNAMLEN=16
|
|
|
|
CONFIG_MTD_SMART=y
|
|
CONFIG_MTD_SMART_SECTOR_SIZE=512
|
|
CONFIG_MTD_SMART_WEAR_LEVEL=y
|
|
|
|
Upon boot, the on-board S25FL116k flash device will appears as:
|
|
|
|
/dev/smart0
|
|
|
|
Before SmartFS can be used, it must be formatted. So this command
|
|
must be used one time the first time that the system boots:
|
|
|
|
nsh> mksmartfs /dev/smart0
|
|
|
|
Then it can be mounted using the following NSH command:
|
|
|
|
nsh> mount -t smartfs /dev/smart0 /mnt/qspi
|
|
|
|
The first time that you boot the system, there will be a long delay
|
|
before the nsh> prompt. That long delay is SmartFS scanning the
|
|
large FLASH part. Likewise, the when you format the SmartFS, you
|
|
also expect a significant delay.
|
|
|
|
A better application design would perform SmartFS initialization
|
|
asynchronously on a separate thread to avoid the delay at the user
|
|
interface.
|
|
|
|
NXFFS
|
|
-----
|
|
The NXFFS file system is selected with the following settings.
|
|
|
|
CONFIG_FS_NXFFS=y
|
|
CONFIG_NXFFS_ERASEDSTATE=0xff
|
|
CONFIG_NXFFS_MAXNAMLEN=255
|
|
CONFIG_NXFFS_PACKTHRESHOLD=32
|
|
CONFIG_NXFFS_PREALLOCATED=y
|
|
CONFIG_NXFFS_TAILTHRESHOLD=8192
|
|
|
|
The NXFFS file system is automatically mounted by logic src/sam_bringup.c when the system boots:
|
|
|
|
nsh> mount
|
|
/mnt/s25fl1 type nxffs
|
|
nsh> echo "This is a test" >/mnt/s25fl1/atest.txt
|
|
nsh> ls /mnt/s25fl1
|
|
/mnt/s25fl1:
|
|
atest.txt
|
|
nsh> cat /mnt/s25fl1/atest.txt
|
|
This is a test
|
|
|
|
Character Driver
|
|
----------------
|
|
If neither SmartFS nor NXFFS are defined, then the S25FL1 driver will be
|
|
wrapped as a character driver and available as /dev/mtd0.
|
|
|
|
Program FLASH Access
|
|
====================
|
|
An on-chip FLASH driver was added and verifed on 2015-11-13. These
|
|
configuration options were enabled to test the on-chip FLASH support:
|
|
|
|
CONFIG_MTD_PROGMEM=y
|
|
CONFIG_SAMV7_PROGMEM=y
|
|
CONFIG_SAMV7_PROGMEM_NSECTORS=8
|
|
|
|
D-Cache must be configured in write-through mode:
|
|
|
|
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=y
|
|
|
|
The total FLASH on the SAMV71 is organized as 128KB/sector x 16 sectors
|
|
= 2MB. The sectors are all uniform (except for sector zero which will
|
|
never be used by the driver).
|
|
|
|
The configuration sets aside 8 sectors, or 8 * 128KB = 1MB of the FLASH
|
|
for programmable memory (CONFIG_SAMV7_PROGMEM_NSECTORS=8). The exact
|
|
number of sectors set aside is optional.
|
|
|
|
NOTE: Ideally, one should also modify the linker script and reduce the size
|
|
of the available FLASH the amount set aside for program usage to avoid
|
|
difficult run-time problems. That would be 1MB in this configuration. I
|
|
did not do that only because I know that my test program is small.
|
|
|
|
When the system boots, you can see the FLASH driver:
|
|
|
|
NuttShell (NSH) NuttX-7.12
|
|
nsh> ls /dev
|
|
/dev:
|
|
config
|
|
console
|
|
mmcsd0
|
|
mtd1
|
|
mtdblock1
|
|
null
|
|
ttyS0
|
|
|
|
/dev/mtdblock1 is a block driver that can be used with any file system on
|
|
the FLASH; /dev/mtd1 is the corresponding character driver used by the
|
|
apps/examples/media test.
|
|
|
|
Each of the uniform sectors is divided up into 256 512B "pages". This is
|
|
not really useful, however, because we can only erase a minimum of groups
|
|
of 16 pages or 8KB. In the code, I you will see that I refer to these
|
|
groups of 16 pages as "clusters." So the cluster is the smallest thing
|
|
that you can perform a read/write/modify operation on.
|
|
|
|
Using 8 sectors yields 16 *8 = 128 clusters (aka blocks). You can see
|
|
this when the apps/examples/media test runs:
|
|
|
|
nsh> media
|
|
MTD Geometry:
|
|
blocksize: 8192
|
|
erasesize: 8192
|
|
neraseblocks: 128
|
|
Using:
|
|
blocksize: 8192
|
|
nblocks: 128
|
|
Write/Verify: Block 0
|
|
Write/Verify: Block 1
|
|
Write/Verify: Block 2
|
|
Write/Verify: Block 3
|
|
...
|
|
Write/Verify: Block 127
|
|
Re-read/Verify: Block 0
|
|
Re-read/Verify: Block 1
|
|
Re-read/Verify: Block 2
|
|
Re-read/Verify: Block 3
|
|
...
|
|
Re-read/Verify: Block 127
|
|
nsh>
|
|
|
|
NOTE: The media test can be added to the NSH configuration with:
|
|
|
|
CONFIG_EXAMPLES_MEDIA=y
|
|
CONFIG_EXAMPLES_MEDIA_BLOCKSIZE=8192
|
|
CONFIG_EXAMPLES_MEDIA_DEVPATH="/dev/mtd1"
|
|
|
|
Networking
|
|
==========
|
|
|
|
KSZ8061RNBVA Connections
|
|
------------------------
|
|
|
|
------ --------- --------- --------------------------
|
|
SAMV71 SAMV71 Ethernet Shared functionality
|
|
Pin Function Function
|
|
------ --------- --------- --------------------------
|
|
PD00 GTXCK REF_CLK Shield
|
|
PD01 GTXEN TXEN
|
|
PD02 GTX0 TXD0
|
|
PD03 GTX1 TXD1
|
|
PD04 GRXDV CRS_DV Trace
|
|
PD05 GRX0 RXD0 Trace
|
|
PD06 GRX1 RXD1 Trace
|
|
PD07 GRXER RXER Trace
|
|
PD08 GMDC MDC Trace
|
|
PD09 GMDIO MDIO
|
|
PA19 GPIO INTERRUPT EXT1, Shield
|
|
PA29 GPIO SIGDET
|
|
PC10 GPIO RESET
|
|
------ --------- --------- --------------------------
|
|
|
|
Selecting the GMAC peripheral
|
|
-----------------------------
|
|
|
|
System Type -> SAMV7 Peripheral Support
|
|
CONFIG_SAMV7_EMAC0=y : Enable the GMAC peripheral (aka, EMAC0)
|
|
CONFIG_SAMV7_TWIHS0=y : We will get the MAC address from the AT24 EEPROM
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
System Type -> EMAC device driver options
|
|
CONFIG_SAMV7_EMAC0_NRXBUFFERS=16 : Set aside some RS and TX buffers
|
|
CONFIG_SAMV7_EMAC0_NTXBUFFERS=8
|
|
CONFIG_SAMV7_EMAC0_RMII=y : The RMII interfaces is used on the board
|
|
CONFIG_SAMV7_EMAC0_AUTONEG=y : Use autonegotiation
|
|
CONFIG_SAMV7_EMAC0_PHYADDR=1 : KSZ8061 PHY is at address 1
|
|
CONFIG_SAMV7_EMAC0_PHYSR=30 : Address of PHY status register on KSZ8061
|
|
CONFIG_SAMV7_EMAC0_PHYSR_ALTCONFIG=y : Needed for KSZ8061
|
|
CONFIG_SAMV7_EMAC0_PHYSR_ALTMODE=0x7 : " " " " " "
|
|
CONFIG_SAMV7_EMAC0_PHYSR_10HD=0x1 : " " " " " "
|
|
CONFIG_SAMV7_EMAC0_PHYSR_100HD=0x2 : " " " " " "
|
|
CONFIG_SAMV7_EMAC0_PHYSR_10FD=0x5 : " " " " " "
|
|
CONFIG_SAMV7_EMAC0_PHYSR_100FD=0x6 : " " " " " "
|
|
|
|
PHY selection. Later in the configuration steps, you will need to select
|
|
the KSZ8061 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_ARP=y : ARP support should be enabled
|
|
CONFIG_NET_ARP_SEND=y : Use ARP to get peer address before sending
|
|
CONFIG_NET_TCP=y : Enable TCP/IP networking
|
|
CONFIG_NET_TCPBACKLOG=y : Support TCP/IP backlog
|
|
CONFIG_NET_TCP_READAHEAD=y : Enable TCP read-ahead buffering
|
|
CONFIG_NET_TCP_WRITE_BUFFERS=y : Enable TCP write buffering
|
|
CONFIG_NET_UDP=y : Enable UDP networking
|
|
CONFIG_NET_BROADCAST=y : Support UDP broadcase packets
|
|
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_KSZ8061=y : Select the KSZ8061 PHY used with EMAC0
|
|
|
|
Device drivers -> Memory Technology Devices
|
|
CONFIG_MTD_AT24XX=y : Enable the AT24 device driver
|
|
CONFIG_AT24XX_SIZE=2 : Normal EEPROM is 2Kbit (256b)
|
|
CONFIG_AT24XX_ADDR=0x57 : Normal EEPROM address */
|
|
CONFIG_AT24XX_EXTENDED=y : Supports an extended memory region
|
|
CONFIG_AT24XX_EXTSIZE=160 : Extended address up to 0x9f
|
|
|
|
RTOS Features ->Work Queue Support
|
|
CONFIG_SCHED_WORKQUEUE=y : Work queue support is needed
|
|
CONFIG_SCHED_HPWORK=y
|
|
CONFIG_SCHED_HPWORKSTACKSIZE=2048 : Might need to be increased
|
|
|
|
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 an IP address
|
|
CONFIG_NSH_DRIPADDR=0x0a000001 : IP address of gateway/host PC
|
|
CONFIG_NSH_NETMASK=0xffffff00 : Netmask
|
|
CONFIG_NSH_NOMAC=n : We will get the IP address from EEPROM
|
|
: Defaults should be okay for other options
|
|
|
|
SAMV71 Versions
|
|
---------------
|
|
|
|
WARNING: The newer SAMV71 have 6 GMAC queues, not 3. All queues must be
|
|
configured for the GMAC to work correctly, even the queues that you are not
|
|
using (you can just configure these queues with a very small ring buffer.)
|
|
|
|
The older uses the Cortex-M7 core r0p1 and the newer r1p1 revisions. The
|
|
SAMV71 revisions are called "rev A" (or sometimes "MRLA") and "rev B"
|
|
("MRLB"). There should be a small "A" or "B" on the chip package just below
|
|
the reference and you can also differentiate them at runtime with the
|
|
VERSION field in the CHIPID CIDR register.
|
|
|
|
Cache-Related Issues
|
|
--------------------
|
|
|
|
I- and D-Caches can be enabled but the D-Cache must be enabled in write-
|
|
through mode. This is to work around issues with the RX and TX descriptors
|
|
with are 8-bytes in size. But the D-Cache cache line size is 32-bytes.
|
|
That means that you cannot reload, clean or invalidate a descriptor without
|
|
also effecting three neighboring descriptors. Setting write through mode
|
|
eliminates the need for cleaning the D-Cache. If only reloading and
|
|
invalidating are done, then there is no problem.
|
|
|
|
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 SAMV71-XULT 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.
|
|
|
|
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:
|
|
|
|
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 SAMV71-XULT:
|
|
|
|
$ ping 10.0.0.2
|
|
|
|
You can also log into the NSH from the host PC like this:
|
|
|
|
$ 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-7.9
|
|
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 sh
|
|
|
|
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. 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 networking initialization feature by itself 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.
|
|
|
|
- Furthermore, there is no support for detecting loss of the network
|
|
connection and recovery of networking when the connection is restored.
|
|
|
|
Both of these shortcomings can be eliminated by enabling the network
|
|
monitor:
|
|
|
|
Network Monitor
|
|
---------------
|
|
By default the network initialization thread will bring-up the network
|
|
then exit, freeing all of the resources that it required. This is a
|
|
good behavior for systems with limited memory.
|
|
|
|
If the CONFIG_NSH_NETINIT_MONITOR option is selected, however, then the
|
|
network initialization thread will persist forever; it will monitor the
|
|
network status. In the event that the network goes down (for example, if
|
|
a cable is removed), then the thread will monitor the link status and
|
|
attempt to bring the network back up. In this case the resources
|
|
required for network initialization are never released.
|
|
|
|
Pre-requisites:
|
|
|
|
- CONFIG_NSH_NETINIT_THREAD as described above.
|
|
|
|
- CONFIG_NETDEV_PHY_IOCTL. Enable PHY IOCTL commands in the Ethernet
|
|
device driver. Special IOCTL commands must be provided by the Ethernet
|
|
driver to support certain PHY operations that will be needed for link
|
|
management. There operations are not complex and are implemented for
|
|
the Atmel SAMV7 family.
|
|
|
|
- CONFIG_ARCH_PHY_INTERRUPT. This is not a user selectable option.
|
|
Rather, it is set when you select a board that supports PHY interrupts.
|
|
In most architectures, the PHY interrupt is not associated with the
|
|
Ethernet driver at all. Rather, the PHY interrupt is provided via some
|
|
board-specific GPIO and the board-specific logic must provide support
|
|
for that GPIO interrupt. To do this, the board logic must do two things:
|
|
(1) It must provide the function arch_phy_irq() as described and
|
|
prototyped in the nuttx/include/nuttx/arch.h, and (2) it must select
|
|
CONFIG_ARCH_PHY_INTERRUPT in the board configuration file to advertise
|
|
that it supports arch_phy_irq(). This logic can be found at
|
|
nuttx/configs/samv71-xult/src/sam_ethernet.c.
|
|
|
|
- And a few other things: UDP support is required (CONFIG_NET_UDP) and
|
|
signals must not be disabled (CONFIG_DISABLE_SIGNALS).
|
|
|
|
Given those prerequisites, the network monitor can be selected with these
|
|
additional settings.
|
|
|
|
Networking Support -> Networking Device Support
|
|
CONFIG_NETDEV_PHY_IOCTL=y : Enable PHY ioctl support
|
|
|
|
Application Configuration -> NSH Library -> Networking Configuration
|
|
CONFIG_NSH_NETINIT_THREAD : Enable the network initialization thread
|
|
CONFIG_NSH_NETINIT_MONITOR=y : Enable the network monitor
|
|
CONFIG_NSH_NETINIT_RETRYMSEC=2000 : Configure the network monitor as you like
|
|
CONFIG_NSH_NETINIT_SIGNO=18
|
|
|
|
USBHS Device Controller Driver
|
|
==============================
|
|
The USBHS device controller driver is enabled with he following configuration
|
|
settings:
|
|
|
|
Device Drivers -> USB Device Driver Support
|
|
CONFIG_USBDEV=y : Enable USB device support
|
|
For full-speed/low-power mode:
|
|
CONFIG_USBDEV_DUALSPEED=n : Disable High speed support
|
|
For high-speed/normal mode:
|
|
CONFIG_USBDEV_DUALSPEED=y : Enable High speed support
|
|
CONFIG_USBDEV_DMA=y : Enable DMA methods
|
|
CONFIG_USBDEV_MAXPOWER=100 : Maximum power consumption
|
|
CONFIG_USBDEV_SELFPOWERED=y : Self-powered device
|
|
|
|
System Type -> SAMV7 Peripheral Selection
|
|
CONFIG_SAMV7_USBDEVHS=y
|
|
|
|
System Type -> SAMV7 USB High Sppeed Device Controller (DCD options
|
|
For full-speed/low-power mode:
|
|
CONFIG_SAMV7_USBDEVHS_LOWPOWER=y : Select low power mode
|
|
For high-speed/normal mode:
|
|
CONFIG_SAMV7_USBDEVHS_LOWPOWER=n : Don't select low power mode
|
|
CONFIG_SAMV7_USBHS_NDTDS=32 : Number of DMA transfer descriptors
|
|
CONFIG_SAMV7_USBHS_PREALLOCATE=y : Pre-allocate descriptors
|
|
|
|
As noted above, this driver will not work correctly if the write back
|
|
data cache is enabled. You must have:
|
|
|
|
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=y
|
|
|
|
In order to be usable, you must all enabled some class driver(s) for the
|
|
USBHS device controller. Here, for example, is how to configure the CDC/ACM
|
|
serial device class:
|
|
|
|
Device Drivers -> USB Device Driver Support
|
|
CONFIG_CDCACM=y : USB Modem (CDC ACM) support
|
|
CONFIG_CDCACM_EP0MAXPACKET=64 : Enpoint 0 packet size
|
|
CONFIG_CDCACM_EPINTIN=1 : Interrupt IN endpoint number
|
|
CONFIG_CDCACM_EPINTIN_FSSIZE=64 : Full speed packet size
|
|
CONFIG_CDCACM_EPINTIN_HSSIZE=64 : High speed packet size
|
|
CONFIG_CDCACM_EPBULKOUT=3 : Bulk OUT endpoint number
|
|
CONFIG_CDCACM_EPBULKOUT_FSSIZE=64 : Full speed packet size
|
|
CONFIG_CDCACM_EPBULKOUT_HSSIZE=512 : High speed packet size
|
|
CONFIG_CDCACM_EPBULKIN=2 : Bulk IN endpoint number
|
|
CONFIG_CDCACM_EPBULKIN_FSSIZE=64 : Full speed packet size
|
|
CONFIG_CDCACM_EPBULKIN_HSSIZE=512 : High speed packet size
|
|
CONFIG_CDCACM_NWRREQS=4 : Number of write requests
|
|
CONFIG_CDCACM_NRDREQS=8 : Number of read requests
|
|
CONFIG_CDCACM_BULKIN_REQLEN=96 : Size of write request buffer (for full speed)
|
|
CONFIG_CDCACM_BULKIN_REQLEN=768 : Size of write request buffer (for high speed)
|
|
CONFIG_CDCACM_RXBUFSIZE=257 : Serial read buffer size
|
|
CONFIG_CDCACM_TXBUFSIZE=193 : Serial transmit buffer size (for full speed)
|
|
CONFIG_CDCACM_TXBUFSIZE=769 : Serial transmit buffer size (for high speed)
|
|
CONFIG_CDCACM_VENDORID=0x0525 : Vendor ID
|
|
CONFIG_CDCACM_PRODUCTID=0xa4a7 : Product ID
|
|
CONFIG_CDCACM_VENDORSTR="NuttX" : Vendor string
|
|
CONFIG_CDCACM_PRODUCTSTR="CDC/ACM Serial" : Product string
|
|
|
|
Device Drivers -> Serial Driver Support
|
|
CONFIG_SERIAL_REMOVABLE=y : Support for removable serial device
|
|
|
|
The CDC/ACM application provides commands to connect and disconnect the
|
|
CDC/ACM serial device:
|
|
|
|
CONFIG_SYSTEM_CDCACM=y : Enable connect/disconnect support
|
|
CONFIG_SYSTEM_CDCACM_DEVMINOR=0 : Use device /dev/ttyACM0
|
|
CONFIG_CDCACM_RXBUFSIZE=??? : A large RX may be needed
|
|
|
|
If you include this CDC/ACM application, then you can connect the CDC/ACM
|
|
serial device to the host by entering the command 'sercon' and you detach
|
|
the serial device with the command 'serdis'. If you do no use this
|
|
application, they you will have to write logic in your board initialization
|
|
code to initialize and attach the USB device.
|
|
|
|
Audio Interface
|
|
===============
|
|
|
|
WM8904 Audio Codec
|
|
------------------
|
|
|
|
SAMV71 Interface WM8904 Interface
|
|
---- ------------ ------- ----------------------------------
|
|
PIO Usage Pin Function
|
|
---- ------------ ------- ----------------------------------
|
|
PA3 TWD0 SDA I2C control interface, data line
|
|
PA4 TWCK0 SCLK I2C control interface, clock line
|
|
PA10 RD ADCDAT Digital audio output (microphone)
|
|
PB18 PCK2 MCLK Master clock
|
|
PB0 TF LRCLK Left/right data alignment clock
|
|
PB1 TK BCLK Bit clock, for synchronization
|
|
PD11 GPIO IRQ Audio interrupt
|
|
PD24 RF LRCLK Left/right data alignment clock
|
|
PD26 TD DACDAT Digital audio input (headphone)
|
|
---- ------------ ------- ----------------------------------
|
|
|
|
CP2100-CP Fractional-N Clock Multiplier
|
|
--------------------------------------
|
|
|
|
SAMV71 Interface CP2100-CP Interface
|
|
---- ------------ ------- ----------------------------------
|
|
PIO Usage Pin Function
|
|
---- ------------ ------- ----------------------------------
|
|
PA3 TWD0 SDA I2C control interface, data line
|
|
PA4 TWCK0 SCLK I2C control interface, clock line
|
|
PD21 TIOA11 CLK_IN PLL input
|
|
- - XTI/XTO 12.0MHz crystal
|
|
PA22 RK CLK_OUT PLL output
|
|
- - AUX_OUT N/C
|
|
---- ------------ ------- ----------------------------------
|
|
|
|
maXTouch Xplained Pro
|
|
=====================
|
|
|
|
Testing has also been performed using the maXTouch Xplained Pro LCD
|
|
(ATMXT-XPRO).
|
|
|
|
**************************************************************************
|
|
* WARNING: *
|
|
* The maXTouch chip was not configured on all of the maXTouch Xplained *
|
|
* Pro boards that I have used (which is two). The maXTouch is *
|
|
* completely non-functional with no configuration in its NV memory! *
|
|
* *
|
|
* My understanding is that this configuration can be set on Linux *
|
|
* using the mxp-app program which is available on GitHub. There is an *
|
|
* (awkward) way to do this with NuttX too. In order to set the *
|
|
* maXTouch configuration with Nuttx you need to do these things: *
|
|
* *
|
|
* - Copy the function atmxt_config() from the file *
|
|
* configs/samv71-xult/src/atmxt_config.c into the file *
|
|
* drivers/input/mxt.c *
|
|
* - Add a call to atmxt_config() in drivers/input/mxt.c in the *
|
|
* function mxt_register() just before the touchscreen device is *
|
|
* registered (i.e, the call to register_driver()). *
|
|
* - Run the code one time. Your maXTouch is configured and should *
|
|
* now work. *
|
|
* - Don't forget to remove atmxt_config() from drivers/input/mxt.c and *
|
|
* restore driver as it was. *
|
|
* *
|
|
**************************************************************************
|
|
|
|
|
|
maXTouch Xplained Pro Standard Extension Header
|
|
-----------------------------------------------
|
|
The LCD could be connected either via EXT1 or EXT2 using the 2x10 20-pin
|
|
cable and the maXTouch Xplained Pro standard extension header. Access would
|
|
then be performed in SPI mode.
|
|
|
|
NOTE: There is currently no support for use of the LCD in SPI mode. See
|
|
the next paragraph where the LCD/EXT4 connection is discussion.
|
|
|
|
NOTE the 3 switch mode selector on the back of the maXtouch. All switches
|
|
should be in the ON position to select 4-wire SPI mode.
|
|
|
|
---- -------- ---- ----------- ---- ----------- ------------------------------------------
|
|
SAMV71-XULT maxTouch Xplained Pro
|
|
PIN FUNCTION EXT1 FUNC EXT2 FUNC Description
|
|
---- -------- ---- ----------- ---- ----------- ------------------------------------------
|
|
1 ID - - - - Communication line to ID chip
|
|
2 GND - - - - Ground
|
|
3 N/C PC31 - PD30 -
|
|
4 N/C PA19 - PC13 -
|
|
5 GPIO PB3 GPIO PA6 GPIO Command/Data Select
|
|
6 N/C PB2 - PD11 -
|
|
7 PWM PA0 PWMC0_PWMH0 PC19 PWMC0_PMWH2 Backlight control
|
|
8 N/C PC30 - PD26 -
|
|
9 GPIO/IRQ PD28 GPIO PA2 GPIO IRQ from maXTouch controller
|
|
10 GPIO PA5 GPIO PA24 GPIO RESET signal for maXTouch and LCD controller
|
|
11 I2C SDA PA3 TWID0 PA3 TWID0 I2C Data line for maXTouch controller
|
|
12 I2C SCL PA4 TWICK0 PA4 TWICK0 I2C Clock line for maXTouch controller
|
|
13 N/C PB0 - PA21 -
|
|
14 N/C PB1 - PB4 -
|
|
15 CS PD25 GPIO PD27 GPIO CS line for LCD controller
|
|
16 SPI MOSI PD21 SPI0_MOSI PD21 SPI0_MOSI SPI Data to LCD controller
|
|
17 SPI MISO PD20 SPI0_MISO PD20 SPI0_MISO SPI Data from LCD controller
|
|
18 SPI SCK PD22 SPI0_SPCK PD22 SPI0_SPCK SPI Clock line
|
|
19 GND - - - - Ground
|
|
20 VCC - - - - Target supply voltage
|
|
---- -------- ---- ----------- ---- ----------- ------------------------------------------
|
|
|
|
NOTE: Use of EXT1 conflicts with the Arduino RXD pin (PD28). You cannot
|
|
put the maXTouch Xplained in EXT1 and also use the Arduino RXD/TXD pins
|
|
as your serial console.
|
|
|
|
maXTouch Xplained Pro Xplained Pro LCD Connector
|
|
------------------------------------------------
|
|
It is also possible to connect the LCD via the flat cable to the EXT4 LCD
|
|
connector. In this case, you would use the SMC/EBI to communicate with the
|
|
LCD.
|
|
|
|
NOTE: (1) Only the parallel interface is supported by the SAMV71-XULT and (2)
|
|
the 3 switch mode selector on the back of the maXtouch. These switches should
|
|
be in the OFF-ON-OFF positions to select 16-bit color mode.
|
|
|
|
----------------- ------------- -----------------------------------------------------------
|
|
LCD SAMV71 Description
|
|
Pin Function Pin Function
|
|
---- ------------ ---- -------- -----------------------------------------------------------
|
|
1 ID - - Communication line to ID chip on extension board
|
|
2 GND - GND Ground
|
|
3 D0 PC0 D0 Data line
|
|
4 D1 PC1 D1 Data line
|
|
5 D2 PC2 D2 Data line
|
|
6 D3 PC3 D3 Data line
|
|
7 GND - GND Ground
|
|
8 D4 PC4 D4 Data line
|
|
9 D5 PC5 D5 Data line
|
|
10 D6 PC6 D6 Data line
|
|
11 D7 PC7 D7 Data line
|
|
12 GND - GND Ground
|
|
13 D8 PE0 D8 Data line
|
|
14 D9 PE1 D9 Data line
|
|
15 D10 PE2 D10 Data line
|
|
16 D11 PE3 D11 Data line
|
|
17 GND - GND Ground
|
|
18 D12 PE4 D12 Data line
|
|
19 D13 PE5 D13 Data line
|
|
20 D14 PA15 D14 Data line
|
|
21 D15 PA16 D15 Data line
|
|
22 GND - GND Ground
|
|
23 D16 - - Data line
|
|
24 D17 - - Data line
|
|
25 N/C - -
|
|
26 N/C - -
|
|
27 GND - GND Ground
|
|
28 N/C - -
|
|
29 N/C - -
|
|
30 N/C - -
|
|
31 N/C - -
|
|
32 GND - GND Ground
|
|
33 PCLK/ PC30 GPIO SMC: Pixel clock Display RAM select.
|
|
CMD_DATA_SEL SPI: One address line of the MCU for displays where it
|
|
is possible to select either the register or the
|
|
data interface
|
|
34 VSYNC/CS PD19 NCS3 SMC: Vertical synchronization.
|
|
SPI: Chip select
|
|
35 HSYNC/WE PC8 NWE SMC: Horizontal synchronization
|
|
SPI: Write enable signal
|
|
36 DATA ENABLE/ PC11 NRD SMC: Data enable signal
|
|
RE SPI: Read enable signal
|
|
37 SPI SCK - - SPI: Clock for SPI
|
|
38 SPI MOSI - - SPI: Master out slave in line of SPI
|
|
39 SPI MISO - - SPI: Master in slave out line of SPI
|
|
40 SPI SS - - SPI: Slave select for SPI
|
|
41 N/C - -
|
|
42 TWI SDA PA3 TWD0 I2C data line (maXTouch®)
|
|
43 TWI SCL PA4 TWCK0 I2C clock line (maXTouch)
|
|
44 IRQ1 PD28 WKUP5 maXTouch interrupt line
|
|
45 N/C PA2 WKUP2
|
|
46 PWM PC9 TIOB7 Backlight control
|
|
47 RESET PC13 GPIO Reset for both display and maxTouch
|
|
48 VCC - - 3.3V power supply for extension board
|
|
49 VCC - - 3.3V power supply for extension board
|
|
50 GND - - Ground
|
|
---- ------------ ---- -------- -----------------------------------------------------------
|
|
|
|
NOTE: Use of LCD/EXT4 conflicts with the Arduino RXD pin (PD28). You cannot
|
|
put the maXTouch Xplained in LCD/EXT4 and also use the Arduino RXD/TXD pins
|
|
as your serial console.
|
|
|
|
Connecting the flat cable. I was embarrassed to say that I did not know how
|
|
the connectors worked. Let me share this so that, perhaps, I can save you
|
|
the same embarrassment:
|
|
|
|
- The maXTouch Xplained Pro has an Omron XF2M-5015-1A connector. There is a
|
|
black bar at back (toward the baord). Raise that bar and insert the cable
|
|
with the contacts away from the board. Lower that bar to lock the cable
|
|
in place.
|
|
|
|
- The SAMV71-Xult has a TE Connectivity 5-1734839-0 FPC connector that works
|
|
differently. On each size of the connector are two small white tabs. Pull
|
|
these out and away from the board. Insert the ribbon with the contacts
|
|
toward the board. Lock the cable in place by pushing the tabs back in
|
|
place.
|
|
|
|
MXT Configuration Options
|
|
-------------------------
|
|
|
|
System Type -> SAMV7 Peripheral Support
|
|
CONFIG_SAMV7_TWIHS0=y : Needed by the MaXTouch controller
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
Board Selection ->
|
|
CONFIG_SAMV71XULT_MXTXPLND=y : MaXTouch Xplained is connected
|
|
CONFIG_SAMV71XULT_MXTXPLND_EXT1=y : Connected on EXT1, or
|
|
CONFIG_SAMV71XULT_MXTXPLND_EXT2=y : Connected on EXT2, or
|
|
CONFIG_SAMV71XULT_MXTXPLND_LCD=y : Connected on LCD
|
|
CONFIG_SAMV71XULT_MXT_DEVMINOR=0 : Register as /dev/input0
|
|
CONFIG_SAMV71XULT_MXT_I2CFREQUENCY=400000
|
|
|
|
NOTE: When selecting EXT1 or EXT2, be conscious of possible pin conflicts.
|
|
EXT1, for example, will conflict with the use of the Arduino TXD and RXD
|
|
pins for the serial console
|
|
|
|
Device Drivers -> Input Devices
|
|
CONFIG_INPUT=y : Enable support for human input devices
|
|
CONFIG_INPUT_MXT=y : Enable support for the maXTouch controller
|
|
|
|
The following enables a small built-in application that can be used to
|
|
test the touchscreen:
|
|
|
|
Application Configuration -> Examples -> Touchscreen example
|
|
CONFIG_EXAMPLES_TOUCHSCREEN=y : Enables the example
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_DEVPATH="/dev/input0"
|
|
CONFIG_EXAMPLES_TOUCHSCREEN_MINOR=0
|
|
|
|
ILI9488 Configuration Options
|
|
-----------------------------
|
|
|
|
Currently only the parallel mode is supported. This means that the LCD can
|
|
only be used in connected in the LCD (EXT4) connection.
|
|
|
|
System Type -> SAMV7 Peripheral Support
|
|
CONFIG_SAMV7_SMC=y : Needed by the ILI9466 driver controller
|
|
CONFIG_SAMV7_XDMAC=y : Needed by the ILI9466 driver
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
Board Selection ->
|
|
CONFIG_SAMV71XULT_MXTXPLND=y : MaXTouch Xplained is connected
|
|
CONFIG_SAMV71XULT_MXTXPLND_LCD=y : Must be connected on LCD
|
|
|
|
NOTE: When selecting EXT1 or EXT2, be conscious of possible pin conflicts.
|
|
EXT1, for example, will conflict with the use of the Arduino TXD and RXD
|
|
pins for the serial console
|
|
|
|
Device Drivers -> LCD drivers
|
|
CONFIG_LCD=y : Enable support for LCDs
|
|
|
|
Graphics
|
|
CONFIG_NX=y : Enable Graphics supported
|
|
CONFIG_NX_LCDDRIVER=y : Enable LCD driver support
|
|
CONFIG_NX_DISABLE_*BPP=y : When * is {1,2,4,8,24, and 32}
|
|
CONFIG_NXFONTS_CHARBITS=7
|
|
CONFIG_NXFONT_SANS23X27=y : One font must be enabled
|
|
|
|
There are several graphics examples that can be enabled under apps/examples.
|
|
nxlines is one of these and can be enabled as follows. See
|
|
apps/examples/README.txt for information about configuring other graphics
|
|
examples.
|
|
|
|
The following enables a small built-in application that can be used to
|
|
test the touchscreen:
|
|
|
|
Application Configuration -> Examples -> NX lines example
|
|
CONFIG_EXAMPLES_NXLINES=y : Enables the nxlines example
|
|
CONFIG_EXAMPLES_NXLINES_VPLANE=0
|
|
CONFIG_EXAMPLES_NXLINES_DEVNO=0
|
|
|
|
MCAN1 Loopback Test
|
|
===================
|
|
|
|
MCAN1
|
|
-----
|
|
SAM V71 Xplained Ultra has two MCAN modules that performs communication according
|
|
to ISO11898-1 (Bosch CAN specification 2.0 part A,B) and Bosch CAN FD
|
|
specification V1.0. MCAN1 is connected to an on-board ATA6561 CAN physical-layer
|
|
transceiver.
|
|
|
|
------- -------- -------- -------------
|
|
SAM V71 FUNCTION ATA6561 SHARED
|
|
PIN FUNCTION FUNCTIONALITY
|
|
------- -------- -------- -------------
|
|
PC14 CANTX1 TXD Shield
|
|
PC12 CANRX1 RXD Shield
|
|
------- -------- -------- -------------
|
|
|
|
Enabling MCAN1
|
|
--------------
|
|
These modifications may be applied to the samv71-xult/nsh configuration in order
|
|
to enable MCAN1:
|
|
|
|
Device Drivers -> CAN Driver support
|
|
CONFIG_CAN=y # Enable the upper-half CAN driver
|
|
CONFIG_CAN_FIFOSIZE=8
|
|
CONFIG_CAN_NPENDINGRTR=4
|
|
|
|
System Type -> SAMV7 Peripheral Selections
|
|
CONFIG_SAMV7_MCAN1=y # Enable MCAN1 as the lower-half
|
|
|
|
System Type -> MCAN device driver options
|
|
CONFIG_SAMV7_MCAN_CLKSRC_MAIN=y # Use the MAIN clock as the source
|
|
CONFIG_SAMV7_MCAN_CLKSRC_PRESCALER=1
|
|
|
|
System Type ->MCAN device driver options -> MCAN1 device driver options
|
|
CONFIG_SAMV7_MCAN1_ISO11899_1=y # Loopback test only support ISO11899-1
|
|
CONFIG_SAMV7_MCAN1_LOOPBACK=y # Needed for loopback test
|
|
CONFIG_SAMV7_MCAN1_BITRATE=500000 # Not critical for loopback test
|
|
CONFIG_SAMV7_MCAN1_PROPSEG=2 # Bit timing setup
|
|
CONFIG_SAMV7_MCAN1_PHASESEG1=11 # " " " " " "
|
|
CONFIG_SAMV7_MCAN1_PHASESEG2=11 # " " " " " "
|
|
CONFIG_SAMV7_MCAN1_FSJW=4 # " " " " " "
|
|
CONFIG_SAMV7_MCAN1_FBITRATE=2000000 # CAN_FD BTW mode is not used
|
|
CONFIG_SAMV7_MCAN1_FPROPSEG=2 # " " " " " " "" " " " "
|
|
CONFIG_SAMV7_MCAN1_FPHASESEG1=4 # " " " " " " "" " " " "
|
|
CONFIG_SAMV7_MCAN1_FPHASESEG2=4 # " " " " " " "" " " " "
|
|
CONFIG_SAMV7_MCAN1_FFSJW=2 # " " " " " " "" " " " "
|
|
CONFIG_SAMV7_MCAN1_NSTDFILTERS=0 # Filters are not used in the loopback test
|
|
CONFIG_SAMV7_MCAN1_NEXTFILTERS=0 # " " " " " " " " "" " " " " " "
|
|
CONFIG_SAMV7_MCAN1_RXFIFO0_32BYTES=y # Each RX FIFO0 element is 32 bytes
|
|
CONFIG_SAMV7_MCAN1_RXFIFO0_SIZE=8 # There are 8 queue elements
|
|
CONFIG_SAMV7_MCAN1_RXFIFO0_32BYTES=y # Each RX FIFO1 element is 32 bytes
|
|
CONFIG_SAMV7_MCAN1_RXFIFO0_SIZE=8 # There are 8 queue elements
|
|
CONFIG_SAMV7_MCAN1_RXBUFFER_32BYTES=y # Each RX BUFFER is 32 bytes
|
|
CONFIG_SAMV7_MCAN1_TXBUFFER_32BYTES=y # Each TX BUFFER is 32 bytes
|
|
CONFIG_SAMV7_MCAN1_TXFIFOQ_SIZE=8 # There are 8 queue elements
|
|
CONFIG_SAMV7_MCAN1_TXEVENTFIFO_SIZE=0 # The event FIFO is not used
|
|
|
|
Enabling the CAN Loopback Test
|
|
------------------------------
|
|
Application Configuration -> Examples -> CAN Example
|
|
CONFIG_EXAMPLES_CAN=y # Enables the CAN test
|
|
|
|
Enabling CAN Debug Output
|
|
-------------------------
|
|
Build Setup -> Debug Options
|
|
CONFIG_DEBUG_FEATURES=y # Enables general debug features
|
|
CONFIG_DEBUG_INFO=y # Enables verbose output
|
|
CONFIG_DEBUG_CAN_INFO=y # Enables debug output from CAN
|
|
|
|
CONFIG_STACK_COLORATION=y # Monitor stack usage
|
|
CONFIG_DEBUG_SYMBOLS=y # Needed only for use with a debugger
|
|
CONFIG_DEBUG_NOOPT=y # Disables optimization
|
|
|
|
System Type -> MCAN device driver options
|
|
CONFIG_SAMV7_MCAN_REGDEBUG=y # Super low level register debug output
|
|
|
|
SPI Slave
|
|
=========
|
|
|
|
An interrutp driven SPI slave driver as added on 2015-08-09 but has not
|
|
been verified as of this writing. See discussion in include/nuttx/spi/slave.h
|
|
and below.
|
|
|
|
I do not yet have a design that supports SPI slave DMA. And, under
|
|
certain, very limited conditions, I think it can be done. Those
|
|
certain conditions are:
|
|
|
|
a) The master does not tie the chip select to ground. The master must
|
|
raise chip select at the end of the transfer. Then I do not need to
|
|
know the length of the transfer; I can cancel the DMA when the chip
|
|
is de-selected.
|
|
|
|
b) The protocol includes a dummy read after sending the command. This
|
|
is very common in SPI device and should not be an issue if it is
|
|
specified. This dummy read time provides time to set up the DMA.
|
|
So the protocol would be:
|
|
|
|
i) Master drops the chip select.
|
|
ii) Master sends the command which will indicate whether the master
|
|
is reading, writing, or exchanging data. The master discards
|
|
the garbage return value.
|
|
iii) Slave is interrupted when the command word is received. The
|
|
SPI device then decodes the command word and setups up the
|
|
subsequent DMA.
|
|
iv) Master sends a dummy word and discards the return value.
|
|
During the bit times to shift the dummy word, the slave has time
|
|
to set up the DMA.
|
|
v) Master then reads or writes (or exchanges) the data If the DMA
|
|
is in place, the transfer should continue normally.
|
|
vi) At the end of the data transfer the master raises the chip
|
|
select.
|
|
|
|
c) There are limitations in the word time, i.e., the time between the
|
|
interrupt for each word shifted in from the master.
|
|
|
|
The controller driver will get events after the receipt of each word in
|
|
ii), iv), and v). The time between each word will be:
|
|
|
|
word-time = nbits * bit time + inter-word-gap
|
|
|
|
So for an 8 bit interface at 20MHz, the words will be received from the
|
|
master a 8 * 50nsec = 400 nsec + inter-word-gap. That is the time
|
|
during which the dummy word would be shifted and during which we
|
|
receive the interrupt for the command word, interpret the command word,
|
|
and to set up the DMA for the remaining word transfer. I don't think
|
|
that is possible, at least not at 20 MHz.
|
|
|
|
That is far too fast even for the interrupt driven solution that I have
|
|
in place now. It could not work at 20MHz. If we suppose that interrupt
|
|
processing is around 1 usec, then an 8 bit interface could not have bit
|
|
times more than 125 nsec or 8 KHz. Interrupt handling should be faster
|
|
than 1 usec, but not a lot faster. I have not benchmarked it. NuttX
|
|
also supports special, zero latency interrupts that could bring the
|
|
interrupt time down even more.
|
|
|
|
Note that we would also have a little more processing time if you used
|
|
16-bit SPI word size.
|
|
|
|
Note also that the interrupt driven approach would have this same basic
|
|
performance limitation with the additional disadvantage that:
|
|
|
|
a) The driver will receive two interrupts per word exchanged:
|
|
|
|
i) One interrupt will be received when the word is shifted in from
|
|
the master (at the end of 8-bit times). This is a data received
|
|
interrupt.
|
|
|
|
ii) And another interrupt when the next words moved to the shift-out
|
|
register, freeing up the transmit holding register. This is the
|
|
data sent interrupt.
|
|
|
|
The ii) event should be very soon after the i) event.
|
|
|
|
Without DMA, the only way to reduce the interrupt rate would be to add
|
|
interrupt-level polling to detect the when transmit holding register
|
|
is available. That is not really a good idea.
|
|
|
|
b) It will hog all of the CPU for the duration of the transfer).
|
|
|
|
Click Shield
|
|
============
|
|
|
|
In the mrf24j40-starhub configuration, a click shield from
|
|
MikroElectronika was used along with a Click "Bee" module. The click
|
|
shield supports two click shields and the following tables describe the
|
|
relationship between the pins on each click shield, the Arduino
|
|
connector and the SAMV71 pins.
|
|
|
|
--------- ---------------------- -------- --------- ------------------ ----------
|
|
mikroBUS1 Arduino SAMV71 mikroBUS2 Arduino SAMV71
|
|
--------- ---------------------- -------- --------- ------------------ ----------
|
|
AN HD1 A0 AN0 Pin 1 AD0 PD26 AN HD1 A1 AN1 Pin 2 AD1 PC31
|
|
RST HD1 A3 Pin 4 AD3 PA19 RST HD1 A2 Pin 3 AD2 PD30
|
|
CS HD4 D10 SPI-SS Pin 8 D10 PD25 CS HD4 D9 Pin 9 D9 PC9
|
|
SCK HD4 D13 SPI-SCK Pin 5 D13 PD22 SCK Same
|
|
MISO HD4 D12 SPI-MISO Pin 6 D12 PD20 MISO Same
|
|
MOSI HD4 D11 SPI-MOSI Pin 7 D11 PD21 MOSI Same
|
|
3.3V N/A 3.3V N/A
|
|
GND N/A GND N/A
|
|
PWM HD3 D6 PWMA Pin 2 D6 PC19 PWM HD3 D5 PWMB Pin 5 D5 PD11
|
|
INT HD3 D2 INT0 Pin 6 D2 PA5 INT HD3 D3 INT1 Pin 5 D3 PA6
|
|
RX HD3 D0 HDR-RX* Pin 8 D0 PD28 RX Same
|
|
TX HD3 D1 HDR-TX* Pin 7 D1 PD30 TX Same
|
|
SCL HD1 A5 I2C-SCL Pin 5 AD5 PC30 SDA Same
|
|
SDA HD1 A4 I2C-SDA Pin 6 AD4 PC13 SCL Same
|
|
5V N/A 5V N/A
|
|
GND N/A GND N/A
|
|
--------- ---------------------- -------- --------- ------------------ ----------
|
|
|
|
* Depends upon setting of SW1, UART vs PROG.
|
|
|
|
--- ----- ------------------------------ ---------------------------------
|
|
PIN PORT SHIELD FUNCTION SAMV71PIN CONFIGURATION
|
|
--- ----- ------------------------------ ---------------------------------
|
|
AD0 PD26 microBUS2 Analog TD PD26 *** Not an AFE pin ***
|
|
AD1 PC31 microBUS2 Analog PC31 AFE1_AD6 GPIO_AFE1_AD6
|
|
AD2 PD30 microBUS2 GPIO reset output PD30
|
|
AD3 PA19 microBUS1 GPIO reset output PA19
|
|
AD4 PC13 (both) I2C-SDA PC13 *** Does not support I2C SDA ***
|
|
AD5 PC30 (both) I2C-SCL PC30 *** Does not support I2C SCL ***
|
|
AD6 PA17 *** Not used ***
|
|
AD7 PC12 *** Not used ***
|
|
D0 PD28 (both) HDR_RX PD28 URXD3 GPIO_UART3_RXD
|
|
D1 PD30 (both) HDR_TX PD30 UTXD3 GPIO_UART3_TXD_1
|
|
D2 PA0 microBUS1 GPIO interrupt input PA0
|
|
D3 PA6 microBUS2 GPIO interrupt input PA6
|
|
D4 PD27 *** Not used ***
|
|
D5 PD11 microBUS2 PWMB PD11 PWMC0_H0
|
|
D6 PC19 microBUS1 PWMA PC19 PWMC0_H2
|
|
D7 PA2 *** Not used ***
|
|
D8 PA5 *** Not used ***
|
|
D9 PC9 microBUS2 CS GPIO output PC9
|
|
D10 PD25 microBUS1 CS GPIO output PD25 SPI0_NPCS1
|
|
D11 PD21 (both) SPI-MOSI PD21 SPI0_MOSI GPIO_SPI0_MOSI
|
|
D12 PD20 (both) SPI-MISO PD20 SPI0_MISO GPIO_SPI0_MISO
|
|
D13 PD22 (both) SPI-SCK PD22 SPI0_SPCK GPIO_SPI0_SPCK
|
|
|
|
Tickless OS
|
|
===========
|
|
|
|
Background
|
|
----------
|
|
By default, a NuttX configuration uses a periodic timer interrupt that
|
|
drives all system timing. The timer is provided by architecture-specific
|
|
code that calls into NuttX at a rate controlled by CONFIG_USEC_PER_TICK.
|
|
The default value of CONFIG_USEC_PER_TICK is 10000 microseconds which
|
|
corresponds to a timer interrupt rate of 100 Hz.
|
|
|
|
An option is to configure NuttX to operation in a "tickless" mode. Some
|
|
limitations of default system timer are, in increasing order of
|
|
importance:
|
|
|
|
- Overhead: Although the CPU usage of the system timer interrupt at 100Hz
|
|
is really very low, it is still mostly wasted processing time. One most
|
|
timer interrupts, there is really nothing that needs be done other than
|
|
incrementing the counter.
|
|
- Resolution: Resolution of all system timing is also determined by
|
|
CONFIG_USEC_PER_TICK. So nothing that be time with resolution finer than
|
|
10 milliseconds be default. To increase this resolution,
|
|
CONFIG_USEC_PER_TICK an be reduced. However, then the system timer
|
|
interrupts use more of the CPU bandwidth processing useless interrupts.
|
|
- Power Usage: But the biggest issue is power usage. When the system is
|
|
IDLE, it enters a light, low-power mode (for ARMs, this mode is entered
|
|
with the wfi or wfe instructions for example). But each interrupt
|
|
awakens the system from this low power mode. Therefore, higher rates
|
|
of interrupts cause greater power consumption.
|
|
|
|
The so-called Tickless OS provides one solution to issue. The basic
|
|
concept here is that the periodic, timer interrupt is eliminated and
|
|
replaced with a one-shot, interval timer. It becomes event driven
|
|
instead of polled: The default system timer is a polled design. On
|
|
each interrupt, the NuttX logic checks if it needs to do anything
|
|
and, if so, it does it.
|
|
|
|
Using an interval timer, one can anticipate when the next interesting
|
|
OS event will occur, program the interval time and wait for it to fire.
|
|
When the interval time fires, then the scheduled activity is performed.
|
|
|
|
Configuration
|
|
-------------
|
|
The following configuration options will enable support for the Tickless
|
|
OS for the SAMV7 platforms using TC0 channels 0-1 (other timers or
|
|
timer channels could be used making the obvious substitutions):
|
|
|
|
RTOS Features -> Clocks and Timers
|
|
CONFIG_SCHED_TICKLESS=y : Configures the RTOS in tickless mode
|
|
CONFIG_SCHED_TICKLESS_ALARM=n : (option not implemented)
|
|
CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP=y
|
|
|
|
System Type -> SAMV7 Peripheral Support
|
|
CONFIG_SAMV7_TC0=y : Enable TC0 (TC channels 0-3
|
|
|
|
System Type -> Timer/counter Configuration
|
|
CONFIG_SAMV7_ONESHOT=y : Enables one-shot timer wrapper
|
|
CONFIG_SAMV7_FREERUN=y : Enabled free-running timer wrapper
|
|
CONFIG_SAMV7_TICKLESS_ONESHOT=0 : Selects TC0 channel 0 for the one-shot
|
|
CONFIG_SAMV7_TICKLESS_FREERUN=1 : Selects TC0 channel 1 for the free-
|
|
: running timer
|
|
|
|
The resolution of the clock is provided by the CONFIG_USEC_PER_TICK
|
|
setting in the configuration file.
|
|
|
|
NOTE: In most cases, the slow clock will be used as the timer/counter
|
|
input. The 32.768KHz crystal is selected by the definition
|
|
BOARD_HAVE_SLOWXTAL in the configs/samv71-xult/board.h file.
|
|
|
|
The slow clock has a resolution of about 30.518 microseconds. Ideally,
|
|
the value of CONFIG_USEC_PER_TICK should be the exact clock resolution.
|
|
Otherwise there will be cumulative timing inaccuracies. But a choice
|
|
choice of:
|
|
|
|
CONFIG_USEC_PER_TICK=31
|
|
|
|
will have an error of 0.6% and will have inaccuracies that will
|
|
effect the time due to long term error build-up.
|
|
|
|
Using the slow clock clock input, the Tickless support is functional,
|
|
however, there are inaccuracies in delays. For example,
|
|
|
|
nsh> sleep 10
|
|
|
|
results in a delay of maybe 5.4 seconds. But the timing accuracy is
|
|
correct if all competing uses of the interval timer are disabled (mostly
|
|
from the high priority work queue). Therefore, I conclude that this
|
|
inaccuracy is due to the inaccuracies in the representation of the clock
|
|
rate. 30.518 usec cannot be represented accurately. Each timing
|
|
calculation results in a small error. When the interval timer is very
|
|
busy, long delays will be divided into many small pieces and each small
|
|
piece has a large error in the calculation. The cumulative error is the
|
|
cause of the problem.
|
|
|
|
Solution: The samv71-xult/src/sam_boot.c file has additional logic
|
|
to enable the programmable clock PCK6 as a clock source for the
|
|
timer/counters if the Tickless mode is selected. The ideal frequency
|
|
would be:
|
|
|
|
frequency = 1,000,000 / CONFIG_USEC_PER_TICK
|
|
|
|
The main crystal is selected as the frequency source. The maximum
|
|
prescaler value is 256 so the minimum frequency is 46,875 Hz which
|
|
corresponds to a period of 21.3 microseconds. A value of
|
|
CONFIG_USEC_PER_TICK=20, or 50KHz, would give an exact solution with
|
|
a divider of 240.
|
|
|
|
SAMV7 Timer Usage
|
|
-----------------
|
|
This current implementation uses two timers: A one-shot timer to
|
|
provide the timed events and a free running timer to provide the current
|
|
time. Since timers are a limited resource, that could be an issue on
|
|
some systems.
|
|
|
|
We could do the job with a single timer if we were to keep the single
|
|
timer in a free-running at all times. The SAMV7 timer/counters have
|
|
16-bit counters with the capability to generate a compare interrupt when
|
|
the timer matches a compare value but also to continue counting without
|
|
stopping (giving another, different interrupt when the timer rolls over
|
|
from 0xffff to zero). So we could potentially just set the compare at
|
|
the number of ticks you want PLUS the current value of timer. Then you
|
|
could have both with a single timer: An interval timer and a free-
|
|
running counter with the same timer! In this case, you would want to
|
|
to set CONFIG_SCHED_TICKLESS_ALARM in the NuttX configuration.
|
|
|
|
Patches are welcome!
|
|
|
|
Debugging
|
|
=========
|
|
|
|
The on-board EDBG appears to work only with Atmel Studio. You can however,
|
|
simply connect a SAM-ICE or J-Link to the JTAG/SWD connector on the board
|
|
and that works great. The only tricky thing is getting the correct
|
|
orientation of the JTAG connection.
|
|
|
|
I have been using Atmel Studio to write code to flash then I use the Segger
|
|
J-Link GDB server to debug. I have been using the 'Device Programming'
|
|
available under the Atmel Studio 'Tool' menu. I have to disconnect the
|
|
SAM-ICE while programming with the EDBG.
|
|
|
|
You can also load code into flash directory with J-Link:
|
|
|
|
arm-none-eabi-gdb
|
|
(gdb) target remote localhost:2331
|
|
(gdb) mon reset
|
|
(gdb) mon halt
|
|
(gdb) load nuttx
|
|
|
|
I run GDB like this from the directory containing the NuttX ELF file:
|
|
|
|
arm-none-eabi-gdb
|
|
(gdb) target remote localhost:2331
|
|
(gdb) mon reset
|
|
(gdb) file nuttx
|
|
(gdb) ... start debugging ...
|
|
|
|
Configurations
|
|
==============
|
|
|
|
Information Common to All Configurations
|
|
----------------------------------------
|
|
Each SAMV71-XULT configuration is maintained in a sub-directory and
|
|
can be selected as follow:
|
|
|
|
tools/configure.sh [OPTIONS] samv71-xult/<subdir>
|
|
|
|
Where typical options are -l to configure to build on Linux or -c to
|
|
configure for Cygwin under Linux. 'tools/configure.sh -h' will show
|
|
you all of the options.
|
|
|
|
Before building, make sure the PATH environment variable include 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
|
|
|
|
The <subdir> that is provided above as an argument to the tools/configure.sh
|
|
must be is one of the following.
|
|
|
|
NOTES:
|
|
|
|
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 UART3 (i.e., for the Arduino serial shield).
|
|
|
|
3. All of these configurations are set up to build under Windows using the
|
|
"GNU Tools for ARM Embedded Processors" that is maintained by ARM
|
|
(unless stated otherwise in the description of the configuration).
|
|
|
|
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
|
|
|
|
That toolchain selection can easily be reconfigured using
|
|
'make menuconfig'. Here are the relevant current settings:
|
|
|
|
Build Setup:
|
|
CONFIG_HOST_WINDOWS=y : Window environment
|
|
CONFIG_WINDOWS_CYGWIN=y : Cywin under Windows
|
|
|
|
System Type -> Toolchain:
|
|
CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW=y : GNU ARM EABI toolchain
|
|
|
|
Configuration sub-directories
|
|
-----------------------------
|
|
|
|
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. There are four very similar NSH configurations:
|
|
|
|
- knsh. This is a somewhat simplified version of the nsh configuration
|
|
that builds using the protected build mode (CONFIG_BUILD_PROTECTED=y).
|
|
- nsh. This configuration is focused on low level, command-line
|
|
driver testing. It has no network.
|
|
- netnsh. This configuration is focused on network testing and
|
|
has only limited command support.
|
|
- mxtxplnd. This configuration is identical to the nsh configuration
|
|
but assumes that you have a maXTouch Xplained Pro LCD attached
|
|
and includes extra tests for the touchscreen and LCD.
|
|
|
|
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. 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. 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.
|
|
|
|
2. 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.
|
|
If you do this a lot, you will probably want to invest a little time
|
|
to develop a tool to automate these steps.
|
|
|
|
module:
|
|
|
|
A simple stripped down configuration that was used for testing NuttX
|
|
OS modules. There are five
|
|
very similar NSH configurations:
|
|
|
|
- knsh. This is a somewhat simplified version of the nsh configuration
|
|
that builds using the protected build mode (CONFIG_BUILD_PROTECTED=y).
|
|
- nsh. This configuration is focused on low level, command-line
|
|
driver testing. It has no network.
|
|
- netnsh. This configuration is focused on network testing and
|
|
has only limited command support.
|
|
- module. A simple stripped down configuration that was used for testing
|
|
NuttXOS modules.
|
|
- mxtxplnd. This configuration is identical to the nsh configuration
|
|
but assumes that you have a maXTouch Xplained Pro LCD attached
|
|
and includes extra tests for the touchscreen and LCD.
|
|
|
|
NOTES:
|
|
|
|
1. Kernel Modules / Shared Libraries
|
|
|
|
I intend to use 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_BINDIR="/mnt/sdcard"
|
|
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_DLLFCN=y
|
|
CONFIG_EXAMPLES_SOTEST=y
|
|
CONFIG_EXAMPLES_SOTEST_BINDIR="/mnt/sdcard"
|
|
|
|
STATUS:
|
|
2017-01-30: Does not yet run correctly.
|
|
|
|
mrf24j40-starhub
|
|
|
|
This configuration implement a hub node in a 6LoWPAN start network.
|
|
It is intended for the us the mrf24j40-starpoint configuration with
|
|
the clicker2-stm32 configurations. Essentially, the SAMV71-XULT
|
|
plays the roll of the hub in the configuration and the clicker2-stm32
|
|
boards are the endpoints in the start.
|
|
|
|
NOTES:
|
|
1. The serial console is configured by default for use with and Arduino
|
|
serial shield (UART3). You will need to reconfigure if you will
|
|
to use a different U[S]ART.
|
|
|
|
2. This configuration derives from the netnsh configuration, but adds
|
|
support for IPv6, 6LoWPAN, and the MRF24J40 IEEE 802.15.4 radio.
|
|
|
|
3. This configuration uses the Mikroe BEE MRF24j40 click boards and
|
|
connects to the SAMV71-XULT using a click shield as described above.
|
|
|
|
4. You must must have also have at least two clicker2-stm32 boards each
|
|
with an MRF24J40 BEE click board in order to run these tests.
|
|
|
|
5. The network initialization thread is NOT enabled. As a result, the
|
|
startup will hang if the Ethernet cable is not plugged in. For more
|
|
information, see the paragraphs above entitled "Network Initialization
|
|
Thread" and "Network Monitor".
|
|
|
|
6. This configuration supports logging of debug output to a circular
|
|
buffer in RAM. This feature is discussed fully in this Wiki page:
|
|
http://nuttx.org/doku.php?id=wiki:howtos:syslog . Relevant
|
|
configuration settings are summarized below:
|
|
|
|
Device Drivers:
|
|
CONFIG_RAMLOG=y : Enable the RAM-based logging feature.
|
|
CONFIG_RAMLOG_CONSOLE=n : (We don't use the RAMLOG console)
|
|
CONFIG_RAMLOG_SYSLOG=y : This enables the RAM-based logger as the
|
|
system logger.
|
|
CONFIG_RAMLOG_NONBLOCKING=y : Needs to be non-blocking for dmesg
|
|
CONFIG_RAMLOG_BUFSIZE=8192 : Buffer size is 8KiB
|
|
|
|
NOTE: This RAMLOG feature is really only of value if debug output
|
|
is enabled. But, by default, no debug output is disabled in this
|
|
configuration. Therefore, there is no logic that will add anything
|
|
to the RAM buffer. This feature is configured and in place only
|
|
to support any future debugging needs that you may have.
|
|
|
|
If you don't plan on using the debug features, then by all means
|
|
disable this feature and save 8KiB of RAM!
|
|
|
|
NOTE: There is an issue with capturing data in the RAMLOG: If
|
|
the system crashes, all of the crash dump information will go into
|
|
the RAMLOG and you will be unable to access it! You can tell that
|
|
the system has crashed because (a) it will be unresponsive and (b)
|
|
the LD2 will be blinking at about 2Hz.
|
|
|
|
You can also reconfigure to use stdout for debug output be disabling
|
|
all of the CONFIG_RAMLOG* settings listed above and enabling the
|
|
following in the .config file:
|
|
|
|
CONFIG_SYSLOG_CONSOLE=y
|
|
CONFIG_SYSLOG_SERIAL_CONSOLE=y
|
|
|
|
7. Telnet: The clicker2-stm32 star point configuration supports the
|
|
Telnet daemon, but not the Telnet client; the star hub configuration
|
|
supports the Telnet client, but not the Telnet daemon. Therefore,
|
|
the star hub can Telnet to any point in the star, the star endpoints
|
|
cannot initiate telnet sessions.
|
|
|
|
8. TCP and UDP Tests: The same TCP and UDP tests as described for
|
|
the clicker2-stm32 mrf24j40-starpoint configuration are supported on
|
|
the star endpoints, but NOT on the star hub. Therefore, all network
|
|
testing is between endpoints with the hub acting, well, only like a
|
|
hub.
|
|
|
|
The nsh> dmesg command can be use at any time on any node to see
|
|
any debug output that you have selected.
|
|
|
|
Telenet sessions may be initiated only from the hub to a star
|
|
endpoint:
|
|
|
|
C: nsh> telnet <server-ip> <-- Runs the Telnet client
|
|
|
|
Where <server-ip> is the IP address of either the E1 or I2 endpoints.
|
|
|
|
STATUS:
|
|
2017-07-02: Configurations added. Not yet tested.
|
|
|
|
2017-07-03: Initial testing, appears to be working, but endpoints
|
|
fail to associate; sniffer shows that nothing sent fro the star
|
|
hub. I am thinking that there is something wrong with the
|
|
GPIO interrupt configuration so that no MRF24J40 interrupt are
|
|
being received.
|
|
|
|
2017-08-15: I think the GPIO interrupts are fixed but there still
|
|
seems to be some issue with the SPI communications.
|
|
|
|
2017-08-16: I believe that there is something interfering with the
|
|
MRF24J40 on the SPI0. There are other things on the bus. The
|
|
MRF24J40 requires sole use of the SPI bus because it holds MISO
|
|
low when not selected.
|
|
|
|
I successfully brought the same logic up on the SAME70-Xplained.
|
|
The SPI signals look clean on the board and the MRF24J40 seems
|
|
fully functional.
|
|
|
|
2017-08-26: There was only a single buffer for reassemblying larger
|
|
packets. This could be a problem issue for the hub configuration
|
|
which really needs the capability concurrently reassemble multiple
|
|
incoming streams. The design was extended to support multiple
|
|
reassembly buffers but additional testing is needed.
|
|
|
|
mxtxplnd:
|
|
|
|
Configures the NuttShell (nsh) located at examples/nsh. There are five
|
|
very similar NSH configurations:
|
|
|
|
- knsh. This is a somewhat simplified version of the nsh configuration
|
|
that builds using the protected build mode (CONFIG_BUILD_PROTECTED=y).
|
|
- nsh. This configuration is focused on low level, command-line
|
|
driver testing. It has no network.
|
|
- netnsh. This configuration is focused on network testing and
|
|
has only limited command support.
|
|
- module. A simple stripped down configuration that was used for testing
|
|
NuttXOS modules.
|
|
- mxtxplnd. This configuration is identical to the nsh configuration
|
|
but assumes that you have a maXTouch Xplained Pro LCD attached
|
|
and includes extra tests for the touchscreen and LCD.
|
|
|
|
NOTES:
|
|
|
|
1. See the notes associated with the nsh configuration below. Only
|
|
differences from that configuration will be addressed here.
|
|
|
|
2. Basic touchscreen/LCD configuration settings are discussed above in
|
|
the paragraph entitled, "maXTouch Xplained Pro".
|
|
|
|
3. Unlike the nsh configuration, this configuration has the serial console
|
|
setup to USART0 which is available on EXT1:
|
|
|
|
----------- --- ------- -----
|
|
Connector PIO Arduino SAMV7
|
|
----------- --- ------- -----
|
|
EXT1 pin 13 PB0 RX3 RXD0
|
|
EXT1 pin 14 PB1 TX3 TXD0
|
|
----------- --- ------- -----
|
|
|
|
and also on the Arduino Communications connector (J505):
|
|
|
|
----------- --- ------- -----
|
|
Connector PIO Arduino SAMV7
|
|
----------- --- ------- -----
|
|
J505 pin 7 PB0 RX3 RXD0
|
|
J505 pin 8 PB1 TX3 TXD0
|
|
----------- --- ------- -----
|
|
|
|
Use of either the EXT1 or the LCD/EXT4 connectors conflict with the
|
|
Arduino RXD pin (UART3, PD28). You cannot put the maXTouch Xplained
|
|
in EXT1 or LCD/EXT4 and also use the Arduino RXD/TXD pins as your
|
|
serial console.
|
|
|
|
The LCD (EXT4) is configured by default because only the parallel LCD
|
|
interface is currently supported and that is only available on that
|
|
connector.
|
|
|
|
If you plan to use EXT2 for some reason, you may re-configure the
|
|
serial console to use UART3, the standard Arduino RXD/TXD. You
|
|
would also, of course, have to disable the LCD.
|
|
|
|
NOTE that the USART0 pins PB0 and PB1 conflict with SSC TF and TK
|
|
pins as connected to the WM8904 audio CODEC. So, unless yet a
|
|
different U[S]ART option is selected, Audio cannot be used with
|
|
this configuration.
|
|
|
|
4. SDRAM is NOT enabled in this configuration.
|
|
|
|
5. Support for the ILI8488 LCD is enabled. Only the parallel mode is
|
|
supported at present. As a consequence, the maXTouch Xplained Pro
|
|
must be connected at the LCD (EXT4) connector. This mode requires:
|
|
|
|
CONFIG_SAMV71XULT_MXTXPLND_LCD=y : Must be connect in LCD (EXT4)
|
|
CONFIG_SAMV7_SMC=y : SMC/EBI support
|
|
CONFIG_SAMV7_XDMAC=y : XDMAC support
|
|
|
|
6. The appx/examples/nxlines is enabled as a built-in application.
|
|
This is a test that displays some simple graphis and can be
|
|
executed from the NSH command line like:
|
|
|
|
nsh> nxlines
|
|
|
|
7. When the maXTouch Xplained is connected (in any position), a new I2C
|
|
address appears at address 0x4a:
|
|
|
|
nsh> i2c dev 3 77
|
|
0 1 2 3 4 5 6 7 8 9 a b c d e f
|
|
00: -- -- -- -- -- -- -- -- -- -- -- -- --
|
|
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- --
|
|
20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- --
|
|
30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- --
|
|
40: -- -- -- -- -- -- -- -- -- -- 4a -- -- -- 4e --
|
|
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- 5f
|
|
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
|
70: -- -- -- -- -- -- -- --
|
|
|
|
This is the I2C address of the maXTouch touchscreen controller.
|
|
|
|
(0x1a is the address of the WM8904 Audio CODEC, 0x28 is the
|
|
address of TWI interface to the EDBG, 0x4e is the address of the
|
|
CP2100CP programmable PLL, and 0x57 and 0x5f are the addresses of
|
|
the AT2 EEPROM. I am not sure what the other address, 0x37, is).
|
|
|
|
8. Support for the touchscreen test is enabled (see apps/examples/touchscreen),
|
|
however, the maXTouch is not yet working (see STATUS below).
|
|
|
|
STATUS:
|
|
2015-04-05: Partial support for the maXTouch Xplained Pro LCD is in
|
|
place. The ILI9488-based LCD is working well with a SMC DMA-based
|
|
interface. Very nice performance.
|
|
2015-05-12: After some difficulties, the maXTouch touchscreen
|
|
controller is now fully functional as well.
|
|
|
|
netnsh:
|
|
|
|
Configures the NuttShell (nsh) located at examples/nsh. There are five
|
|
very similar NSH configurations:
|
|
|
|
- knsh. This is a somewhat simplified version of the nsh configuration
|
|
that builds using the protected build mode (CONFIG_BUILD_PROTECTED=y).
|
|
- nsh. This configuration is focused on low level, command-line
|
|
driver testing. It has no network.
|
|
- netnsh. This configuration is focused on network testing and
|
|
has only limited command support.
|
|
- module. A simple stripped down configuration that was used for testing
|
|
NuttXOS modules.
|
|
- mxtxplnd. This configuration is identical to the nsh configuration
|
|
but assumes that you have a maXTouch Xplained Pro LCD attached
|
|
and includes extra tests for the touchscreen and LCD.
|
|
|
|
NOTES:
|
|
|
|
1. The serial console is configured by default for use with and Arduino
|
|
serial shield (UART3). You will need to reconfigure if you will
|
|
to use a different U[S]ART.
|
|
|
|
2. Default stack sizes are large and should really be tuned to reduce
|
|
the RAM footprint:
|
|
|
|
CONFIG_SCHED_HPWORKSTACKSIZE=2048
|
|
CONFIG_IDLETHREAD_STACKSIZE=1024
|
|
CONFIG_USERMAIN_STACKSIZE=2048
|
|
CONFIG_PTHREAD_STACK_MIN=256
|
|
CONFIG_PTHREAD_STACK_DEFAULT=2048
|
|
CONFIG_POSIX_SPAWN_PROXY_STACKSIZE=1024
|
|
CONFIG_TASK_SPAWN_DEFAULT_STACKSIZE=2048
|
|
CONFIG_BUILTIN_PROXY_STACKSIZE=1024
|
|
CONFIG_NSH_TELNETD_DAEMONSTACKSIZE=2048
|
|
CONFIG_NSH_TELNETD_CLIENTSTACKSIZE=2048
|
|
|
|
3. NSH built-in applications are supported. There are, however, not
|
|
enabled built-in applications.
|
|
|
|
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. The network initialization thread and the NSH network montior are
|
|
enabled in this configuration. As a result, networking initialization
|
|
is performed asynchronously with NSH bring-up. For more information,
|
|
see the paragraphs above entitled "Network Initialization Thread" and
|
|
"Network Monitor".
|
|
|
|
5. SDRAM is NOT enabled in this configuration.
|
|
|
|
6. TWI/I2C
|
|
|
|
TWIHS0 is enabled in this configuration. The SAM V71 Xplained Ultra
|
|
supports two devices on the one on-board I2C device on the TWIHS0 bus:
|
|
(1) The AT24MAC402 serial EEPROM described above and (2) the Wolfson
|
|
WM8904 audio CODEC. This device contains a MAC address for use with
|
|
the Ethernet interface.
|
|
|
|
Relevant configuration settings:
|
|
|
|
CONFIG_SAMV7_TWIHS0=y
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
CONFIG_I2C=y
|
|
|
|
7. TWIHS0 is used to support 256 byte non-volatile storage. This EEPROM
|
|
holds the assigned MAC address which is necessary for networking. The
|
|
EEPROM is also available for storage of configuration data using the
|
|
MTD configuration as described above under the heading, "MTD
|
|
Configuration Data".
|
|
|
|
8. Support for HSMCI is built-in by default. The SAMV71-XULT provides
|
|
one full-size SD memory card slot. Refer to the section entitled
|
|
"SD card" for configuration-related information.
|
|
|
|
See "Open Issues" above for issues related to HSMCI.
|
|
|
|
The auto-mounter is not enabled. See the section above entitled
|
|
"Auto-Mounter".
|
|
|
|
9. Performance-related Configuration settings:
|
|
|
|
CONFIG_ARMV7M_ICACHE=y : Instruction cache is enabled
|
|
CONFIG_ARMV7M_DCACHE=y : Data cache is enabled
|
|
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=y : Write through mode
|
|
CONFIG_ARCH_FPU=y : H/W floating point support is enabled
|
|
CONFIG_ARCH_DPFPU=y : 64-bit H/W floating point support is enabled
|
|
|
|
# CONFIG_ARMV7M_ITCM is not set : Support not yet in place
|
|
# CONFIG_ARMV7M_DTCM is not set : Support not yet in place
|
|
|
|
I- and D-Caches are enabled but the D-Cache must be enabled in write-
|
|
through mode. This is to work around issues with the RX and TX
|
|
descriptors with are 8-bytes in size. But the D-Cache cache line
|
|
size is 32-bytes. That means that you cannot reload, clean or
|
|
invalidate a descriptor without also effecting three neighboring
|
|
descriptors. Setting write through mode eliminates the need for
|
|
cleaning the D-Cache. If only reloading and invalidating are done,
|
|
then there is no problem.
|
|
|
|
Stack sizes are also large to simplify the bring-up and should be
|
|
tuned for better memory usages.
|
|
|
|
STATUS:
|
|
2015-03-29: I- and D-caches are currently enabled, but as noted
|
|
above, the D-Cache must be enabled in write-through mode. Also -Os
|
|
optimization is not being used (-O2). If the cache is enabled in
|
|
Write-Back mode or if higher levels of optimization are enabled, then
|
|
there are failures when trying to ping the target from a host.
|
|
|
|
nsh:
|
|
|
|
Configures the NuttShell (nsh) located at examples/nsh. There are five
|
|
very similar NSH configurations:
|
|
|
|
- knsh. This is a somewhat simplified version of the nsh configuration
|
|
that builds using the protected build mode (CONFIG_BUILD_PROTECTED=y).
|
|
- nsh. This configuration is focused on low level, command-line
|
|
driver testing. It has no network.
|
|
- netnsh. This configuration is focused on network testing and
|
|
has only limited command support.
|
|
- module. A simple stripped down configuration that was used for testing
|
|
NuttXOS modules.
|
|
- mxtxplnd. This configuration is identical to the nsh configuration
|
|
but assumes that you have a maXTouch Xplained Pro LCD attached
|
|
and includes extra tests for the touchscreen and LCD.
|
|
|
|
NOTES:
|
|
|
|
1. The serial console is configured by default for use with and Arduino
|
|
serial shield (UART3). You will need to reconfigure if you will
|
|
to use a different U[S]ART.
|
|
|
|
2. Default stack sizes are large and should really be tuned to reduce
|
|
the RAM footprint:
|
|
|
|
CONFIG_ARCH_INTERRUPTSTACK=2048
|
|
CONFIG_IDLETHREAD_STACKSIZE=1024
|
|
CONFIG_USERMAIN_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. SDRAM is enabled in this configuration. Here are the relevant
|
|
configuration settings:
|
|
|
|
System Type
|
|
CONFIG_SAMV7_SDRAMC=y
|
|
CONFIG_SAMV7_SDRAMSIZE=2097152
|
|
|
|
SDRAM is not added to the heap in this configuration. To do that
|
|
you would need to set CONFIG_SAMV7_SDRAMHEAP=y and CONFIG_MM_REGIONS=2.
|
|
Instead, the SDRAM is set up so that is can be used with a destructive
|
|
RAM test enabled with this option:
|
|
|
|
Application Configuration:
|
|
CONFIG_SYSTEM_RAMTEST=y
|
|
|
|
The RAM test can be executed as follows:
|
|
|
|
nsh> ramtest -w 70000000 2097152
|
|
|
|
NuttShell (NSH) NuttX-7.8
|
|
nsh> ramtest -w 70000000 2097152
|
|
RAMTest: Marching ones: 70000000 2097152
|
|
RAMTest: Marching zeroes: 70000000 2097152
|
|
RAMTest: Pattern test: 70000000 2097152 55555555 aaaaaaaa
|
|
RAMTest: Pattern test: 70000000 2097152 66666666 99999999
|
|
RAMTest: Pattern test: 70000000 2097152 33333333 cccccccc
|
|
RAMTest: Address-in-address test: 70000000 2097152
|
|
nsh>
|
|
|
|
5. TWI/I2C
|
|
|
|
TWIHS0 is enabled in this configuration. The SAM V71 Xplained Ultra
|
|
supports two devices on the one on-board I2C device on the TWIHS0 bus:
|
|
(1) The AT24MAC402 serial EEPROM described above and (2) the Wolfson
|
|
WM8904 audio CODEC. This device contains a MAC address for use with
|
|
the Ethernet interface.
|
|
|
|
In this configuration, the I2C tool at apps/system/i2ctool is
|
|
enabled. This tools supports interactive access to I2C devices on
|
|
the enabled TWIHS bus. Relevant configuration settings:
|
|
|
|
CONFIG_SAMV7_TWIHS0=y
|
|
CONFIG_SAMV7_TWIHS0_FREQUENCY=100000
|
|
|
|
CONFIG_I2C=y
|
|
|
|
CONFIG_SYSTEM_I2CTOOL=y
|
|
CONFIG_I2CTOOL_MINBUS=0
|
|
CONFIG_I2CTOOL_MAXBUS=0
|
|
CONFIG_I2CTOOL_MINADDR=0x03
|
|
CONFIG_I2CTOOL_MAXADDR=0x77
|
|
CONFIG_I2CTOOL_MAXREGADDR=0xff
|
|
CONFIG_I2CTOOL_DEFFREQ=400000
|
|
|
|
Example usage:
|
|
|
|
nsh> i2c
|
|
Usage: i2c <cmd> [arguments]
|
|
Where <cmd> is one of:
|
|
|
|
Show help : ?
|
|
List busses : bus
|
|
List devices : dev [OPTIONS] <first> <last>
|
|
Read register : get [OPTIONS] [<repititions>]
|
|
Show help : help
|
|
Write register: set [OPTIONS] <value> [<repititions>]
|
|
Verify access : verf [OPTIONS] [<value>] [<repititions>]
|
|
|
|
Where common "sticky" OPTIONS include:
|
|
[-a addr] is the I2C device address (hex). Default: 03 Current: 03
|
|
[-b bus] is the I2C bus number (decimal). Default: 0 Current: 0
|
|
[-r regaddr] is the I2C device register address (hex). Default: 00 Current: 00
|
|
[-w width] is the data width (8 or 16 decimal). Default: 8 Current: 8
|
|
[-s|n], send/don't send start between command and data. Default: -n Current: -n
|
|
[-i|j], Auto increment|don't increment regaddr on repititions. Default: NO Current: NO
|
|
[-f freq] I2C frequency. Default: 400000 Current: 400000
|
|
|
|
NOTES:
|
|
o An environment variable like $PATH may be used for any argument.
|
|
o Arguments are "sticky". For example, once the I2C address is
|
|
specified, that address will be re-used until it is changed.
|
|
|
|
WARNING:
|
|
o The I2C dev command may have bad side effects on your I2C devices.
|
|
Use only at your own risk.
|
|
nsh> i2c bus
|
|
BUS EXISTS?
|
|
Bus 0: YES
|
|
nsh> i2c dev 3 77
|
|
0 1 2 3 4 5 6 7 8 9 a b c d e f
|
|
00: -- -- -- -- -- -- -- -- -- -- -- -- --
|
|
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- --
|
|
20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- --
|
|
30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- --
|
|
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e --
|
|
50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- 5f
|
|
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
|
70: -- -- -- -- -- -- -- --
|
|
nsh>
|
|
|
|
Where 0x1a is the address of the WM8904 Audio CODEC, 0x28 is the
|
|
address of TWI interface to the EDBG, 0x4e is the address of the
|
|
CP2100CP programmable PLL, and 0x57 and 0x5f are the addresses of
|
|
the AT2 EEPROM (I am not sure what the other address, 0x37, is
|
|
as this writing).
|
|
|
|
6. TWIHS0 is also used to support 256 byte non-volatile storage for
|
|
configuration data using the MTD configuration as described above
|
|
under the heading, "MTD Configuration Data".
|
|
|
|
7. Support for HSMCI is built-in by default. The SAMV71-XULT provides
|
|
one full-size SD memory card slot. Refer to the section entitled
|
|
"SD card" for configuration-related information.
|
|
|
|
See "Open Issues" above for issues related to HSMCI.
|
|
|
|
The auto-mounter is not enabled. See the section above entitled
|
|
"Auto-Mounter".
|
|
|
|
8. Performance-related Configuration settings:
|
|
|
|
CONFIG_ARMV7M_ICACHE=y : Instruction cache is enabled
|
|
CONFIG_ARMV7M_DCACHE=y : Data cache is enabled
|
|
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=n : Write back mode
|
|
CONFIG_ARCH_FPU=y : H/W floating point support is enabled
|
|
CONFIG_ARCH_DPFPU=y : 64-bit H/W floating point support is enabled
|
|
|
|
# CONFIG_ARMV7M_ITCM is not set : Support not yet in place
|
|
# CONFIG_ARMV7M_DTCM is not set : Support not yet in place
|
|
|
|
Stack sizes are also large to simplify the bring-up and should be
|
|
tuned for better memory usages.
|
|
|
|
STATUS:
|
|
2015-03-28: HSMCI TX DMA is disabled. There are some issues with the TX
|
|
DMA that need to be corrected.
|
|
|
|
nxwm:
|
|
|
|
This is a special configuration setup for the NxWM window manager
|
|
UnitTest. It provides an interactive windowing experience with the
|
|
maXTouch Xplained Pro LCD.
|
|
|
|
NOTES:
|
|
|
|
1. 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 here:
|
|
|
|
NxWidgets/nxwm
|
|
|
|
The NxWM unit test can be found at:
|
|
|
|
NxWidgets/UnitTests/nxwm
|
|
|
|
Documentation for installing the NxWM unit test can be found here:
|
|
|
|
NxWidgets/UnitTests/README.txt
|
|
|
|
2. Here is the quick summary of the build steps. These steps assume
|
|
that you have the entire NuttX GIT in some directory HOME. You may
|
|
have these components installed elsewhere. In that case, you
|
|
will need to adjust all of the paths in the following accordingly:
|
|
|
|
a. Install the VNC nxwm configuration
|
|
|
|
$ tools/configure.sh samv71-xult/vnc
|
|
|
|
b. Make the build context (only)
|
|
|
|
$ make context
|
|
|
|
c. Install the nxwm unit test
|
|
|
|
$ cd HOME/NxWidgets
|
|
$ tools/install.sh HOME/apps nxwm
|
|
Creating symbolic link
|
|
- To HOME/NxWidgets/UnitTests/nxwm
|
|
- At HOME/apps/external
|
|
|
|
d. Build the NxWidgets library
|
|
|
|
$ cd HOME/NxWidgets/libnxwidgets
|
|
$ make TOPDIR=HOME/nuttx
|
|
...
|
|
|
|
e. Build the NxWM library
|
|
|
|
$ cd HOME/NxWidgets/nxwm
|
|
$ make TOPDIR=HOME/nuttx
|
|
...
|
|
|
|
f. Built NuttX with the installed unit test as the application
|
|
|
|
$ cd HOME/nuttx
|
|
$ make
|
|
|
|
3. Reading from the LCD is not currently functional. The following
|
|
settings are in the configuration that tell the system that this
|
|
is a read-only LCD:
|
|
|
|
CONFIG_LCD_NOGETRUN=y
|
|
CONFIG_NX_WRITEONLY=y
|
|
|
|
4. Small Icons are selected and can be very difficult to touch. You
|
|
might want to enable larger icons with:
|
|
|
|
CONFIG_NXWM_LARGE_ICONS=y
|
|
|
|
STATUS:
|
|
2015-05-13:
|
|
- The demo functions and produces displays but is not yet very stable.
|
|
|
|
- I have two maXTouch Xplained Pro displays. One works well, the
|
|
other has some issues which I suspect are due to the ribbon cable
|
|
connector with fits too snugly on one side.
|
|
|
|
Here are the symptoms of the LCD that does not work. I attribute
|
|
these problems with problems in the parallel interface due to a
|
|
bad connection:
|
|
|
|
- The color is wrong; to reddish. This suggests some issue with color
|
|
format or pixel width
|
|
- Images are positioned correctly on the display, but all half the
|
|
horizontal width that they should be, again suggesting some problem
|
|
with the pixel with.
|
|
- Some images are simply truncated to half the correct size (such as
|
|
the touch circles in the calibration screen).
|
|
- Other images are horizontally compressed (such as the initial NX
|
|
logo on the background).
|
|
|
|
- As mentioned above, reading fromthe LCD is not currently functional.
|
|
There are some special settings work work around this but the
|
|
bottom line is that transparent operations cannot yet be supported.
|
|
|
|
- I am seeing some small artifacts with the font used in the HEX
|
|
calculator display.
|
|
|
|
- Line spacing in the NxTerm window is too much. This is probably
|
|
a font-related issue too.
|
|
|
|
vnc:
|
|
|
|
This is a special version of an NSH configuration. It has networking
|
|
and graphics enabled. It is configured to use the VNC server to provide
|
|
a remote desktop for use with VNC client on a PC. It includes the
|
|
graphics text at apps/examples/nximage.
|
|
|
|
NOTES:
|
|
|
|
1. Network configuration: IP address 10.0.0.2. The is easily changed
|
|
via 'make menuconfig'. The VNC server address is 10.0.0.2:5900.
|
|
|
|
2. The default (local) framebuffer configuration is 320x240 with 8-bit
|
|
RGB color.
|
|
|
|
3. There are complicated interactions between VNC and the network
|
|
configuration. The CONFIG_VNCSERVER_UPDATE_BUFSIZE determines the
|
|
size of update messages. That is 1024 bytes in that configuration
|
|
(the full message with the header will be a little larger). The
|
|
CONFIG_NET_ETH_PKTSIZE is set to 590 so that a full update will
|
|
require several packets.
|
|
|
|
Write buffering also effects network performance. This will break
|
|
up the large updates into small (196 byte) groups. When we run out
|
|
of read-ahead buffers, then partial updates may be sent causing a
|
|
loss of synchronization.
|
|
|
|
4. Hint: If you are debugging using the RealVNC clint, turn off all
|
|
mouse/keyboard inputs in the options/input menu. That will make
|
|
things a little clearer.
|
|
|
|
5. To select 16-bits per pixel RGB15 5:6:5
|
|
|
|
CONFIG_NX_DISABLE_8BPP=y
|
|
# CONFIG_NX_DISABLE_16BPP is not set
|
|
|
|
# CONFIG_VNCSERVER_COLORFMT_RGB8 is not set
|
|
CONFIG_VNCSERVER_COLORFMT_RGB16=y
|
|
|
|
CONFIG_EXAMPLES_NXIMAGE_BPP=16
|
|
|
|
To re-select 8-bits per pixel RGB8 3:3:2
|
|
|
|
# CONFIG_NX_DISABLE_8BPP is not set
|
|
CONFIG_NX_DISABLE_16BPP=y
|
|
|
|
CONFIG_VNCSERVER_COLORFMT_RGB8=y
|
|
# CONFIG_VNCSERVER_COLORFMT_RGB16 is not set
|
|
|
|
# CONFIG_EXAMPLES_NXIMAGE_GREYSCALE is not set
|
|
CONFIG_EXAMPLES_NXIMAGE_BPP=8
|
|
|
|
STATUS:
|
|
2016-04-21: I have gotten the apps/examples/nximage to work with
|
|
lots issues with 16-bit RGB and verbose GRAPHICS and UPDATER debug
|
|
ON. There are reliability problems and it hangs at the end of the
|
|
test.
|
|
|
|
2016-04-22: The default configuration now uses RGB8 which needs a lot
|
|
less SRAM for the local frame buffer and does not degrade the color
|
|
quality in the remote display (since it is also 8 BPP). At 8
|
|
BPP, the remote display is correct even with both GRAPHICS and
|
|
UPDATER debug OFF -- and there is no hang!
|
|
|
|
2106-04-23: The NxImage test was selected because it is a very simple
|
|
graphics test. Continued testing, however, requires a more complex
|
|
configuration. Hence, the vnxwm configuration was created.
|
|
|
|
A memory clobber error was fixed and this probably corrects some of
|
|
the reliability problems noted on 2016-04-21.
|
|
|
|
vnxwm:
|
|
|
|
This is a special configuration setup for the NxWM window manager
|
|
UnitTest. It provides an interactive windowing experience via a remote
|
|
VNC client window running on your PC. The SAMV71-XULT is connected to
|
|
the PC via Ethernet.
|
|
|
|
NOTES:
|
|
|
|
1. 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 here:
|
|
|
|
NxWidgets/nxwm
|
|
|
|
The NxWM unit test can be found at:
|
|
|
|
NxWidgets/UnitTests/nxwm
|
|
|
|
Documentation for installing the NxWM unit test can be found here:
|
|
|
|
NxWidgets/UnitTests/README.txt
|
|
|
|
2. Here is the quick summary of the build steps. These steps assume
|
|
that you have the entire NuttX GIT in some directory HOME. You may
|
|
have these components installed elsewhere. In that case, you
|
|
will need to adjust all of the paths in the following accordingly:
|
|
|
|
a. Install the nxwm configuration
|
|
|
|
$ tools/configure.sh samv71-xult/nxwm
|
|
|
|
b. Make the build context (only)
|
|
|
|
$ make context
|
|
|
|
c. Install the nxwm unit test
|
|
|
|
$ cd HOME/NxWidgets
|
|
$ tools/install.sh HOME/apps nxwm
|
|
Creating symbolic link
|
|
- To HOME/NxWidgets/UnitTests/nxwm
|
|
- At HOME/apps/external
|
|
|
|
d. Build the NxWidgets library
|
|
|
|
$ cd HOME/NxWidgets/libnxwidgets
|
|
$ make TOPDIR=HOME/nuttx
|
|
...
|
|
|
|
e. Build the NxWM library
|
|
|
|
$ cd HOME/NxWidgets/nxwm
|
|
$ make TOPDIR=HOME/nuttx
|
|
...
|
|
|
|
f. Built NuttX with the installed unit test as the application
|
|
|
|
$ cd HOME/nuttx
|
|
$ make
|
|
|
|
3. Network configuration: IP address 10.0.0.2. The is easily changed
|
|
via 'make menuconfig'. The VNC server address is 10.0.0.2:5900.
|
|
|
|
4. The default (local) framebuffer configuration is 320x240 with 8-bit
|
|
RGB color.
|
|
|
|
I had some problems at 16-bits per pixle (see STATUS below). To
|
|
select 16-bits per pixel RGB15 5:6:5
|
|
|
|
CONFIG_NX_DISABLE_8BPP=y
|
|
# CONFIG_NX_DISABLE_16BPP is not set
|
|
|
|
# CONFIG_VNCSERVER_COLORFMT_RGB8 is not set
|
|
CONFIG_VNCSERVER_COLORFMT_RGB16=y
|
|
|
|
CONFIG_EXAMPLES_NXIMAGE_BPP=16
|
|
|
|
To re-select 8-bits per pixel RGB8 3:3:2
|
|
|
|
# CONFIG_NX_DISABLE_8BPP is not set
|
|
CONFIG_NX_DISABLE_16BPP=y
|
|
|
|
CONFIG_VNCSERVER_COLORFMT_RGB8=y
|
|
# CONFIG_VNCSERVER_COLORFMT_RGB16 is not set
|
|
|
|
# CONFIG_EXAMPLES_NXIMAGE_GREYSCALE is not set
|
|
CONFIG_EXAMPLES_NXIMAGE_BPP=8
|
|
|
|
5. There are complicated interactions between VNC and the network
|
|
configuration. The CONFIG_VNCSERVER_UPDATE_BUFSIZE determines the
|
|
size of update messages. That is 1024 bytes in that configuration
|
|
(the full message with the header will be a little larger). The
|
|
CONFIG_NET_ETH_PKTSIZE is set to 590 so that a full update will
|
|
require several packets.
|
|
|
|
Write buffering also effects network performance. This will break
|
|
up the large updates into small (196 byte) groups. When we run out
|
|
of read-ahead buffers, then partial updates may be sent causing a
|
|
loss of synchronization.
|
|
|
|
STATUS:
|
|
2106-04-23: Configuration created. See status up to this data in
|
|
the vnc configuration. That probably all applies here as well.
|
|
|
|
Only some initial testing has been performed: The configuration
|
|
is partially functional. Menus do appear and mouse input is
|
|
probably working correctly.
|
|
|
|
But there are a lot of instabilities. I see assertions of
|
|
various kinds and the RealVNC client often crashes as well.
|
|
Some of the assertions I see are:
|
|
|
|
while (sem_wait(&session->queuesem) < 0)
|
|
...
|
|
rect = (FAR struct vnc_fbupdate_s *)sq_remfirst(&session->updqueue);
|
|
DEBUGASSERT(rect != NULL);
|
|
|
|
I would think that could mean only that the semaphore counting is
|
|
out of sync with the number of updates in the queue.
|
|
|
|
But also the assertion at devif/devif_iobsend.c line: 102 which
|
|
probably means some kind of memory corruption.
|
|
|
|
2017-01-30: knsh configuration does not yet run correctly.
|