Remove the tail space char from all files

Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
This commit is contained in:
Xiang Xiao 2023-02-26 02:12:10 +08:00 committed by Petro Karashchenko
parent cf9dd1c653
commit 21bc466a2b
19 changed files with 50 additions and 51 deletions
Application.mk
audioutils/mml_parser
canutils/libcanardv1
examples
netutils/iperf
testing/mtd_config_fs

@ -135,7 +135,7 @@ endef
define ELFCOMPILEZIG
$(ECHO_BEGIN)"ZIG: $1 "
# Remove target suffix here since zig compiler add .o automatically
$(Q) $(ZIG) build-obj $(ZIGELFFLAGS) $($(strip $1)_ZIGELFFLAGS) --name $(basename $2) $1
$(Q) $(ZIG) build-obj $(ZIGELFFLAGS) $($(strip $1)_ZIGELFFLAGS) --name $(basename $2) $1
$(ECHO_END)
endef

@ -66,7 +66,7 @@ ex: ``"CDEFGAB > C R C < BAGFEDC"``, ``"O4 CDEFGAB O5 C R C O4 BAGFEDC"``
### Tempo
Tempo is indicated as "T" and numter following after the "T".
Tempo number decide a speed of the score. This value is used for culculating sample number for
Tempo number decide a speed of the score. This value is used for culculating sample number for
the note (or rest).
ex: ``"T120"``

@ -32,7 +32,7 @@
#include <audioutils/mml_parser.h>
#ifdef DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif
@ -50,7 +50,7 @@
#define TUPLET_START '{'
#define TUPLET_END '}'
#ifdef DEBUG_ON
#ifdef DEBUG_ON
#define DEBUG printf
#else
#define DEBUG(...)

@ -55,7 +55,7 @@ $(LIBCANARDV1_UNPACKNAME): $(LIBCANARDV1_PACKNAME)
$(call DELDIR, $@)
$(Q) $(UNPACK) $<
$(Q) touch $@
$(O1HEAP_PACKNAME):
@echo "Downloading: $@"
$(Q) curl -o $@ -L $(O1HEAP_URL)$(DELIM)$(O1HEAP_VERSION)$(PACKEXT)
@ -77,7 +77,7 @@ $(APPS_INCDIR)$(DELIM)canard.h: $(LIBCANARDV1_DRVDIR)$(DELIM)canard.h
$(APPS_INCDIR)$(DELIM)canard_dsdl.h: $(LIBCANARDV1_DRVDIR)$(DELIM)canard_dsdl.h
$(Q) cp $< $@
$(APPS_INCDIR)$(DELIM)o1heap.h: $(O1HEAP_DRVDIR)$(DELIM)o1heap.h
$(Q) cp $< $@

@ -2003,7 +2003,7 @@ The watcher is a task that will monitor other tasks that subscribe to be watched
If a watched task doesn't signal the watcher during the watchdog time period,
the watchdog timer will expire and the watcher will print the tasks that did
not signal and the ones that signaled. The tasks that did not signal will be printed
as the tasks that starved the dog and the tasks that signaled will be printed as
as the tasks that starved the dog and the tasks that signaled will be printed as
the tasks that fed the dog.
The watcher task will only feed the watchdog timer when all subscribed tasks have
asked to feed dog.
@ -2013,16 +2013,16 @@ To start the watcher, just run:
`watcher`
The watched example is not required to use the watcher. The watched example is simply
a task that creates 4 tasks that will subscribe to be watched. The first and fourth
a task that creates 4 tasks that will subscribe to be watched. The first and fourth
will not feed the dog to expose the functionality. This example will show the user
how to subscribe, to feed the dog and to unsubscribe.
how to subscribe, to feed the dog and to unsubscribe.
To start the watched, just run:
`watched`
`watched`
P.S: This example will only be supported by the chips that support interrupt on
timeout, i.e., which have the \"capture\" command implemented.
timeout, i.e., which have the \"capture\" command implemented.
This test depends on these specific configurations settings (your
specific watchdog hardware settings might require additional settings).
@ -2032,9 +2032,9 @@ specific watchdog hardware settings might require additional settings).
- `CONFIG_NSH_BUILTIN_APPS` Build this example an NSH built-in
function.
- `CONFIG_DRIVERS_NOTE` and `CONFIG_SCHED_INSTRUMENTATION` Allows the watcher
to get the tasks' names.
to get the tasks' names.
- `CONFIG_FS_FAT` Allows the creation of a FAT filesystem on the ramdisk
to create a file with all the necessary info for the watched tasks.
to create a file with all the necessary info for the watched tasks.
Specific configuration options for the `watcher` example include:
@ -2044,7 +2044,7 @@ Specific configuration options for the `watcher` example include:
the Watcher. Default: `/dev/watchdog0`.
- `CONFIG_EXAMPLES_WATCHER_TIMEOUT` The watchdog timeout value in
milliseconds.
- `CONFIG_EXAMPLES_WATCHER_SIGNAL` This is the Signal Number used for
- `CONFIG_EXAMPLES_WATCHER_SIGNAL` This is the Signal Number used for
communication between the watcher task and the watched tasks.
Specific configuration options for the `watched` example include:

