remove examples/xxx/README.md. Migrated to Documentation/applications/examples
part of examples/bastest is moved to examples/bastest.testcases.md
This commit is contained in:
raiden00pl
Xiang Xiao
parent
14f19f0e7d
commit
7e918964e4
2187
examples/README.md
2187
examples/README.md
File diff suppressed because it is too large
Load Diff
@ -1,49 +1,3 @@
|
||||
# Examples / `bastest` Bas BASIC Tests
|
||||
|
||||
This directory contains a small program that will mount a ROMFS file system
|
||||
containing the BASIC test files extracted from the BAS `2.4` release.
|
||||
|
||||
## Background
|
||||
|
||||
Bas is an interpreter for the classic dialect of the programming language BASIC.
|
||||
It is pretty compatible to typical BASIC interpreters of the 1980s, unlike some
|
||||
other UNIX BASIC interpreters, that implement a different syntax, breaking
|
||||
compatibility to existing programs. Bas offers many ANSI BASIC statements for
|
||||
structured programming, such as procedures, local variables and various loop
|
||||
types. Further there are matrix operations, automatic LIST indentation and many
|
||||
statements and functions found in specific classic dialects. Line numbers are
|
||||
not required.
|
||||
|
||||
The interpreter tokenises the source and resolves references to variables and
|
||||
jump targets before running the program. This compilation pass increases
|
||||
efficiency and catches syntax errors, type errors and references to variables
|
||||
that are never initialised. Bas is written in ANSI C for UNIX systems.
|
||||
|
||||
## License
|
||||
|
||||
BAS `2.4` is released as part of NuttX under the standard 3-clause BSD license
|
||||
use by all components of NuttX. This is not incompatible with the original BAS
|
||||
`2.4` licensing
|
||||
|
||||
Copyright (c) 1999-2014 Michael Haardt
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
|
||||
the Software, and to permit persons to whom the Software is furnished to do so,
|
||||
subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
|
||||
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
|
||||
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
|
||||
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
||||
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
# Test Overview
|
||||
|
||||
## `test01.bas`
|
||||
@ -1,42 +0,0 @@
|
||||
# Examples / `camera` Camera Snapshot
|
||||
|
||||
This sample is implemented as `camera` command on NuttX Shell. The synopsis of
|
||||
the command is as below.
|
||||
|
||||
```
|
||||
nsh> camera ([-jpg]) ([capture num])
|
||||
|
||||
-jpg : this option is set for storing JPEG file into a strage.
|
||||
: If this option isn't set capturing raw RGB565 data in a file.
|
||||
: raw RGB565 is default.
|
||||
|
||||
capture num : this option instructs number of taking pictures.
|
||||
: 10 is default.
|
||||
```
|
||||
|
||||
Storage will be selected automatically based on the available storage option.
|
||||
|
||||
Execution example:
|
||||
|
||||
```
|
||||
nsh> camera
|
||||
nximage_listener: Connected
|
||||
nximage_initialize: Screen resolution (320,240)
|
||||
Take 10 pictures as RGB file in /mnt/sd0 after 5 seconds.
|
||||
After finishing taking pictures, this app will be finished after 10 seconds.
|
||||
Expier time is pasted.
|
||||
Start capturing...
|
||||
FILENAME:/mnt/sd0/VIDEO001.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO002.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO003.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO004.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO005.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO006.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO007.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO008.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO009.RGB
|
||||
FILENAME:/mnt/sd0/VIDEO010.RGB
|
||||
Finished capturing...
|
||||
Expier time is pasted.
|
||||
nximage_listener: Lost server connection: 117
|
||||
```
|
||||
@ -1,23 +0,0 @@
|
||||
# Examples / `flash_test` SMART Flash Device Test
|
||||
|
||||
```
|
||||
Author: Ken Pettit
|
||||
Date: April 24, 2013
|
||||
```
|
||||
|
||||
This application performs a SMART flash block device test. This test performs a
|
||||
sector allocate, read, write, free and garbage collection test on a SMART MTD
|
||||
block device. This test can be built only as an NSH command
|
||||
|
||||
**Note**: This test uses internal OS interfaces and so is not available in the
|
||||
NUTTX kernel build
|
||||
|
||||
```
|
||||
Usage:
|
||||
|
||||
flash_test mtdblock_device
|
||||
|
||||
Additional options:
|
||||
|
||||
--force to replace existing installation
|
||||
```
|
||||
@ -1,17 +0,0 @@
|
||||
# Examples / `flowc`
|
||||
|
||||
General Usage Instructions:
|
||||
|
||||
1. The receiver side enter, start the receiver program. The receiver is now
|
||||
waiting to receive data on the configured serial port.
|
||||
2. On the sender side start the sender program. This will send data to the
|
||||
receiver which will verify that no data is lost.
|
||||
|
||||
On Linux, you can alternatively do:
|
||||
|
||||
```bash
|
||||
$ stty -F /dev/ttyACM0 crtscts
|
||||
$ cat testdata.dat >/dev/ttyACM0
|
||||
```
|
||||
|
||||
where you need to replace `/dev/ttyACM0` with your selected serial device.
|
||||
@ -1,82 +0,0 @@
|
||||
# FOC example
|
||||
|
||||
The main purpose of this example is to provide a universal template to
|
||||
implement the motor controller based on the kernel-side FOC device and
|
||||
the application-side FOC library.
|
||||
|
||||
At the moment, this example implements a simple open-loop velocity controller.
|
||||
|
||||
# Hardware setup
|
||||
|
||||
This example has not yet implemented any mechanism to protect the
|
||||
powered device. This means that there is no overtemeprature
|
||||
protection, no overcurrent protection and no overvoltage protection.
|
||||
|
||||
Make sure that you power the device properly and provide current
|
||||
limits on your own so as not to break your hardware.
|
||||
|
||||
# Configuration
|
||||
|
||||
The FOC PI current controller parameters can be obtained from the given
|
||||
equations:
|
||||
|
||||
```
|
||||
Kp = ccb * Ls;
|
||||
pp = Rs / Ls;
|
||||
Ki = pp * Kp * T;
|
||||
```
|
||||
|
||||
where:
|
||||
Kp - PI proportional coefficient
|
||||
Ki - PI integral coefficient
|
||||
Rs - average phase serial resistance
|
||||
Ls - average phase serial inductance
|
||||
pp - pole plant
|
||||
ccb - current control bandwidth
|
||||
T - sampling period
|
||||
|
||||
## Sample parameters for some commercially available motors
|
||||
|
||||
* Odrive D6374 150KV
|
||||
p = 7
|
||||
Rs = 0.0254 Ohm
|
||||
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
|
||||
@ -1,298 +0,0 @@
|
||||
# Examples / `json` cJSON JSON Parser
|
||||
|
||||
This directory contains logic taken from the cJSON project:
|
||||
|
||||
http://sourceforge.net/projects/cjson/
|
||||
|
||||
This corresponds to SVN revision `r42` (with lots of changes for NuttX coding
|
||||
standards). As of `r42`, the SVN repository was last updated on `2011-10-10` so
|
||||
I presume that the code is stable and there is no risk of maintaining duplicate
|
||||
logic in the NuttX repository.
|
||||
|
||||
# Contents
|
||||
|
||||
- License
|
||||
- Welcome to cJSON
|
||||
|
||||
# License
|
||||
|
||||
Copyright (c) 2009 Dave Gamble
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
|
||||
the Software, and to permit persons to whom the Software is furnished to do so,
|
||||
subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
|
||||
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
|
||||
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
|
||||
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
||||
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
# Welcome to cJSON
|
||||
|
||||
cJSON aims to be the dumbest possible parser that you can get your job done
|
||||
with. It's a single file of C, and a single header file.
|
||||
|
||||
JSON is described best here: http://www.json.org/ It's like XML, but fat-free.
|
||||
You use it to move data around, store things, or just generally represent your
|
||||
program's state.
|
||||
|
||||
First up, how do I build? Add `cJSON.c` to your project, and put `cJSON.h`
|
||||
somewhere in the header search path. For example, to build the test app:
|
||||
|
||||
```bash
|
||||
gcc cJSON.c test.c -o test -lm
|
||||
./test
|
||||
```
|
||||
|
||||
As a library, cJSON exists to take away as much legwork as it can, but not get
|
||||
in your way. As a point of pragmatism (i.e. ignoring the truth), I'm going to
|
||||
say that you can use it in one of two modes: Auto and Manual. Let's have a quick
|
||||
run-through.
|
||||
|
||||
I lifted some JSON from this page: http://www.json.org/fatfree.html That page
|
||||
inspired me to write cJSON, which is a parser that tries to share the same
|
||||
philosophy as JSON itself. Simple, dumb, out of the way.
|
||||
|
||||
Some JSON:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Jack (\"Bee\") Nimble",
|
||||
"format": {
|
||||
"type": "rect",
|
||||
"width": 1920,
|
||||
"height": 1080,
|
||||
"interlace": false,
|
||||
"frame rate": 24
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Assume that you got this from a file, a webserver, or magic JSON elves,
|
||||
whatever, you have a `char *` to it. Everything is a cJSON struct.
|
||||
|
||||
Get it parsed:
|
||||
|
||||
```c
|
||||
cJSON *root = cJSON_Parse(my_json_string);
|
||||
```
|
||||
|
||||
This is an object. We're in C. We don't have objects. But we do have structs.
|
||||
|
||||
What's the framerate?
|
||||
|
||||
```c
|
||||
cJSON *format = cJSON_GetObjectItem(root,"format");
|
||||
int framerate = cJSON_GetObjectItem(format,"frame rate")->valueint;
|
||||
```
|
||||
|
||||
Want to change the framerate?
|
||||
|
||||
```c
|
||||
cJSON_GetObjectItem(format,"frame rate")->valueint = 25;
|
||||
```
|
||||
|
||||
Back to disk?
|
||||
|
||||
```c
|
||||
char *rendered = cJSON_Print(root);
|
||||
```
|
||||
|
||||
Finished? Delete the root (this takes care of everything else).
|
||||
|
||||
```c
|
||||
cJSON_Delete(root);
|
||||
```
|
||||
|
||||
That's AUTO mode. If you're going to use Auto mode, you really ought to check
|
||||
pointers before you dereference them. If you want to see how you'd build this
|
||||
struct in code?
|
||||
|
||||
```c
|
||||
cJSON *root,*fmt;
|
||||
root = cJSON_CreateObject();
|
||||
|
||||
cJSON_AddItemToObject(root, "name", cJSON_CreateString("Jack (\"Bee\") Nimble"));
|
||||
cJSON_AddItemToObject(root, "format", fmt = cJSON_CreateObject());
|
||||
cJSON_AddStringToObject(fmt,"type", "rect");
|
||||
cJSON_AddNumberToObject(fmt,"width", 1920);
|
||||
cJSON_AddNumberToObject(fmt,"height", 1080);
|
||||
cJSON_AddFalseToObject (fmt,"interlace");
|
||||
cJSON_AddNumberToObject(fmt,"frame rate", 24);
|
||||
```
|
||||
|
||||
Hopefully we can agree that's not a lot of code? There's no overhead, no
|
||||
unnecessary setup. Look at test.c for a bunch of nice examples, mostly all
|
||||
ripped off the json.org site, and a few from elsewhere.
|
||||
|
||||
What about manual mode? First up you need some detail.
|
||||
Let's cover how the cJSON objects represent the JSON data.
|
||||
cJSON doesn't distinguish arrays from objects in handling; just type.
|
||||
Each cJSON has, potentially, a child, siblings, value, a name.
|
||||
|
||||
The root object has: Object Type and a Child
|
||||
The Child has name "name", with value "Jack ("Bee") Nimble", and a sibling:
|
||||
Sibling has type Object, name "format", and a child.
|
||||
That child has type String, name "type", value "rect", and a sibling:
|
||||
Sibling has type Number, name "width", value 1920, and a sibling:
|
||||
Sibling has type Number, name "height", value 1080, and a sibling:
|
||||
Sibling hs type False, name "interlace", and a sibling:
|
||||
Sibling has type Number, name "frame rate", value 24
|
||||
|
||||
Here's the structure:
|
||||
|
||||
```c
|
||||
typedef struct cJSON {
|
||||
struct cJSON *next,*prev;
|
||||
struct cJSON *child;
|
||||
|
||||
int type;
|
||||
|
||||
char *valuestring;
|
||||
int valueint;
|
||||
double valuedouble;
|
||||
|
||||
char *string;
|
||||
} cJSON;
|
||||
```
|
||||
|
||||
By default all values are 0 unless set by virtue of being meaningful.
|
||||
|
||||
next/prev is a doubly linked list of siblings. next takes you to your sibling,
|
||||
prev takes you back from your sibling to you. Only objects and arrays have a
|
||||
"child", and it's the head of the doubly linked list. A "child" entry will have
|
||||
`prev==0`, but next potentially points on. The last sibling has `next=0`. The
|
||||
type expresses Null/True/False/Number/String/Array/Object, all of which are
|
||||
`#define`d in `cJSON.h`.
|
||||
|
||||
A Number has `valueint` and `valuedouble`. If you're expecting an `int`, read
|
||||
`valueint`, if not read `valuedouble`.
|
||||
|
||||
Any entry which is in the linked list which is the child of an object will have
|
||||
a "string" which is the "name" of the entry. When I said "name" in the above
|
||||
example, that's "string". "string" is the JSON name for the 'variable name' if
|
||||
you will.
|
||||
|
||||
Now you can trivially walk the lists, recursively, and parse as you please. You
|
||||
can invoke `cJSON_Parse` to get cJSON to parse for you, and then you can take
|
||||
the root object, and traverse the structure (which is, formally, an N-tree), and
|
||||
tokenise as you please. If you wanted to build a callback style parser, this is
|
||||
how you'd do it (just an example, since these things are very specific):
|
||||
|
||||
```c
|
||||
void parse_and_callback(cJSON *item, const char *prefix)
|
||||
{
|
||||
while (item)
|
||||
{
|
||||
size_t len = strlen(prefix) + strlen(item->name) + 2;
|
||||
char *newprefix = malloc(len);
|
||||
snprintf(newprefix, len, "%s/%s", prefix, item->name);
|
||||
int dorecurse = callback(newprefix, item->type, item);
|
||||
if (item->child && dorecurse) parse_and_callback(item->child, newprefix);
|
||||
item = item->next;
|
||||
free(newprefix);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The prefix process will build you a separated list, to simplify your callback
|
||||
handling. The `dorecurse` flag would let the callback decide to handle
|
||||
sub-arrays on it's own, or let you invoke it per-item. For the item above, your
|
||||
callback might look like this:
|
||||
|
||||
```c
|
||||
int callback(const char *name,int type, cJSON *item)
|
||||
{
|
||||
if (!strcmp(name,"name")) { /* populate name */ }
|
||||
else if (!strcmp(name,"format/type") { /* handle "rect" */ }
|
||||
else if (!strcmp(name,"format/width") { /* 800 */ }
|
||||
else if (!strcmp(name,"format/height") { /* 600 */ }
|
||||
else if (!strcmp(name,"format/interlace") { /* false */ }
|
||||
else if (!strcmp(name,"format/frame rate") { /* 24 */ }
|
||||
return 1;
|
||||
}
|
||||
```
|
||||
|
||||
Alternatively, you might like to parse iteratively.
|
||||
|
||||
You'd use:
|
||||
|
||||
```c
|
||||
void parse_object(cJSON *item)
|
||||
{
|
||||
int i; for (i=0; i < cJSON_GetArraySize(item); i++)
|
||||
{
|
||||
cJSON *subitem = cJSON_GetArrayItem(item, i);
|
||||
// handle subitem.
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Or, for PROPER manual mode:
|
||||
|
||||
```c
|
||||
void parse_object(cJSON *item)
|
||||
{
|
||||
cJSON *subitem = item->child;
|
||||
|
||||
while (subitem)
|
||||
{
|
||||
// handle subitem
|
||||
if (subitem->child) parse_object(subitem->child);
|
||||
|
||||
subitem = subitem->next;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Of course, this should look familiar, since this is just a stripped-down version
|
||||
of the callback-parser.
|
||||
|
||||
This should cover most uses you'll find for parsing. The rest should be possible
|
||||
to infer.. and if in doubt, read the source! There's not a lot of it! ;)
|
||||
|
||||
In terms of constructing JSON data, the example code above is the right way to
|
||||
do it. You can, of course, hand your sub-objects to other functions to populate.
|
||||
Also, if you find a use for it, you can manually build the objects. For
|
||||
instance, suppose you wanted to build an array of objects?
|
||||
|
||||
```c
|
||||
cJSON *objects[24];
|
||||
|
||||
cJSON *Create_array_of_anything(cJSON **items,int num)
|
||||
{
|
||||
int i;cJSON *prev, *root=cJSON_CreateArray();
|
||||
for (i=0;i<24;i++)
|
||||
{
|
||||
if (!i) root->child=objects[i];
|
||||
else prev->next=objects[i], objects[i]->prev=prev;
|
||||
prev=objects[i];
|
||||
}
|
||||
return root;
|
||||
}
|
||||
```
|
||||
|
||||
and simply: `Create_array_of_anything(objects,24)`;
|
||||
|
||||
cJSON doesn't make any assumptions about what order you create things in. You
|
||||
can attach the objects, as above, and later add children to each of those
|
||||
objects.
|
||||
|
||||
As soon as you call `cJSON_Print`, it renders the structure to text.
|
||||
|
||||
The test.c code shows how to handle a bunch of typical cases. If you uncomment
|
||||
the code, it'll load, parse and print a bunch of test files, also from json.org,
|
||||
which are more complex than I'd care to try and stash into a `const char
|
||||
array[]`.
|
||||
|
||||
Enjoy cJSON!
|
||||
|
||||
_Dave Gamble, Aug 2009_
|
||||
@ -1,138 +0,0 @@
|
||||
# Examples / MCUboot / `swap_test`
|
||||
|
||||
## Description
|
||||
|
||||
MCUboot Swap Image is an application to demostrate firmware upgrade using
|
||||
internal flash memory. It simulate MCUboot API steps to switch between two
|
||||
valid images.
|
||||
|
||||
This application add 3 Builtin Apps to NuttX NSH: version, set_img and confirm.
|
||||
After application is build and `nuttx.bin` be generated, the binary must be
|
||||
signed. Consult your board README file to get instructions how to do it.
|
||||
|
||||
## How to build and flash
|
||||
|
||||
First step is build your board configuraton using `mcuboot-loader` as target.
|
||||
That create the bootloader itself. The `nuttx.bin` must be flash as usual.
|
||||
|
||||
After that, clean up environment and set `mcuboot-swap-test` as target. The
|
||||
build output will generate the `nuttx.bin` file. You should execute the MCUboot
|
||||
script called `imgtool.py` and sign the binary file two times.
|
||||
|
||||
The first time you will use `--version 1.0.0` and `signedv1.bin` as output file.
|
||||
Then, the second sign you need change to `--version 2.0.0` and `signedv2.bin`
|
||||
as output file.
|
||||
|
||||
The `signedv1.bin` file must be at MCUboot Slot-0 partition and `signedv2.bin`
|
||||
at Slot-1.
|
||||
|
||||
More instructions about how to sign and flash can be found at board README file.
|
||||
|
||||
## Running swap image test
|
||||
|
||||
Open you terminal and reboot your board. You can see a similar output as below.
|
||||
You can check builtin apps using command `?`.
|
||||
|
||||
```bash
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
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
|
||||
|
||||
Builtin Apps:
|
||||
mcuboot_set_img mcuboot_confirm sh
|
||||
mcuboot_version ramtest nsh
|
||||
nsh>
|
||||
```
|
||||
|
||||
First step (check version):
|
||||
|
||||
```bash
|
||||
nsh> mcuboot_version
|
||||
Image version 1.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
Second step (mark image as good because it is running). This is an optional
|
||||
step that must be executed if you ran `imgtool.py` without optional parameter
|
||||
`--confirm`.
|
||||
|
||||
```bash
|
||||
nsh> mcuboot_confirm
|
||||
Application Image successfully confirmed!
|
||||
nsh>
|
||||
```
|
||||
|
||||
Third step (let's reboot and see whats happen):
|
||||
|
||||
```bash
|
||||
nsh> reboot
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
NuttShell (NSH) NuttX-10.2.0
|
||||
nsh> mcuboot_version
|
||||
Image version 1.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
Fourth step (let's switch image):
|
||||
|
||||
```bash
|
||||
nsh> mcuboot_set_img
|
||||
Requested update for next boot. Restarting...
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
NuttShell (NSH) NuttX-10.2.0
|
||||
nsh> mcuboot_version
|
||||
Image version 2.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
Now, we switched from image version 1.0.0 to image 2.0.0. However, we intentionaly
|
||||
will not run `mcuboot_confirm` app.
|
||||
|
||||
```bash
|
||||
nsh> reboot
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
NuttShell (NSH) NuttX-10.2.0
|
||||
nsh> mcuboot_version
|
||||
Image version 1.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
This means that if for any reason App reboot, have a malfunctioning or not boot,
|
||||
MCUboot will switch back to old `good` image! Remember that we executed
|
||||
`mcuboot_confirm` at step two.
|
||||
|
||||
Fifth step (switch to image version 2 and mark as permanent):
|
||||
|
||||
```bash
|
||||
nsh> mcuboot_set_img
|
||||
Requested update for next boot. Restarting...
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
NuttShell (NSH) NuttX-10.2.0
|
||||
nsh> mcuboot_confirm
|
||||
Application Image successfully confirmed!
|
||||
nsh> mcuboot_version
|
||||
Image version 2.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
Sixth step (Reboot and confirm V2 image):
|
||||
|
||||
```bash
|
||||
nsh> reboot
|
||||
*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
|
||||
NuttShell (NSH) NuttX-10.2.0
|
||||
nsh> mcuboot_version
|
||||
Image version 2.0.0.0
|
||||
nsh>
|
||||
```
|
||||
|
||||
Conclusion, once we boot a newer image and confirm it MCUboot always run that
|
||||
image, unless you instruct it to swap again!
|
||||
@ -1,25 +0,0 @@
|
||||
This is a simple MQTT publisher example using MQTT-C
|
||||
|
||||
By default it publishes to the "test" topic and exits. Default behaviour
|
||||
including, host, port, topic, message and loop count can be changed through
|
||||
different arguments.
|
||||
|
||||
To test:
|
||||
From the host start an MQTT broker and subscribe to the "test" topic. Here
|
||||
mosquitto is used:
|
||||
|
||||
```
|
||||
mosquitto&
|
||||
mosquitto_sub -t test
|
||||
```
|
||||
Make sure that mosquitto is not configured in local mode only.
|
||||
|
||||
From the nsh:
|
||||
|
||||
Launch the built-in app `mqttc_pub` specifying the host:
|
||||
|
||||
```
|
||||
mqttc_pub -h HOST
|
||||
```
|
||||
|
||||
The target will publish the message "test".
|
||||
@ -1,17 +0,0 @@
|
||||
# Examples / `pdcurses` PDCurses Demos
|
||||
|
||||
This directory contains demonstration programs to show and test the capabilities
|
||||
of `pdcurses` libraries. Some of them predate PDCurses, PCcurses or even
|
||||
`pcurses`/`ncurses`. Although some PDCurses-specific code has been added, all
|
||||
programs remain portable to other implementations (at a minimum, to `ncurses`).
|
||||
|
||||
## Building
|
||||
|
||||
The demos are built by the platform-specific makefiles, in the platform
|
||||
directories. There are no dependencies besides curses and the standard C
|
||||
library, and no configuration is needed.
|
||||
|
||||
## Distribution Status
|
||||
|
||||
Public Domain, except for `rain_main.c` and `worm_main.c`, which are under the
|
||||
ncurses license (MIT-like).
|
||||
@ -1,26 +0,0 @@
|
||||
# Client TCP
|
||||
|
||||
## 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).
|
||||
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 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)
|
||||
2) init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
|
||||
|
||||
## Additional info
|
||||
|
||||
Both tcp_ipc_client and tcp_ipc_server examples have been full covered in NuttX International Workshop 2022. You can watch the full presentation here: https://www.youtube.com/watch?v=hr0OfTt1KeY
|
||||
The tcp_ipc_server and tcp_ipc_client examples have been developed by Flavio Ipirranga and Pedro Bertoleti from Instituto de Pesquisas Eldorado (IPE) in Brazil.
|
||||
@ -1,28 +0,0 @@
|
||||
# Server TCP
|
||||
|
||||
## 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).
|
||||
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 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)
|
||||
2) init server automatically after boot using NuttShell start up scripts (check: https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts )
|
||||
|
||||
## Additional info
|
||||
|
||||
Both client_tcp and server_tcp examples have been full covered in NuttX International Workshop 2022. You can watch the full presentation here: https://www.youtube.com/watch?v=hr0OfTt1KeY
|
||||
The server_tcp and client_tcp examples have been developed by Flavio Ipirranga and Pedro Bertoleti from Instituto de Pesquisas Eldorado (IPE) in Brazil.
|
||||
@ -1,43 +0,0 @@
|
||||
# Examples / `tcpblaster` TCP Performance Test
|
||||
|
||||
To set up, do `make menuconfig` and select the _Apps_ → _Examples_ →
|
||||
_tcpblaster_. By default, nuttx will the be the client which sends data; and the
|
||||
host computer (Linux, macOS, or Windows) will be the server.
|
||||
|
||||
Set up networking so the nuttx computer can ping the host, and the host can ping
|
||||
nuttx. Now you are ready to run the test.
|
||||
|
||||
On host:
|
||||
|
||||
```
|
||||
$ ./tcpserver
|
||||
Binding to IPv4 Address: 00000000
|
||||
server: Accepting connections on port 5471
|
||||
```
|
||||
|
||||
On nuttx:
|
||||
|
||||
```
|
||||
nsh> tcpclient
|
||||
Connecting to IPv4 Address: 0100000a
|
||||
client: Connected
|
||||
[2014-07-31 00:16:15.000] 0: Sent 200 4096-byte buffers: 800.0 KB (avg 4.0 KB) in 0.18 seconds (4444.4 KB/second)
|
||||
```
|
||||
|
||||
Now on the host you should see something like:
|
||||
|
||||
```
|
||||
$ ./tcpserver
|
||||
Binding to IPv4 Address: 00000000
|
||||
server: Accepting connections on port 5471
|
||||
server: Connection accepted -- receiving
|
||||
[2020-02-22 16:17:07.000] 0: Received 200 buffers: 502.9 KB (buffer average size: 2.5 KB) in 0.12 seconds (4194.8 KB/second)
|
||||
[2020-02-22 16:17:07.000] 1: Received 200 buffers: 393.1 KB (buffer average size: 2.0 KB) in 0.09 seconds (4299.4 KB/second)
|
||||
```
|
||||
|
||||
This will tell you the link speed in KB/sec – kilobytes per second. If you want
|
||||
kilobits, multiply by `8`.
|
||||
|
||||
You can use the `make menuconfig` to reverse the setup, and have nuttx be the
|
||||
server, and the host be the client. If you do that, start the server first
|
||||
(nuttx), then start the client (host).
|
||||
@ -1,7 +0,0 @@
|
||||
# Examples / `telnetd` Telnet Daemon
|
||||
|
||||
This directory contains a functional port of the tiny uIP shell. In the NuttX
|
||||
environment, the NuttShell (at `apps/nshlib`) supersedes this tiny shell and
|
||||
also supports telnetd.
|
||||
|
||||
This example is retained here for reference purposes only.
|
||||
Loading…
x
Reference in New Issue
Block a user