diff --git a/ChangeLog b/ChangeLog index 5f27953c96..19a0bcaae1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -3281,3 +3281,7 @@ after receiving data. That has historical reasons to be there (it was needed before read-ahead buffering was added), but kills performance. (Noted by Max Holtzberg). + * configs/shenzhou: Add beginnings of a board configuration for the + Shenzhou STM32107 board (see www.armjishu.com). Very little is in + place as of this initial check-in. + diff --git a/Documentation/NuttX.html b/Documentation/NuttX.html index 8fd164b88a..287c702d26 100644 --- a/Documentation/NuttX.html +++ b/Documentation/NuttX.html @@ -1799,12 +1799,25 @@

STMicro STM32F107x. - Chip support for the STM32 F1 "Connectivity Line" family has been present in NuttX and users have reported that they have successful brought up NuttX on there proprietary boards using this logic. - Support for the Olimex STM32-P107 was contributed by Max Holtzberg and first appeared in NuttX-6.21. -

+ Chip support for the STM32 F1 "Connectivity Line" family has been present in NuttX for some time and users have reported that they have successful brought up NuttX on there proprietary boards using this logic. +

+

+ Olimex STM32-P107 + Support for the Olimex STM32-P107 was contributed by Max Holtzberg and first appeared in NuttX-6.21. That port features the STMicro STM32F107VC MCU. +

+

+

+ Shenzhou + Work is underway as of this writing to port NuttX to the Shenzhou development board (See www.armjishu.com) featuring the STMicro STM32F107VCT MCU. + If all goes according to plan, this port should be verified and avaialble in NuttX-6.22. +

+