@ -81,7 +81,7 @@ class CETL
printf("v1 with 0 through 9\n");
for (auto& it : v1) {
printf("%i ", it);
}
}
printf("\n");
printf("v2 with 10 through 29\n");

@ -17,7 +17,7 @@ limits on your own so as not to break your hardware.
# Configuration
The FOC PI current controller parameters can be obtained from the given
The FOC PI current controller parameters can be obtained from the given
equations:
```
@ -43,41 +43,40 @@ where:
Ls = 8.73 uH
i\_max = ?
v\_max = ?
Example configuration for f\_PWM = 20kHz, f\_notifier = 10kHz, ccb=1000:
Kp = 0.0087
Ki = 0.0025
* Linix 45ZWN24-40 (PMSM motor dedicated for NXP FRDM-MC-LVMTR kit)
p = 2
Rs = 0.5 Ohm
Ls = 0.400 mH
i\_max = 2.34 A
v\_max = 24 V
Example configuration for f\_PWM = 10kHz, f\_notifier = 5kHz, ccb=1000:
Kp = 0.4
Ki = 0.1
* Bull-Running BR2804-1700 kV (motor provided with the ST P-NUCLEO-IHM07 kit)
p = 7
Rs = 0.11 Ohm
Ls = 0.018 mH
i\_max = 1.2A
v\_max = 12V
Example configuration for f\_PWM = 20kHz, f\_notifier = 10kHz, ccb=200:
Kp = 0.036
Ki = 0.022
* iPower GBM2804H-100T (gimbal motor provided with the ST P-NUCLEO-IHM03 kit)
p = 7
Rs = 5.29 Ohm
Ls = 1.05 mH
i\_max = 0.15A
v\_max = 12V
Example configuration for f\_PWM = 10kHz, f\_notifier = 5kHz, ccb=TODO:
Kp = TODO
Ki = TODO

4
examples/lp503x/Kconfig Executable file → Normal file

@ -21,7 +21,7 @@ config EXAMPLES_LP503X_PROGNAME
config EXAMPLES_LP503X_DEVPATH
string "LP503X device path"
default "/dev/leddrv0"
config EXAMPLES_LP503X_PRIORITY
int "lp503x task priority"
default 100
@ -29,5 +29,5 @@ config EXAMPLES_LP503X_PRIORITY
config EXAMPLES_LP503X_STACKSIZE
int "lp503x stack size"
default DEFAULT_TASK_STACKSIZE
endif

@ -39,16 +39,16 @@ NuttShell (NSH) NuttX-10.2.0
nsh> ?
help usage: help [-v] [<cmd>]
. cd echo hexdump mv rmdir true xd
[ cp exec kill printf set truncate
? cmp exit ls ps sleep uname
basename dirname false mkdir pwd source umount
break dd free mkrd reboot test unset
cat df help mount rm time usleep
. cd echo hexdump mv rmdir true xd
[ cp exec kill printf set truncate
? cmp exit ls ps sleep uname
basename dirname false mkdir pwd source umount
break dd free mkrd reboot test unset
cat df help mount rm time usleep
Builtin Apps:
mcuboot_set_img mcuboot_confirm sh
mcuboot_version ramtest nsh
mcuboot_set_img mcuboot_confirm sh
mcuboot_version ramtest nsh
nsh>
```

@ -2,19 +2,19 @@
## What's this?
This program consists of a client socket & custom messages that send data (hex-string formatted data) to a server (tcp_ipc_server).
This program consists of a client socket & custom messages that send data (hex-string formatted data) to a server (tcp_ipc_server).
Then, tcp_ipc_server send this data over LoraWAN (using Radioenge LoRaWAN module). It means using TCP/IP sockets as IPC channel to ensure controlled access to LoRaWAN connectivity.
The goals of using this approach to send LoRaWAN data are:
* Having a solid and reliable infrastructure to ensure IPC works fine for multiple applications simultaneously
* Having the possibility to host different IoT projects and solutions that use LPWAN in a single ESP32
* Having the possibility to host different IoT projects and solutions that use LPWAN in a single ESP32
* Having the possibility to validate, test and debug multiple IoT projects and solutions at the same time, under the same connectivity conditions (same signal strength, same antenna, same modem/transceiver, etc.)
Both client and server work on local network scope.
## How do I use this?
In order to test tcp_ipc_client & tcp_ipc_server together, there are two ways to proceed:
1) Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)

