configs/: Remove dangline space at the end of lines in .txt files.
This commit is contained in:
Gregory Nutt
parent
1ed9793751
commit
44545781e5
@ -572,7 +572,7 @@ OpenOCD for the ESP32
|
||||
esp32.cpu0: Target halted, pc=0x400835BF
|
||||
187 g_tick_divisor = divisor;
|
||||
(gdb) ...
|
||||
|
||||
|
||||
Configurations
|
||||
==============
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ OpenSDAv2
|
||||
HDK-compatible debug interface preloaded with the open-source CMSIS-DAP
|
||||
Interface firmware (mbed interface) for rapid prototyping and product
|
||||
development.
|
||||
|
||||
|
||||
To use set raw binary output for nuttx.bin
|
||||
|
||||
Serial Console
|
||||
|
||||
@ -478,7 +478,7 @@ Where <subdir> is one of the following:
|
||||
|
||||
netnsh:
|
||||
Configures the NuttShell (nsh) located at apps/examples/nsh. This
|
||||
configuration is similar to the nsh configuration except that network
|
||||
configuration is similar to the nsh configuration except that network
|
||||
upport is enabled.
|
||||
|
||||
NOTES:
|
||||
|
||||
@ -30,7 +30,7 @@ on the FPGA board. Those peripherals include:
|
||||
- 3-Axis accelerometer
|
||||
- Temperature sensor
|
||||
|
||||
See http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/
|
||||
See http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/
|
||||
or http://store.digilentinc.com/nexys-4-artix-7-fpga-trainer-board-limited-time-see-nexys4-ddr/
|
||||
for more information about these boards.
|
||||
|
||||
@ -53,25 +53,25 @@ Contents
|
||||
|
||||
Development Environment
|
||||
=======================
|
||||
The NR5M100 RISC-V core was designed as a low gate count / low performance micro controller
|
||||
The NR5M100 RISC-V core was designed as a low gate count / low performance micro controller
|
||||
for inclusion in an ASIC. It is based on a Verilog RISC-V called picorv32, but has many
|
||||
additions beyond that baseline. The design running on the Digilent Nexys4 FPGA is a
|
||||
additions beyond that baseline. The design running on the Digilent Nexys4 FPGA is a
|
||||
validation platform for the core and is presented as an open source project.
|
||||
|
||||
The reason NR5M100 is "low performance" is that it is a state machine based core (like the
|
||||
picorv32) and not a multi-stage pipeline core. This means that it requires an average of
|
||||
4.5 clock cycles to execute each instruction. On a multi-stage pipeline architecure, this
|
||||
average would be closer to 1 clock cycle per instruction (though a bit higher due to
|
||||
average would be closer to 1 clock cycle per instruction (though a bit higher due to
|
||||
pipeline branch misses). The tradeoff for lower performance is a simpler design. There
|
||||
is a single memory bus interface for both instructions and data. Multi-stage pipeline
|
||||
cores require a separate I and D bus with cache SRAM and an external memory cache controller,
|
||||
etc. This in addition to the pipeline registers adds additional gate count.
|
||||
|
||||
The nr5m100-nexys4 core runs at 83.333 Mhz which provides about 18 Mhz effective operating
|
||||
speed with the multi-clock per instruction architecture. If you are looking for a higher
|
||||
performance platform, you should check out the PULP Platform ( http://www.pulp-platform.org ).
|
||||
That is an FPGA design with a 4-stage pipeline RISC-V core, though not currently supported
|
||||
by NuttX. The NR5M100 project will likely pull in the RISC-V core from that design next,
|
||||
speed with the multi-clock per instruction architecture. If you are looking for a higher
|
||||
performance platform, you should check out the PULP Platform ( http://www.pulp-platform.org ).
|
||||
That is an FPGA design with a 4-stage pipeline RISC-V core, though not currently supported
|
||||
by NuttX. The NR5M100 project will likely pull in the RISC-V core from that design next,
|
||||
though this will probably not be available soon. With a bit of work, it is possible to
|
||||
run the nr5m100-nexys4 core at 170 Mhz with a 6.5 clocks-per-instruction state machine.
|
||||
This would give an effective performance of about 26Mhz.
|
||||
@ -87,8 +87,8 @@ RISC-V GNU Toolchain
|
||||
====================
|
||||
|
||||
To compile the code, you must first build a RISC-V GNU Toolchain from the sources at
|
||||
https://github.com/riscv/riscv-gnu-toolchain. I don't know of any sources for pre-compiled
|
||||
toolchains (though there may be some out there).
|
||||
https://github.com/riscv/riscv-gnu-toolchain. I don't know of any sources for pre-compiled
|
||||
toolchains (though there may be some out there).
|
||||
|
||||
To build this toolchain, follow these instructions (tested on Ubuntu 12.04):
|
||||
|
||||
@ -118,16 +118,16 @@ RISC-V GNU Toolchain
|
||||
|
||||
Windows based toolchain
|
||||
-----------------------
|
||||
May be possible to compile the GNU toolchain described above using Cygwin, but havne't tried it.
|
||||
May be possible to compile the GNU toolchain described above using Cygwin, but havne't tried it.
|
||||
|
||||
Debugger
|
||||
========
|
||||
The Debug Module within the NR5M100 RISC-V has been designed to work with the RISC-V gdb
|
||||
The Debug Module within the NR5M100 RISC-V has been designed to work with the RISC-V gdb
|
||||
debugger interfaced with the SiFive implementation of OpenOCD. The interface has been tested
|
||||
with a J-LINK JTAG probe connected to PMOD header B on the FPGA using an adapter board
|
||||
with a J-LINK JTAG probe connected to PMOD header B on the FPGA using an adapter board
|
||||
that I designed and fabbed at OSHPark. I will update this README.txt file soon with a link
|
||||
to the shared project for anyone who wishes to build one.
|
||||
|
||||
|
||||
To build OpenOCD, perform the following:
|
||||
|
||||
1. Ensure the proper packages are installed:
|
||||
@ -139,7 +139,7 @@ Debugger
|
||||
cd ~/riscv
|
||||
git clone --recursive https://github.com/sifive/openocd.git
|
||||
|
||||
3. Configure and build OpenOCD. The x86_64 GCC compilers will give errors because of
|
||||
3. Configure and build OpenOCD. The x86_64 GCC compilers will give errors because of
|
||||
shadowed variable warnings, so diable the -Werror flag also:
|
||||
|
||||
cd openocd
|
||||
|
||||
@ -237,7 +237,7 @@ Configurations
|
||||
reconfiguration process.
|
||||
|
||||
2. Unless stated otherwise, all configurations generate console
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
elevant configuration settings are listed below:
|
||||
|
||||
CONFIG_STM32_USART2=y
|
||||
@ -319,7 +319,7 @@ Configurations
|
||||
CONFIG_NSH_ARCHINIT=y
|
||||
CONFIG_NSH_BUILTIN_APPS=y
|
||||
|
||||
Support for NSH built-in applications is enabled for future use.
|
||||
Support for NSH built-in applications is enabled for future use.
|
||||
However, no built applications are enabled in this base configuration.
|
||||
|
||||
2. C++ support for applications is NOT enabled. That could be enabled
|
||||
|
||||
@ -223,7 +223,7 @@ Configurations
|
||||
reconfiguration process.
|
||||
|
||||
2. Unless stated otherwise, all configurations generate console
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
elevant configuration settings are listed below:
|
||||
|
||||
CONFIG_STM32_USART2=y
|
||||
@ -305,7 +305,7 @@ Configurations
|
||||
CONFIG_NSH_ARCHINIT=y
|
||||
CONFIG_NSH_BUILTIN_APPS=y
|
||||
|
||||
Support for NSH built-in applications is enabled for future use.
|
||||
Support for NSH built-in applications is enabled for future use.
|
||||
However, no built applications are enabled in this base configuration.
|
||||
|
||||
2. C++ support for applications is NOT enabled. That could be enabled
|
||||
|
||||
@ -229,7 +229,7 @@ Configurations
|
||||
reconfiguration process.
|
||||
|
||||
2. Unless stated otherwise, all configurations generate console
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
output on USART2, as described above under "Serial Console". The
|
||||
elevant configuration settings are listed below:
|
||||
|
||||
CONFIG_STM32_USART2=y
|
||||
|
||||
@ -76,7 +76,7 @@ NUCLEO-L496ZG Features:
|
||||
Microprocessor: STM32L496ZGT6 Core: ARM 32-bit Cortex®-M4 CPU with FPU,
|
||||
80 MHz, MPU, and DSP instructions.
|
||||
Memory: 1024 KB Flash 320KB of SRAM (including 64KB of SRAM2)
|
||||
ADC: 3×12-bit: up to 24 channels
|
||||
ADC: 3×12-bit: up to 24 channels
|
||||
DMA: 2 X 7-stream DMA controllers with FIFOs and burst support
|
||||
Timers: Up to 13 timers: (2x 16-bit lowpower), two 32-bit timers,
|
||||
2x watchdogs, SysTick
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
README
|
||||
======
|
||||
|
||||
The Olimex STM32-H407 configuration is based on
|
||||
stm32Fdiscovery and Olimex STM32-H405.
|
||||
The Olimex STM32-H407 configuration is based on
|
||||
stm32Fdiscovery and Olimex STM32-H405.
|
||||
|
||||
The H407 was programmed with ST-LINK/V2 from both Win8.1 and Ubuntu 14.04
|
||||
This release provides baseline for H407 12MHZ clock in include/board.h
|
||||
|
||||
@ -49,7 +49,7 @@ Configuring NuttX to use your Wireless Router (aka Access Point)
|
||||
|
||||
Browser the menus this way:
|
||||
|
||||
Application Configuration --->
|
||||
Application Configuration --->
|
||||
NSH Library --->
|
||||
Networking Configuration --->
|
||||
WAPI Configuration --->
|
||||
|
||||
@ -580,7 +580,7 @@ Configuration sub-directories
|
||||
1. The configuration configuration can be modified to include support
|
||||
for the on-board SRAM (1MB).
|
||||
|
||||
System Type -> External Memory Configuration
|
||||
System Type -> External Memory Configuration
|
||||
CONFIG_SAM34_EXTSRAM0=y : Select SRAM on CS0
|
||||
CONFIG_SAM34_EXTSRAM0SIZE=1048576 : Size=1MB
|
||||
|
||||
@ -589,7 +589,7 @@ Configuration sub-directories
|
||||
a) To enable the NuttX RAM test that may be used to verify the
|
||||
external SRAM:
|
||||
|
||||
System Type -> External Memory Configuration
|
||||
System Type -> External Memory Configuration
|
||||
CONFIG_SAM34_EXTSRAM0HEAP=n : Don't add to heap
|
||||
|
||||
Application Configuration -> System NSH Add-Ons
|
||||
@ -623,7 +623,7 @@ Configuration sub-directories
|
||||
b) To add this RAM to the NuttX heap, you would need to change the
|
||||
configuration as follows:
|
||||
|
||||
System Type -> External Memory Configuration
|
||||
System Type -> External Memory Configuration
|
||||
CONFIG_SAM34_EXTSRAM0HEAP=y : Add external RAM to heap
|
||||
|
||||
Memory Management
|
||||
|
||||
@ -24,7 +24,7 @@ Procedure:
|
||||
5. NSH shouls start
|
||||
|
||||
NuttShell (NSH) NuttX-7.3
|
||||
nsh>
|
||||
nsh>
|
||||
|
||||
6. Mount the SD card at /music
|
||||
|
||||
|
||||
@ -359,7 +359,7 @@ Creating and Using DRAMBOOT
|
||||
cd tools
|
||||
./configure.sh sama5d4-ek/dramboot
|
||||
cd -
|
||||
|
||||
|
||||
Before building, make sure that the PATH environment variable includes
|
||||
the correct path to the directory than holds your toolchain binaries.
|
||||
|
||||
|
||||
@ -104,7 +104,7 @@ the following icons will be visible:
|
||||
pause, fast forward, rewind, and adjust the volume.
|
||||
|
||||
Unfortunately in this version, the WM8904 audio CODEC is stubbed out so
|
||||
you will not actually be able to heard any of the .WAV files that you
|
||||
you will not actually be able to heard any of the .WAV files that you
|
||||
|
||||
Telnet access:
|
||||
==============
|
||||
|
||||
@ -478,7 +478,7 @@ Serial Consoles
|
||||
Atmel Studio 6.1
|
||||
================
|
||||
|
||||
NOTE: These instructions are old. The SAML21 requires Atmel Studio 6.2.
|
||||
NOTE: These instructions are old. The SAML21 requires Atmel Studio 6.2.
|
||||
They may still prove useful to you, however.
|
||||
|
||||
Loading Code into FLASH:
|
||||
|
||||
@ -2369,7 +2369,7 @@ Configuration sub-directories
|
||||
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.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ routed case no special configuration is necessary, but by default the
|
||||
simulation will only be accessible to the host on which it runs.
|
||||
|
||||
Bridge mode is recommended where possible. It requires slightly more effort
|
||||
to set up, but is much more flexible, and is likely to be easier to maintain
|
||||
to set up, but is much more flexible, and is likely to be easier to maintain
|
||||
in the end.
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ able to see it until the simulation is stopped. The host route will force all
|
||||
traffic destined for that IP to be sent to the tap interface.
|
||||
|
||||
NOTE: If you configure an IP address that is not on the same subnet as your
|
||||
host, additional manual setup will be required. This is not
|
||||
host, additional manual setup will be required. This is not
|
||||
recommended; you should use bridge mode instead.
|
||||
|
||||
|
||||
@ -90,22 +90,22 @@ network as your eth1 interface. Note that your bridge will generally not need
|
||||
an IP address in this case.
|
||||
|
||||
If you only have a single interface, you can configure your system so that eth0
|
||||
(or other primary interface) is on the bridge. To do this, you would execute
|
||||
(or other primary interface) is on the bridge. To do this, you would execute
|
||||
commands like the following from the system console:
|
||||
|
||||
# brctl addbr nuttx0
|
||||
# brctl addif nuttx0 eth0
|
||||
# ifconfig nuttx0 <host-ip-address/netmask>
|
||||
# route add -net default gw ...
|
||||
|
||||
|
||||
The rest of your network configuration would remain the same; your host's IP
|
||||
address has simply moved from being assigned directly to the ethernet interface,
|
||||
to being assigned to the bridge that contains that interface. The connection
|
||||
to being assigned to the bridge that contains that interface. The connection
|
||||
will operate as normal. NuttX simulations will join the bridge as with the
|
||||
previous example.
|
||||
|
||||
In either of the live access scenarios presented here, the default gateway you
|
||||
configure in your simluation should be the normal one for the network you're
|
||||
configure in your simluation should be the normal one for the network you're
|
||||
accessing, whether or not the bridge has an IP address. The bridge is acting
|
||||
as an ethernet hub; your simluation has direct access to the normal gateway as
|
||||
if the simluation were a device physically connected to the network.
|
||||
@ -113,7 +113,7 @@ if the simluation were a device physically connected to the network.
|
||||
|
||||
CONFIGURING AT STARTUP
|
||||
----------------------
|
||||
Most Linux distributions have a mechanism for configuring a bridge at startup.
|
||||
Most Linux distributions have a mechanism for configuring a bridge at startup.
|
||||
See your distribution's documentation for more information.
|
||||
|
||||
|
||||
@ -122,7 +122,7 @@ NOTES
|
||||
|
||||
o Users of VMware ESXi should be aware that the bridge will place the contained
|
||||
ethernet interface into promiscuous mode (don't ask me why). ESXi will
|
||||
reject this by default, and nothing will work. To fix this, edit the
|
||||
reject this by default, and nothing will work. To fix this, edit the
|
||||
properties of the relevant vSwitch or VLAN, select the Security tab, and
|
||||
set "Promiscuous Mode" to "Accept".
|
||||
|
||||
|
||||
@ -361,7 +361,7 @@ Temperature Sensor
|
||||
bytesread = read(fd, buffer, 8*sizeof(b16_t)); /* Read temperature samples */
|
||||
|
||||
More complex temperature sensor operations are also available. See the
|
||||
IOCTL commands enumerated in include/nuttx/sensors/lm75.h. Also read the
|
||||
IOCTL commands enumerated in include/nuttx/sensors/lm75.h. Also read the
|
||||
descriptions of the stm32_lm75initialize() and stm32_lm75attach()
|
||||
interfaces in the arch/board/board.h file (sames as
|
||||
configs/stm3210e-eval/include/board.h).
|
||||
|
||||
@ -356,15 +356,15 @@ Nokia 5110 LCD Display support:
|
||||
After compiling and flashing the nuttx.bin inside the board, reset it.
|
||||
You should see it:
|
||||
|
||||
NuttShell (NSH)
|
||||
NuttShell (NSH)
|
||||
nsh> ?
|
||||
help usage: help [-v] [<cmd>]
|
||||
help usage: help [-v] [<cmd>]
|
||||
|
||||
[ dd free mb sh usleep
|
||||
? echo help mh sleep xd
|
||||
cat exec hexdump mw test
|
||||
cd exit kill pwd true
|
||||
cp false ls set unset
|
||||
[ dd free mb sh usleep
|
||||
? echo help mh sleep xd
|
||||
cat exec hexdump mw test
|
||||
cd exit kill pwd true
|
||||
cp false ls set unset
|
||||
|
||||
Builtin Apps:
|
||||
nxhello
|
||||
|
||||
@ -416,10 +416,10 @@ https://github.com/texane/stlink
|
||||
--------------------------------
|
||||
This is an open source server for the ST-Link that I have never used.
|
||||
|
||||
It is also possible to use an external debugger such as the Segger JLink
|
||||
It is also possible to use an external debugger such as the Segger JLink
|
||||
(EDU or commercial models) provided:
|
||||
|
||||
1) The CN4 jumpers are removed to disconnect the on-board STLinkV2 from
|
||||
1) The CN4 jumpers are removed to disconnect the on-board STLinkV2 from
|
||||
the STM32F3.
|
||||
|
||||
2) The appropriate (20 pin connector to flying wire) adapter is used to connect
|
||||
@ -433,7 +433,7 @@ It is also possible to use an external debugger such as the Segger JLink
|
||||
|
||||
The signals used with external (SWD) debugging are:
|
||||
|
||||
VREF (3V)
|
||||
VREF (3V)
|
||||
GROUND (GND)
|
||||
SWCLK (PA14)
|
||||
SWIO (PA13)
|
||||
|
||||
@ -2,7 +2,7 @@ README
|
||||
======
|
||||
|
||||
This README discusses issues unique to NuttX configurations for the
|
||||
STMicro STM32F746G-DISCO development board featuring the STM32F746NGH6
|
||||
STMicro STM32F746G-DISCO development board featuring the STM32F746NGH6
|
||||
MCU. The STM32F746NGH6 is a 216MHz Cortex-M7 operation with 1024Kb Flash
|
||||
memory and 300Kb SRAM. The board features:
|
||||
|
||||
|
||||
@ -88,7 +88,7 @@ AT24 Serial EEPROM
|
||||
----------------
|
||||
|
||||
A AT24C512 Serial EEPPROM was used for tested I2C. There are no I2C
|
||||
devices on-board the Launchpad, but an external serial EEPROM module
|
||||
devices on-board the Launchpad, but an external serial EEPROM module
|
||||
module was used.
|
||||
|
||||
The Serial EEPROM was mounted on an external adaptor board and connected
|
||||
|
||||
@ -68,19 +68,19 @@ Micro-USB K64_MICRO_USB_DN USB0_DN
|
||||
Pushbuttons SW1 (LLWU_P10) PTC6 PTC6
|
||||
SW2 (RSTIN_B_R) RSTIN RESET
|
||||
SW3 (NMI B) PTA4 PTA4
|
||||
LEDs D5 / Green LED PTE6 PTE6
|
||||
D6 / Yellow LED PTE7 PTE7
|
||||
D7 / Orange LED PTE8 PTE8
|
||||
D9 / Blue LED PTE9 PTE9
|
||||
LEDs D5 / Green LED PTE6 PTE6
|
||||
D6 / Yellow LED PTE7 PTE7
|
||||
D7 / Orange LED PTE8 PTE8
|
||||
D9 / Blue LED PTE9 PTE9
|
||||
Potentiometer Potentiometer (R526) ? ADC1_SE18
|
||||
Accelerometer I2C SDA PTC11 I2C1_SDA
|
||||
I2C SCL PTC10 I2C1_SCL
|
||||
INT1 PTA6 PTA6
|
||||
INT2 PTA8 PTA8
|
||||
|
||||
|
||||
SDHC important notice: on TWR-K64F120M, R521 (close to the SD card holder) is not placed,
|
||||
hence WRPROTEC is always ON. Either place a 4.7KOhm resistor or change PIN config
|
||||
to PULLDOWN, loosing Write Protect function. See twrk64.h.
|
||||
to PULLDOWN, loosing Write Protect function. See twrk64.h.
|
||||
|
||||
Connections via the General Purpose Tower Plug-in (TWRPI) Socket
|
||||
-------------------- ------------------------- -------- -------------------
|
||||
@ -265,7 +265,7 @@ Networking Support
|
||||
|
||||
From the target side, you may should also be able to ping the host
|
||||
(assuming it's IP is 192.168.0.1):
|
||||
|
||||
|
||||
nsh> ping 192.168.0.1
|
||||
PING 192.168.0.1 56 bytes of data
|
||||
56 bytes from 192.168.0.1: icmp_seq=1 time=0 ms
|
||||
@ -279,7 +279,7 @@ Networking Support
|
||||
56 bytes from 192.168.0.1: icmp_seq=9 time=0 ms
|
||||
56 bytes from 192.168.0.1: icmp_seq=10 time=0 ms
|
||||
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
|
||||
nsh>
|
||||
nsh>
|
||||
|
||||
You can also log into the NSH from the host PC like this:
|
||||
|
||||
@ -409,7 +409,7 @@ as follows:
|
||||
* 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 LED1 ON and LED2 faintly glowing. This faint glow
|
||||
is because of timer interrupts and signal that result in the LED being
|
||||
is because of timer interrupts and signal that result in the LED being
|
||||
illuminated on a small proportion of the time.
|
||||
*** LED3 may even glow faintlier then LED2 while signals are processed.
|
||||
|
||||
@ -798,18 +798,18 @@ Where <subdir> is one of the following:
|
||||
CONFIG_SCHED_WORKQUEUE=y : Enable the NuttX workqueue
|
||||
|
||||
CONFIG_NSH_ARCHINIT=y : Provide NSH initializeation logic
|
||||
|
||||
|
||||
netnsh:
|
||||
------
|
||||
This is the same config then nsh, but it adds Ethernet support with the
|
||||
TWR-SER card. It includes telnetd in order to access nsh from Ethernet.
|
||||
IP address defaults to 192.168.0.233/24.
|
||||
|
||||
|
||||
NOTES:
|
||||
|
||||
1. See networking support for application and especially for jumper setting.
|
||||
In this config, this is TWR-SER that clocks the MCU.
|
||||
|
||||
|
||||
2. The PHY link negotiation is done at boot time only. If no link is then
|
||||
available, a fallback mode is used at 10Mbs/half-duplex. Please make sure
|
||||
your ethernet cable and switches are on before booting.
|
||||
|
||||
@ -19,7 +19,7 @@ Serial Console
|
||||
|
||||
Be default, UART0 (aka, USIC0, channel 0) is used as the serial console.
|
||||
The RX and TX pins is available:
|
||||
|
||||
|
||||
RX - P1.4, Connector X2, pin 17
|
||||
TX - P1.5, Connector X2, pin 16
|
||||
GND - Available on pins 1-4 of either connector X1 or X2
|
||||
@ -47,7 +47,7 @@ LEDs
|
||||
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
|
||||
LED1 LED2
|
||||
------------------ ------------------------ ------ ------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user