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
|
# Test Overview
|
||||||
|
|
||||||
## `test01.bas`
|
## `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