diff --git a/Documentation/NuttXLinks.html b/Documentation/NuttXLinks.html index 128ee5d2d3..b2206050c6 100644 --- a/Documentation/NuttXLinks.html +++ b/Documentation/NuttXLinks.html @@ -22,6 +22,7 @@
  • SourceForge
  • FreshMeat
  • Forum
    • +
  • OSChina
  • Downloads
  • Wiki
  • Toolchains
    • diff --git a/Documentation/README.html b/Documentation/README.html index abb54ab603..c18dd9ad84 100644 --- a/Documentation/README.html +++ b/Documentation/README.html @@ -166,6 +166,8 @@ | | | |- include/README.txt | | | |- src/README.txt | | | `- README.txt + | | |- shenzhou/ + | | | `- README.txt | | |- skp16c26/ | | | |- include/README.txt | | | |- src/README.txt diff --git a/README.txt b/README.txt index 28b4fba032..5964511289 100644 --- a/README.txt +++ b/README.txt @@ -735,6 +735,8 @@ nuttx | | |- include/README.txt | | |- src/README.txt | | `- README.txt + | |- shenzhou/ + | | `- README.txt | |- skp16c26/ | | |- include/README.txt | | |- src/README.txt diff --git a/configs/README.txt b/configs/README.txt index 6cd5eef3f9..c8b02711a7 100644 --- a/configs/README.txt +++ b/configs/README.txt @@ -1709,6 +1709,10 @@ configs/sim This port does not support interrupts or a real timer (and hence no round robin scheduler) Otherwise, it is complete. +configs/shenzhou + This is the port of NuttX to the Shenzhou development board from + www.armjishu.com. This board features the STMicro STM32F107VCT MCU. + configs/skp16c26 Renesas M16C processor on the Renesas SKP16C26 StarterKit. This port uses the GNU m32c toolchain. STATUS: The port is complete but untested diff --git a/configs/shenzhou/README.txt b/configs/shenzhou/README.txt new file mode 100755 index 0000000000..bda76a783f --- /dev/null +++ b/configs/shenzhou/README.txt @@ -0,0 +1,1110 @@ +README +====== + +This README discusses issues unique to NuttX configurations for the Shenzhou +development board from www.armjishu.com featuring the STMicro STM32F107VCT +MCU. On-board features: + + - STM32F107VCT + - 10/100M PHY (DM9161AEP) + - TFT LCD Connector + - USB OTG + - CAN (CAN1=2) + - USART connectos (USART1-2) + - RS-485 + - SD card slot + - Audio DAC (PCM1770) + - SPI Flash (W25X16) + - (4) LEDs (LED1-4) + - 2.4G Wireless (NRF24L01 SPI module) + - 315MHz Wireless (module) + - (4) Buttons (KEY1-4, USERKEY2, USERKEY, TEMPER, WAKEUP) + - VBUS/external +4V select + - 5V/3.3V power conversion + - Extension connector + - JTAG + +Contents +======== + + - STM32F107VCT Pin Usage + - Development Environment + - GNU Toolchain Options + - IDEs + - NuttX buildroot Toolchain + - Shenzhou-specific Configuration Options + - LEDs + - Shenzhou-specific Configuration Options + - Configurations + +STM32F107VCT Pin Usage +====================== + +23 PA0 WAKEUP Connected to KEY4. Active low: Closing KEY4 pulls WAKEUP to ground. +24 PA1 MII_RX_CLK + RMII_REF_CLK +25 PA2 MII_MDIO +26 PA3 315M_VT +29 PA4 DAC_OUT1 +30 PA5 DAC_OUT2 JP10 + SPI1_SCK +31 PA6 SPI1_MISO +32 PA7 SPI1_MOSI +67 PA8 MCO +68 PA9 USB_VBUS JP3 + USART1_TX +69 PA10 USB_ID JP5 + USART1TX +70 PA11 USB_DM +71 PA12 USB_DP +72 PA13 TMS/SWDIO +76 PA14 TCK/SWCLK +77 PA15 TDI + +35 PB0 ADC_IN1 +36 PB1 ADC_IN2 +37 PB2 DATA_LE + BOOT1 JP13 +89 PB3 TDO/SWO +90 PB4 TRST +91 PB5 CAN2_RX +92 PB6 CAN2_TX JP11 + I2C1_SCL +93 PB7 I2C1_SDA +95 PB8 USB_PWR +96 PB9 F_CS +47 PB10 USERKEY +48 PB11 MII_TX_EN +51 PB12 I2S_WS + MII_TXD0 +52 PB13 I2S_CK + MII_TXD1 +53 PB14 SD_CD +54 PB15 I2S_DIN + +15 PC0 POTENTIO_METER +16 PC1 MII_MDC +17 PC2 WIRELESS_INT +18 PC3 WIRELESS_CE +33 PC4 USERKEY2 +34 PC5 TP_INT JP6 + MII_INT +63 PC6 I2S_MCK Pulled high +64 PC7 LCD_CS Pulled high +65 PC8 LCD_CS Pulled high +66 PC9 TP_CS Pulled hight +78 PC10 SPI3_SCK +79 PC11 SPI3_MISO +80 PC12 SPI3_MOSI +7 PC13 TAMPER +8 PC14 OSC32_IN Y1 32.768Khz XTAL +9 PC15 OSC32_OUT Y1 32.768Khz XTAL + +81 PD0 CAN1_RX +82 PD1 CAN1_TX +83 PD2 LED1 +84 PD3 LED2 +85 PD4 LED3 +86 PD5 485_TX + USART2_TX +87 PD6 485_RX JP4 + USART2_RX +88 PD7 LED4 + 485_DIR +55 PD8 MII_RX_DV + RMII_CRSDV +56 PD9 MII_RXD0 +57 PD10 MII_RXD1 +58 PD11 SD_CS +59 PD12 WIRELESS_CS +60 PD13 LCD_RS +61 PD14 LCD_WR +62 PD15 LCD_RD + +97 PE0 DB00 +98 PE1 DB01 +1 PE2 DB02 +2 PE3 DB03 +3 PE4 DB04 +4 PE5 DB05 +5 PE6 DB06 +38 PE7 DB07 +39 PE8 DB08 +40 PE9 DB09 +41 PE10 DB10 +42 PE11 DB11 +43 PE12 DB12 +44 PE13 DB13 +45 PE14 DB14 +46 PE15 DB15 + +73 N/C + +12 OSC_IN Y2 25Mhz XTAL +13 OSC_OUT Y2 25Mhz XTAL + +94 BOOT0 JP15 (3.3V or GND) +14 RESET S5 +6 VBAT JP14 (3.3V or battery) + +49 VSS_1 GND +74 VSS_2 GND +99 VSS_3 GND +27 VSS_4 GND +10 VSS_5 GND +19 VSSA VSSA +20 VREF- VREF- + + +Development Environment +======================= + + Either Linux or Cygwin on Windows can be used for the development environment. + The source has been built only using the GNU toolchain (see below). Other + toolchains will likely cause problems. Testing was performed using the Cygwin + environment because the development tools that I used only work under Windows. + +GNU Toolchain Options +===================== + + Toolchain Configurations + ------------------------ + The NuttX make system has been modified to support the following different + toolchain options. + + 1. The CodeSourcery GNU toolchain, + 2. The Atollic Toolchain, + 3. The devkitARM GNU toolchain, + 4. Raisonance GNU toolchain, or + 5. The NuttX buildroot Toolchain (see below). + + Most testing has been conducted using the CodeSourcery toolchain for Windows and + that is the default toolchain in most configurations. To use the Atollic, + devkitARM, Raisonance GNU, or NuttX buildroot toolchain, you simply need to + add one of the following configuration options to your .config (or defconfig) + file: + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_STM32_CODESOURCERYL=y : CodeSourcery under Linux + CONFIG_STM32_ATOLLIC_LITE=y : The free, "Lite" version of Atollic toolchain under Windows + CONFIG_STM32_ATOLLIC_PRO=y : The paid, "Pro" version of Atollic toolchain under Windows + CONFIG_STM32_DEVKITARM=y : devkitARM under Windows + CONFIG_STM32_RAISONANCE=y : Raisonance RIDE7 under Windows + CONFIG_STM32_BUILDROOT=y : NuttX buildroot under Linux or Cygwin (default) + + If you change the default toolchain, then you may also have to modify the PATH in + the setenv.h file if your make cannot find the tools. + + NOTE: the CodeSourcery (for Windows), Atollic, devkitARM, and Raisonance toolchains are + Windows native toolchains. The CodeSourcery (for Linux) and NuttX buildroot + toolchains are Cygwin and/or Linux native toolchains. There are several limitations + to using a Windows based toolchain in a Cygwin environment. The three biggest are: + + 1. The Windows toolchain cannot follow Cygwin paths. Path conversions are + performed automatically in the Cygwin makefiles using the 'cygpath' utility + but you might easily find some new path problems. If so, check out 'cygpath -w' + + 2. Windows toolchains cannot follow Cygwin symbolic links. Many symbolic links + are used in Nuttx (e.g., include/arch). The make system works around these + problems for the Windows tools by copying directories instead of linking them. + But this can also cause some confusion for you: For example, you may edit + a file in a "linked" directory and find that your changes had no effect. + That is because you are building the copy of the file in the "fake" symbolic + directory. If you use a Windows toolchain, you should get in the habit of + making like this: + + make clean_context all + + An alias in your .bashrc file might make that less painful. + + 3. Dependencies are not made when using Windows versions of the GCC. This is + because the dependencies are generated using Windows pathes which do not + work with the Cygwin make. + + Support has been added for making dependencies with the windows-native toolchains. + That support can be enabled by modifying your Make.defs file as follows: + + - MKDEP = $(TOPDIR)/tools/mknulldeps.sh + + MKDEP = $(TOPDIR)/tools/mkdeps.sh --winpaths "$(TOPDIR)" + + If you have problems with the dependency build (for example, if you are not + building on C:), then you may need to modify tools/mkdeps.sh + + The CodeSourcery Toolchain (2009q1) + ----------------------------------- + The CodeSourcery toolchain (2009q1) does not work with default optimization + level of -Os (See Make.defs). It will work with -O0, -O1, or -O2, but not with + -Os. + + The Atollic "Pro" and "Lite" Toolchain + -------------------------------------- + One problem that I had with the Atollic toolchains is that the provide a gcc.exe + and g++.exe in the same bin/ file as their ARM binaries. If the Atollic bin/ path + appears in your PATH variable before /usr/bin, then you will get the wrong gcc + when you try to build host executables. This will cause to strange, uninterpretable + errors build some host binaries in tools/ when you first make. + + The Atollic "Lite" Toolchain + ---------------------------- + The free, "Lite" version of the Atollic toolchain does not support C++ nor + does it support ar, nm, objdump, or objdcopy. If you use the Atollic "Lite" + toolchain, you will have to set: + + CONFIG_HAVE_CXX=n + + In order to compile successfully. Otherwise, you will get errors like: + + "C++ Compiler only available in TrueSTUDIO Professional" + + The make may then fail in some of the post link processing because of some of + the other missing tools. The Make.defs file replaces the ar and nm with + the default system x86 tool versions and these seem to work okay. Disable all + of the following to avoid using objcopy: + + CONFIG_RRLOAD_BINARY=n + CONFIG_INTELHEX_BINARY=n + CONFIG_MOTOROLA_SREC=n + CONFIG_RAW_BINARY=n + + devkitARM + --------- + The devkitARM toolchain includes a version of MSYS make. Make sure that the + the paths to Cygwin's /bin and /usr/bin directories appear BEFORE the devkitARM + path or will get the wrong version of make. + +IDEs +==== + + NuttX is built using command-line make. It can be used with an IDE, but some + effort will be required to create the project. + + Makefile Build + -------------- + Under Eclipse, it is pretty easy to set up an "empty makefile project" and + simply use the NuttX makefile to build the system. That is almost for free + under Linux. Under Windows, you will need to set up the "Cygwin GCC" empty + makefile project in order to work with Windows (Google for "Eclipse Cygwin" - + there is a lot of help on the internet). + + Native Build + ------------ + Here are a few tips before you start that effort: + + 1) Select the toolchain that you will be using in your .config file + 2) Start the NuttX build at least one time from the Cygwin command line + before trying to create your project. This is necessary to create + certain auto-generated files and directories that will be needed. + 3) Set up include pathes: You will need include/, arch/arm/src/stm32, + arch/arm/src/common, arch/arm/src/armv7-m, and sched/. + 4) All assembly files need to have the definition option -D __ASSEMBLY__ + on the command line. + + Startup files will probably cause you some headaches. The NuttX startup file + is arch/arm/src/stm32/stm32_vectors.S. With RIDE, I have to build NuttX + one time from the Cygwin command line in order to obtain the pre-built + startup object needed by RIDE. + +NuttX buildroot Toolchain +========================= + + A GNU GCC-based toolchain is assumed. The files */setenv.sh should + be modified to point to the correct path to the Cortex-M3 GCC toolchain (if + different from the default in your PATH variable). + + If you have no Cortex-M3 toolchain, one can be downloaded from the NuttX + SourceForge download site (https://sourceforge.net/project/showfiles.php?group_id=189573). + This GNU toolchain builds and executes in the Linux or Cygwin environment. + + 1. You must have already configured Nuttx in /nuttx. + + cd tools + ./configure.sh shenzhou/ + + 2. Download the latest buildroot package into + + 3. unpack the buildroot tarball. The resulting directory may + have versioning information on it like buildroot-x.y.z. If so, + rename /buildroot-x.y.z to /buildroot. + + 4. cd /buildroot + + 5. cp configs/cortexm3-defconfig-4.3.3 .config + + 6. make oldconfig + + 7. make + + 8. Edit setenv.h, if necessary, so that the PATH variable includes + the path to the newly built binaries. + + See the file configs/README.txt in the buildroot source tree. That has more + detailed PLUS some special instructions that you will need to follow if you are + building a Cortex-M3 toolchain for Cygwin under Windows. + +LEDs +==== + +The Shenzhou board has four LEDs labeled LED1, LED2, LED3 and LED4 on the +board. These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is +defined. In that case, the usage by the board port is defined in +include/board.h and src/up_leds.c. The LEDs are used to encode OS-related +events as follows: + + SYMBOL Meaning LED1* LED2 LED3 LED4**** + ------------------- ----------------------- ------- ------- ------- ------ + LED_STARTED NuttX has been started ON OFF OFF OFF + LED_HEAPALLOCATE Heap has been allocated OFF ON OFF OFF + LED_IRQSENABLED Interrupts enabled ON ON OFF OFF + LED_STACKCREATED Idle stack created OFF OFF ON OFF + LED_INIRQ In an interrupt** ON N/C N/C OFF + LED_SIGNAL In a signal handler*** N/C ON N/C OFF + LED_ASSERTION An assertion failed ON ON N/C OFF + LED_PANIC The system has crashed N/C N/C N/C ON + LED_IDLE STM32 is is sleep mode (Optional, not used) + + * If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot + and these LEDs will give you some indication of where the failure was + ** The normal state is LED3 ON and LED1 faintly glowing. This faint glow + is because of timer interupts that result in the LED being illuminated + on a small proportion of the time. + *** LED2 may also flicker normally if signals are processed. +**** LED4 may not be available if RS-485 is also used it will then indicate + the RS-485 direction. + +Shenzhou-specific Configuration Options +============================================ + + CONFIG_ARCH - Identifies the arch/ subdirectory. This should + be set to: + + CONFIG_ARCH=arm + + CONFIG_ARCH_family - For use in C code: + + CONFIG_ARCH_ARM=y + + CONFIG_ARCH_architecture - For use in C code: + + CONFIG_ARCH_CORTEXM3=y + + CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory + + CONFIG_ARCH_CHIP=stm32 + + CONFIG_ARCH_CHIP_name - For use in C code to identify the exact + chip: + + CONFIG_ARCH_CHIP_STM32F107VCT=y + + CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG - Enables special STM32 clock + configuration features. + + CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG=n + + CONFIG_ARCH_BOARD - Identifies the configs subdirectory and + hence, the board that supports the particular chip or SoC. + + CONFIG_ARCH_BOARD=shenzhou (for the Shenzhou development board) + + CONFIG_ARCH_BOARD_name - For use in C code + + CONFIG_ARCH_BOARD_SHENZHOU=y + + CONFIG_ARCH_LOOPSPERMSEC - Must be calibrated for correct operation + of delay loops + + CONFIG_ENDIAN_BIG - define if big endian (default is little + endian) + + CONFIG_DRAM_SIZE - Describes the installed DRAM (SRAM in this case): + + CONFIG_DRAM_SIZE=0x00010000 (64Kb) + + CONFIG_DRAM_START - The start address of installed DRAM + + CONFIG_DRAM_START=0x20000000 + + CONFIG_STM32_CCMEXCLUDE - Exclude CCM SRAM from the HEAP + + In addition to internal SRAM, SRAM may also be available through the FSMC. + In order to use FSMC SRAM, the following additional things need to be + present in the NuttX configuration file: + + CONFIG_STM32_FSMC_SRAM - Indicates that SRAM is available via the + FSMC (as opposed to an LCD or FLASH). + + CONFIG_HEAP2_BASE - The base address of the SRAM in the FSMC address space (hex) + + CONFIG_HEAP2_END - The size of the SRAM in the FSMC address space (decimal) + + CONFIG_ARCH_IRQPRIO - The STM32107xxx supports interrupt prioritization + + CONFIG_ARCH_IRQPRIO=y + + CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to boards that + have LEDs + + CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt + stack. If defined, this symbol is the size of the interrupt + stack in bytes. If not defined, the user task stacks will be + used during interrupt handling. + + CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions + + CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to board architecture. + + CONFIG_ARCH_CALIBRATION - Enables some build in instrumentation that + cause a 100 second delay during boot-up. This 100 second delay + serves no purpose other than it allows you to calibratre + CONFIG_ARCH_LOOPSPERMSEC. You simply use a stop watch to measure + the 100 second delay then adjust CONFIG_ARCH_LOOPSPERMSEC until + the delay actually is 100 seconds. + + Individual subsystems can be enabled: + + AHB1 + ---- + CONFIG_STM32_CRC + CONFIG_STM32_BKPSRAM + CONFIG_STM32_CCMDATARAM + CONFIG_STM32_DMA1 + CONFIG_STM32_DMA2 + CONFIG_STM32_ETHMAC + CONFIG_STM32_OTGHS + + AHB2 + ---- + CONFIG_STM32_DCMI + CONFIG_STM32_CRYP + CONFIG_STM32_HASH + CONFIG_STM32_RNG + CONFIG_STM32_OTGFS + + AHB3 + ---- + CONFIG_STM32_FSMC + + APB1 + ---- + CONFIG_STM32_TIM2 + CONFIG_STM32_TIM3 + CONFIG_STM32_TIM4 + CONFIG_STM32_TIM5 + CONFIG_STM32_TIM6 + CONFIG_STM32_TIM7 + CONFIG_STM32_TIM12 + CONFIG_STM32_TIM13 + CONFIG_STM32_TIM14 + CONFIG_STM32_WWDG + CONFIG_STM32_IWDG + CONFIG_STM32_SPI2 + CONFIG_STM32_SPI3 + CONFIG_STM32_USART2 + CONFIG_STM32_USART3 + CONFIG_STM32_UART4 + CONFIG_STM32_UART5 + CONFIG_STM32_I2C1 + CONFIG_STM32_I2C2 + CONFIG_STM32_I2C3 + CONFIG_STM32_CAN1 + CONFIG_STM32_CAN2 + CONFIG_STM32_DAC1 + CONFIG_STM32_DAC2 + CONFIG_STM32_PWR -- Required for RTC + + APB2 + ---- + CONFIG_STM32_TIM1 + CONFIG_STM32_TIM8 + CONFIG_STM32_USART1 + CONFIG_STM32_USART6 + CONFIG_STM32_ADC1 + CONFIG_STM32_ADC2 + CONFIG_STM32_ADC3 + CONFIG_STM32_SDIO + CONFIG_STM32_SPI1 + CONFIG_STM32_SYSCFG + CONFIG_STM32_TIM9 + CONFIG_STM32_TIM10 + CONFIG_STM32_TIM11 + + Timer devices may be used for different purposes. One special purpose is + to generate modulated outputs for such things as motor control. If CONFIG_STM32_TIMn + is defined (as above) then the following may also be defined to indicate that + the timer is intended to be used for pulsed output modulation, ADC conversion, + or DAC conversion. Note that ADC/DAC require two definition: Not only do you have + to assign the timer (n) for used by the ADC or DAC, but then you also have to + configure which ADC or DAC (m) it is assigned to. + + CONFIG_STM32_TIMn_PWM Reserve timer n for use by PWM, n=1,..,14 + CONFIG_STM32_TIMn_ADC Reserve timer n for use by ADC, n=1,..,14 + CONFIG_STM32_TIMn_ADCm Reserve timer n to trigger ADCm, n=1,..,14, m=1,..,3 + CONFIG_STM32_TIMn_DAC Reserve timer n for use by DAC, n=1,..,14 + CONFIG_STM32_TIMn_DACm Reserve timer n to trigger DACm, n=1,..,14, m=1,..,2 + + For each timer that is enabled for PWM usage, we need the following additional + configuration settings: + + CONFIG_STM32_TIMx_CHANNEL - Specifies the timer output channel {1,..,4} + + NOTE: The STM32 timers are each capable of generating different signals on + each of the four channels with different duty cycles. That capability is + not supported by this driver: Only one output channel per timer. + + JTAG Enable settings (by default JTAG-DP and SW-DP are disabled): + + CONFIG_STM32_JTAG_FULL_ENABLE - Enables full SWJ (JTAG-DP + SW-DP) + CONFIG_STM32_JTAG_NOJNTRST_ENABLE - Enables full SWJ (JTAG-DP + SW-DP) + but without JNTRST. + CONFIG_STM32_JTAG_SW_ENABLE - Set JTAG-DP disabled and SW-DP enabled + + STM32107xxx specific device driver settings + + CONFIG_U[S]ARTn_SERIAL_CONSOLE - selects the USARTn (n=1,2,3) or UART + m (m=4,5) for the console and ttys0 (default is the USART1). + CONFIG_U[S]ARTn_RXBUFSIZE - Characters are buffered as received. + This specific the size of the receive buffer + CONFIG_U[S]ARTn_TXBUFSIZE - Characters are buffered before + being sent. This specific the size of the transmit buffer + CONFIG_U[S]ARTn_BAUD - The configure BAUD of the UART. Must be + CONFIG_U[S]ARTn_BITS - The number of bits. Must be either 7 or 8. + CONFIG_U[S]ARTn_PARTIY - 0=no parity, 1=odd parity, 2=even parity + CONFIG_U[S]ARTn_2STOP - Two stop bits + + CONFIG_STM32_SPI_INTERRUPTS - Select to enable interrupt driven SPI + support. Non-interrupt-driven, poll-waiting is recommended if the + interrupt rate would be to high in the interrupt driven case. + CONFIG_STM32_SPI_DMA - Use DMA to improve SPI transfer performance. + Cannot be used with CONFIG_STM32_SPI_INTERRUPT. + + CONFIG_SDIO_DMA - Support DMA data transfers. Requires CONFIG_STM32_SDIO + and CONFIG_STM32_DMA2. + CONFIG_SDIO_PRI - Select SDIO interrupt prority. Default: 128 + CONFIG_SDIO_DMAPRIO - Select SDIO DMA interrupt priority. + Default: Medium + CONFIG_SDIO_WIDTH_D1_ONLY - Select 1-bit transfer mode. Default: + 4-bit transfer mode. + + CONFIG_STM32_PHYADDR - The 5-bit address of the PHY on the board + CONFIG_STM32_MII - Support Ethernet MII interface + CONFIG_STM32_MII_MCO1 - Use MCO1 to clock the MII interface + CONFIG_STM32_MII_MCO2 - Use MCO2 to clock the MII interface + CONFIG_STM32_RMII - Support Ethernet RMII interface + CONFIG_STM32_AUTONEG - Use PHY autonegotion to determine speed and mode + CONFIG_STM32_ETHFD - If CONFIG_STM32_AUTONEG is not defined, then this + may be defined to select full duplex mode. Default: half-duplex + CONFIG_STM32_ETH100MBPS - If CONFIG_STM32_AUTONEG is not defined, then this + may be defined to select 100 MBps speed. Default: 10 Mbps + CONFIG_STM32_PHYSR - This must be provided if CONFIG_STM32_AUTONEG is + defined. The PHY status register address may diff from PHY to PHY. This + configuration sets the address of the PHY status register. + CONFIG_STM32_PHYSR_SPEED - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides bit mask indicating 10 or 100MBps speed. + CONFIG_STM32_PHYSR_100MBPS - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides the value of the speed bit(s) indicating 100MBps speed. + CONFIG_STM32_PHYSR_MODE - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provide bit mask indicating full or half duplex modes. + CONFIG_STM32_PHYSR_FULLDUPLEX - This must be provided if CONFIG_STM32_AUTONEG is + defined. This provides the value of the mode bits indicating full duplex mode. + CONFIG_STM32_ETH_PTP - Precision Time Protocol (PTP). Not supported + but some hooks are indicated with this condition. + + Shenzhou CAN Configuration + + CONFIG_CAN - Enables CAN support (one or both of CONFIG_STM32_CAN1 or + CONFIG_STM32_CAN2 must also be defined) + CONFIG_CAN_FIFOSIZE - The size of the circular buffer of CAN messages. + Default: 8 + CONFIG_CAN_NPENDINGRTR - The size of the list of pending RTR requests. + Default: 4 + CONFIG_CAN_LOOPBACK - A CAN driver may or may not support a loopback + mode for testing. The STM32 CAN driver does support loopback mode. + CONFIG_CAN1_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN1 is defined. + CONFIG_CAN2_BAUD - CAN1 BAUD rate. Required if CONFIG_STM32_CAN2 is defined. + CONFIG_CAN_TSEG1 - The number of CAN time quanta in segment 1. Default: 6 + CONFIG_CAN_TSEG2 - the number of CAN time quanta in segment 2. Default: 7 + CONFIG_CAN_REGDEBUG - If CONFIG_DEBUG is set, this will generate an + dump of all CAN registers. + + Shenzhou LCD Hardware Configuration + + The LCD driver supports the following LCDs on the STM324xG_EVAL board: + + AM-240320L8TNQW00H (LCD_ILI9320 or LCD_ILI9321) OR + AM-240320D5TOQW01H (LCD_ILI9325) + + Configuration options. + + CONFIG_LCD_LANDSCAPE - Define for 320x240 display "landscape" + support. Default is this 320x240 "landscape" orientation + For the Shenzhou board, the edge opposite from the row of buttons + is used as the top of the display in this orientation. + CONFIG_LCD_RLANDSCAPE - Define for 320x240 display "reverse + landscape" support. Default is this 320x240 "landscape" + orientation + For the Shenzhou board, the edge next to the row of buttons + is used as the top of the display in this orientation. + CONFIG_LCD_PORTRAIT - Define for 240x320 display "portrait" + orientation support. In this orientation, the STM3210E-EVAL's + LCD ribbon cable is at the bottom of the display. Default is + 320x240 "landscape" orientation. + In this orientation, the top of the display is to the left + of the buttons (if the board is held so that the buttons are at the + botton of the board). + CONFIG_LCD_RPORTRAIT - Define for 240x320 display "reverse + portrait" orientation support. In this orientation, the + STM3210E-EVAL's LCD ribbon cable is at the top of the display. + Default is 320x240 "landscape" orientation. + In this orientation, the top of the display is to the right + of the buttons (if the board is held so that the buttons are at the + botton of the board). + CONFIG_LCD_RDSHIFT - When reading 16-bit gram data, there appears + to be a shift in the returned data. This value fixes the offset. + Default 5. + + The LCD driver dynamically selects the LCD based on the reported LCD + ID value. However, code size can be reduced by suppressing support for + individual LCDs using: + + CONFIG_STM32_ILI9320_DISABLE (includes ILI9321) + CONFIG_STM32_ILI9325_DISABLE + + STM32 USB OTG FS Host Driver Support + + Pre-requisites + + CONFIG_USBHOST - Enable USB host support + CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG - Needed + CONFIG_SCHED_WORKQUEUE - Worker thread support is required + + Options: + + CONFIG_STM32_OTGFS_RXFIFO_SIZE - Size of the RX FIFO in 32-bit words. + Default 128 (512 bytes) + CONFIG_STM32_OTGFS_NPTXFIFO_SIZE - Size of the non-periodic Tx FIFO + in 32-bit words. Default 96 (384 bytes) + CONFIG_STM32_OTGFS_PTXFIFO_SIZE - Size of the periodic Tx FIFO in 32-bit + words. Default 96 (384 bytes) + CONFIG_STM32_OTGFS_DESCSIZE - Maximum size of a descriptor. Default: 128 + CONFIG_STM32_OTGFS_SOFINTR - Enable SOF interrupts. Why would you ever + want to do that? + CONFIG_STM32_USBHOST_REGDEBUG - Enable very low-level register access + debug. Depends on CONFIG_DEBUG. + CONFIG_STM32_USBHOST_PKTDUMP - Dump all incoming and outgoing USB + packets. Depends on CONFIG_DEBUG. + +Configurations +============== + +Each Shenzhou configuration is maintained in a sudirectory and +can be selected as follow: + + cd tools + ./configure.sh shenzhou/ + cd - + . ./setenv.sh + +Where is one of the following: + + dhcpd: + ----- + + This builds the DCHP server using the apps/examples/dhcpd application + (for execution from FLASH.) See apps/examples/README.txt for information + about the dhcpd example. The server address is 10.0.0.1 and it serves + IP addresses in the range 10.0.0.2 through 10.0.0.17 (all of which, of + course, are configurable). + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + + nettest: + ------- + + This configuration directory may be used to verify networking performance + using the STM32's Ethernet controller. It uses apps/examples/nettest to excercise the + TCP/IP network. + + CONFIG_EXAMPLE_NETTEST_SERVER=n : Target is configured as the client + CONFIG_EXAMPLE_NETTEST_PERFORMANCE=y : Only network performance is verified. + CONFIG_EXAMPLE_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2) : Target side is IP: 10.0.0.2 + CONFIG_EXAMPLE_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host side is IP: 10.0.0.1 + CONFIG_EXAMPLE_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1) : Server address used by which ever is client. + + nsh: + --- + Configures the NuttShell (nsh) located at apps/examples/nsh. The + Configuration enables both the serial and telnet NSH interfaces. + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_NSH_DHCPC=n : DHCP is disabled + CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2) : Target IP address 10.0.0.2 + CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1) : Host IP address 10.0.0.1 + + NOTES: + 1. This example assumes that a network is connected. During its + initialization, it will try to negotiate the link speed. If you have + no network connected when you reset the board, there will be a long + delay (maybe 30 seconds?) before anything happens. That is the timeout + before the networking finally gives up and decides that no network is + available. + + 2. This example supports the ADC test (apps/examples/adc) but this must + be manually enabled by selecting: + + CONFIG_ADC=y : Enable the generic ADC infrastructure + CONFIG_STM32_ADC3=y : Enable ADC3 + CONFIG_STM32_TIM1=y : Enable Timer 1 + CONFIG_STM32_TIM1_ADC=y : Indicate that timer 1 will be used to trigger an ADC + CONFIG_STM32_TIM1_ADC3=y : Assign timer 1 to drive ADC3 sampling + CONFIG_STM32_ADC3_SAMPLE_FREQUENCY=100 : Select a sampling frequency + + See also apps/examples/README.txt + + General debug for analog devices (ADC/DAC): + + CONFIG_DEBUG_ANALOG + + 3. This example supports the PWM test (apps/examples/pwm) but this must + be manually enabled by selecting eeither + + CONFIG_PWM=y : Enable the generic PWM infrastructure + CONFIG_PWM_PULSECOUNT=n : Disable to support for TIM1/8 pulse counts + CONFIG_STM32_TIM4=y : Enable TIM4 + CONFIG_STM32_TIM4_PWM=y : Use TIM4 to generate PWM output + CONFIG_STM32_TIM4_CHANNEL=2 : Select output on TIM4, channel 2 + + If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 32. + Ground is available on CN3, pin1. + + Or.. + + CONFIG_PWM=y : Enable the generic PWM infrastructure + CONFIG_PWM_PULSECOUNT=y : Enable to support for TIM1/8 pulse counts + CONFIG_STM32_TIM8=y : Enable TIM8 + CONFIG_STM32_TIM8_PWM=y : Use TIM8 to generate PWM output + CONFIG_STM32_TIM8_CHANNEL=4 : Select output on TIM8, channel 4 + + If CONFIG_STM32_FSMC is disabled, output will appear on CN3, pin 17 + Ground is available on CN23 pin1. + + See also include/board.h and apps/examples/README.txt + + Special PWM-only debug options: + + CONFIG_DEBUG_PWM + + 4. This example supports the CAN loopback test (apps/examples/can) but this + must be manually enabled by selecting: + + CONFIG_CAN=y : Enable the generic CAN infrastructure + CONFIG_CAN_EXID=y or n : Enable to support extended ID frames + CONFIG_STM32_CAN1=y : Enable CAN1 + CONFIG_CAN_LOOPBACK=y : Enable CAN loopback mode + + See also apps/examples/README.txt + + Special CAN-only debug options: + + CONFIG_DEBUG_CAN + CONFIG_CAN_REGDEBUG + + 5. This example can support an FTP client. In order to build in FTP client + support simply uncomment the following lines in the appconfig file (before + configuring) or in the apps/.config file (after configuring): + + #CONFIGURED_APPS += netutils/ftpc + #CONFIGURED_APPS += examples/ftpc + + 6. This example can support an FTP server. In order to build in FTP server + support simply uncomment the following lines in the appconfig file (before + configuring) or in the apps/.config file (after configuring): + + #CONFIGURED_APPS += netutils/ftpd + #CONFIGURED_APPS += examples/ftpd + + And enable poll() support in the NuttX configuration file: + + CONFIG_DISABLE_POLL=n + + 7. This example supports the watchdog timer test (apps/examples/watchdog) + but this must be manually enabled by selecting: + + CONFIG_WATCHDOG=y : Enables watchdog timer driver support + CONFIG_STM32_WWDG=y : Enables the WWDG timer facility, OR + CONFIG_STM32_IWDG=y : Enables the IWDG timer facility (but not both) + + The WWDG watchdog is driven off the (fast) 42MHz PCLK1 and, as result, + has a maximum timeout value of 49 milliseconds. For WWDG watchdog, you + should also add the fillowing to the configuration file: + + CONFIG_EXAMPLES_WATCHDOG_PINGDELAY=20 + CONFIG_EXAMPLES_WATCHDOG_TIMEOUT=49 + + The IWDG timer has a range of about 35 seconds and should not be an issue. + + 7. Adding LCD and graphics support: + + appconfig (apps/.config): Enable the application configurations that you + want to use. Asexamples: + + CONFIGURED_APPS += examples/nx : Pick one or more + CONFIGURED_APPS += examples/nxhello : + CONFIGURED_APPS += examples/nximage : + CONFIGURED_APPS += examples/nxlines : + + defconfig (nuttx/.config): + + CONFIG_STM32_FSMC=y : FSMC support is required for the LCD + CONFIG_NX=y : Enable graphics suppport + CONFIG_MM_REGIONS=3 : When FSMC is enabled, so is the on-board SRAM memory region + + 8. USB OTG FS Device or Host Support + + CONFIG_USBDEV - Enable USB device support, OR + CONFIG_USBHOST - Enable USB host support + CONFIG_STM32_OTGFS - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG - Needed + CONFIG_SCHED_WORKQUEUE - Worker thread support is required + + 9. USB OTG FS Host Support. The following changes will enable support for + a USB host on the STM32F4Discovery, including support for a mass storage + class driver: + + CONFIG_USBDEV=n - Make sure tht USB device support is disabled + CONFIG_USBHOST=y - Enable USB host support + CONFIG_STM32_OTGFS=y - Enable the STM32 USB OTG FS block + CONFIG_STM32_SYSCFG=y - Needed for all USB OTF FS support + CONFIG_SCHED_WORKQUEUE=y - Worker thread support is required for the mass + storage class driver. + CONFIG_NSH_ARCHINIT=y - Architecture specific USB initialization + is needed for NSH + CONFIG_FS_FAT=y - Needed by the USB host mass storage class. + + With those changes, you can use NSH with a FLASH pen driver as shown + belong. Here NSH is started with nothing in the USB host slot: + + NuttShell (NSH) NuttX-x.yy + nsh> ls /dev + /dev: + console + null + ttyS0 + + After inserting the FLASH drive, the /dev/sda appears and can be + mounted like this: + + nsh> ls /dev + /dev: + console + null + sda + ttyS0 + nsh> mount -t vfat /dev/sda /mnt/stuff + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + + And files on the FLASH can be manipulated to standard interfaces: + + nsh> echo "This is a test" >/mnt/stuff/atest.txt + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + -rw-rw-rw- 16 atest.txt + nsh> cat /mnt/stuff/atest.txt + This is a test + nsh> cp /mnt/stuff/filea.c fileb.c + nsh> ls /mnt/stuff + /mnt/stuff: + -rw-rw-rw- 16236 filea.c + -rw-rw-rw- 16 atest.txt + -rw-rw-rw- 16236 fileb.c + + To prevent data loss, don't forget to un-mount the FLASH drive + before removing it: + + nsh> umount /mnt/stuff + + 11. This configuration requires that jumper JP22 be set to enable RS-232 + operation. + + nsh2: + ----- + + This is an alternative NSH configuration. One limitation of the Shenzhou + board is that you cannot have both a UART-based NSH console and SDIO support. + The nsh2 differs from the nsh configuration in the following ways: + + -CONFIG_STM32_USART3=y : USART3 is disabled + +CONFIG_STM32_USART3=n + + -CONFIG_STM32_SDIO=n : SDIO is enabled + +CONFIG_STM32_SDIO=y + + Logically, these are the only differences: This configuration has SDIO (and + the SD card) enabled and the serial console disabled. There is ONLY a + Telnet console!. + + There are some special settings to make life with only a Telnet + + CONFIG_SYSLOG=y - Enables the System Logging feature. + CONFIG_RAMLOG=y - Enable the RAM-based logging feature. + CONFIG_RAMLOG_CONSOLE=y - Use the RAM logger as the default console. + This means that any console output from non-Telnet threads will + go into the circular buffer in RAM. + CONFIG_RAMLOG_SYSLOG - This enables the RAM-based logger as the + system logger. This means that (1) in addition to the console + output from other tasks, ALL of the debug output will also to + to the circular buffer in RAM, and (2) NSH will now support a + command called 'dmesg' that can be used to dump the RAM log. + + There are a few other configuration differences as necessary to support + this different device configuration. Just the do the 'diff' if you are + curious. + + NOTES: + 1. See the notes for the nsh configuration. Most also apply to the nsh2 + configuration. Like the nsh configuration, this configuration can + be modified to support a variety of additional tests. + + 2. RS-232 is disabled, but Telnet is still available for use as a console. + Since RS-232 and SDIO use the same pins (one controlled by JP22), RS232 + and SDIO cannot be used concurrently. + + 3. This configuration requires that jumper JP22 be set to enable SDIO + operation. To enable MicroSD Card, which shares same I/Os with RS-232, + JP22 is not fitted. + + 4. In order to use SDIO without overruns, DMA must be used. The STM32 F4 + has 192Kb of SRAM in two banks: 112Kb of "system" SRAM located at + 0x2000:0000 and 64Kb of "CCM" SRAM located at 0x1000:0000. It appears + that you cannot perform DMA from CCM SRAM. The work around that I have now + is simply to omit the 64Kb of CCM SRAM from the heap so that all memory is + allocated from System SRAM. This is done by setting: + + CONFIG_MM_REGIONS=1 + + Then DMA works fine. The downside is, of course, is that we lose 64Kb + of precious SRAM. + + 5. Another SDIO/DMA issue. This one is probably a software bug. This is + the bug as stated in the TODO list: + + "If you use a large I/O buffer to access the file system, then the + MMCSD driver will perform multiple block SD transfers. With DMA + ON, this seems to result in CRC errors detected by the hardware + during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y" + + For this reason, CONFIG_MMCSD_MULTIBLOCK_DISABLE=y appears in the defconfig + file. + + 6. Another DMA-related concern. I see this statement in the reference + manual: "The burst configuration has to be selected in order to respect + the AHB protocol, where bursts must not cross the 1 KB address boundary + because the minimum address space that can be allocated to a single slave + is 1 KB. This means that the 1 KB address boundary should not be crossed + by a burst block transfer, otherwise an AHB error would be generated, + that is not reported by the DMA registers." + + There is nothing in the DMA driver to prevent this now. + + nxconsole: + ---------- + This is yet another NSH configuration. This NSH configuration differs + from the others, however, in that it uses the NxConsole driver to host + the NSH shell. + + Some of the differences in this configuration and the normal nsh configuration + include these settings in the defconfig file: + + These select NX Multi-User mode: + + CONFG_NX_MULTIUSER=y + CONFIG_DISABLE_MQUEUE=n + + The following definition in the defconfig file to enables the NxConsole + driver: + + CONFIG_NXCONSOLE=y + + The appconfig file selects examples/nxconsole instead of examples/nsh: + + CONFIGURED_APPS += examples/nxconsole + + Other configuration settings: + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + CONFIG_LCD_LANDSCAPE=y : 320x240 landscape + + nxwm + ---- + This is a special configuration setup for the NxWM window manager + UnitTest. The NxWM window manager can be found here: + + trunk/NxWidgets/nxwm + + The NxWM unit test can be found at: + + trunk/NxWidgets/UnitTests/nxwm + + Documentation for installing the NxWM unit test can be found here: + + trunk/NxWidgets/UnitTests/README.txt + + Here is the quick summary of the build steps: + + 1. Intall the nxwm configuration + + $ cd ~/nuttx/trunk/nuttx/tools + $ ./configure.sh shenzhou/nxwm + + 2. Make the build context (only) + + $ cd .. + $ . ./setenv.sh + $ make context + ... + + 3. Install the nxwm unit test + + $ cd ~/nuttx/trunk/NxWidgets + $ tools/install.sh ~/nuttx/trunk/apps nxwm + Creating symbolic link + - To ~/nuttx/trunk/NxWidgets/UnitTests/nxwm + - At ~/nuttx/trunk/apps/external + + 4. Build the NxWidgets library + + $ cd ~/nuttx/trunk/NxWidgets/libnxwidgets + $ make TOPDIR=~/nuttx/trunk/nuttx + ... + + 5. Build the NxWM library + + $ cd ~/nuttx/trunk/NxWidgets/nxwm + $ make TOPDIR=~//nuttx/trunk/nuttx + ... + + 6. Built NuttX with the installed unit test as the application + + $ cd ~/nuttx/trunk/nuttx + $ make + + ostest: + ------ + This configuration directory, performs a simple OS test using + examples/ostest. By default, this project assumes that you are + using the DFU bootloader. + + CONFIG_STM32_CODESOURCERYW=y : CodeSourcery under Windows + + telnetd: + -------- + + A simple test of the Telnet daemon(see apps/netutils/README.txt, + apps/examples/README.txt, and apps/examples/telnetd). This is + the same daemon that is used in the nsh configuration so if you + use NSH, then you don't care about this. This test is good for + testing the Telnet daemon only because it works in a simpler + environment than does the nsh configuration. diff --git a/net/recvfrom.c b/net/recvfrom.c index 6b9eb9a908..8bb658f48f 100644 --- a/net/recvfrom.c +++ b/net/recvfrom.c @@ -371,7 +371,7 @@ static int recvfrom_timeout(struct recvfrom_s *pstate) * 1) This delay function has been enabled with CONFIG_NET_TCP_RECVDELAY > 0 * 2) Some data has already been received from the socket. Since this can * only be true for a TCP/IP socket, this logic applies only to TCP/IP - * sockets, and either + * sockets. And either * 3) There is no configured receive timeout, or * 4) The configured receive timeout is greater than than the delay */ @@ -598,7 +598,9 @@ static uint16_t recvfrom_tcpinterrupt(struct uip_driver_s *dev, void *conn, /* Report an error only if no data has been received */ +#if CONFIG_NET_TCP_RECVDELAY > 0 if (pstate->rf_recvlen == 0) +#endif { /* Report the timeout error */