@ -43,7 +43,7 @@
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <arpa/inet.h>
#include <arpa/inet.h>
#include "protocol.h"
@ -90,7 +90,7 @@ static void show_usage(FAR const char *progname)
#define SOCKET_PORT 5000
#define TCP_DATA_RCV_WITHOUT_FLAGS 0
#define RCV_BUFFER_SIZE 520
#define SEND_BUFFER_SIZE 500
#define SEND_BUFFER_SIZE 500
#define TIME_SECONDS_TO_SEND_NEXT_DATA 15
/****************************************************************************

@ -2,21 +2,21 @@
## What's this?
This program consists of a server socket & custom messages to establish IPC for multiple applications (client_tcp) and one process that controls LoRaWAN connectivity (server_tcp).
This program consists of a server socket & custom messages to establish IPC for multiple applications (client_tcp) and one process that controls LoRaWAN connectivity (server_tcp).
For more details about client side, please see client_tcp example.
This approach using TCP/IP sockets as IPC channel ensures controlled access to LoRaWAN connectivity.
The goals of using this approach are:
* Having a solid and reliable infrastructure to ensure IPC works fine for multiple applications simultaneously
* Having the possibility to host different IoT projects and solutions that use LPWAN in a single ESP32
* Having the possibility to host different IoT projects and solutions that use LPWAN in a single ESP32
* Having the possibility to validate, test and debug multiple IoT projects and solutions at the same time, under the same connectivity conditions (same signal strength, same antenna, same modem/transceiver, etc.)
Both client and server work on local network scope.
## How do I use this?
In order to test client_tcp & server_tcp together, there are two ways to proceed:
1) Init server manually (command: SERVER &), and after successfull server init, also init client manually (CLIENT 127.0.0.1)

@ -62,7 +62,7 @@
#define LORAWAN_DOWNLINK_TIME_MS 10000
#define MAX_MESSAGE_SIZE 12
#define SEND_MESSAGE 'U'
#define SEND_MESSAGE 'U'
#define DOWNLINK_RESPONSE 'D'
/****************************************************************************

@ -83,7 +83,7 @@ static int read_uart_lorawan_resp(unsigned char * ptr_response_buffer,
****************************************************************************/
#define PATH_TO_UART1 "/dev/ttyS1"
#define FULL_AT_CMD_MAX_SIZE 200
#define FULL_AT_CMD_MAX_SIZE 200
#define TIME_BETWEEN_AT_CMDS 1 //s
#define MAX_ATTEMPTS_TO_SEND 3

@ -15,7 +15,7 @@ config EXAMPLES_TIMER_GPIO
connected to the digital output. This example differs from the timer
example because it waits on a sigwaitinfo() instead of using a signal
handler. This approach ensures a deterministic wake-up time when the
signal occurs.
signal occurs.
if EXAMPLES_TIMER_GPIO

@ -10,10 +10,10 @@ config EXAMPLES_WATCHED
---help---
This application works with the watcher example and plays
the role of the watched task. This process will create 2
watched tasks. These tasks will subscribe to be watched.
watched tasks. These tasks will subscribe to be watched.
One task will feed the dog and the other will starve the dog.
So, the watchdog timer will expire and the offending task will
be printed.
be printed.
if EXAMPLES_WATCHED

@ -10,7 +10,7 @@ config EXAMPLES_WATCHER
depends on FSUTILS_MKFATFS
---help---
Enable the watcher example. The watcher is a task that will monitor
other tasks that have previously subscribed to be watched. If the
other tasks that have previously subscribed to be watched. If the
watched tasks don't signal the watcher during the watchdog time period,
the watchdog timer will expire and the watcher will print the tasks that
did not signal and the ones that signaled. This example will only be supported

@ -2,7 +2,7 @@
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
config NETUTILS_IPERF
bool "iperf example"
default n
@ -14,7 +14,7 @@ config NETUTILS_IPERF
Enable the \"iperf example\"
if NETUTILS_IPERF
config NETUTILS_IPERF_PROGNAME
string "Program name"
default "iperf"

@ -5,7 +5,7 @@ implemented in Zephyr by Laczen. We made several modification to the original de
The main purpose of those modification was:
1. support C-string key in nvs API(Original design only support uint16_t as key)
2. Meanwhile achieve better performance by limiting flash read times(Theoratically
better than Zephyr subsys/settings, which is based on original NVS).
better than Zephyr subsys/settings, which is based on original NVS).
- `CONFIG_TESTING_FAILSAFE_MTD_CONFIG` Enable the test.