You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Check the [docs](./docs) folder. No need to read all this stuff - it is just for help and reference.
71
-
- Check issuesand discussions including the closed items.
71
+
- Check [issues](https://github.com/rokath/trice/issues)and [discussions](https://github.com/rokath/trice/discussions) including the closed items.
72
72
73
73
## Debugging using VS-Code and Clang for a Trice-instrumented Project in Direct-Out Mode over SEGGER-RTT
74
74
@@ -94,6 +94,19 @@ The Trice cache keeps copies of all to `trice i` or `trice c` passed files after
94
94
95
95
For example an auto-formatter should get active **before** the `tice insert` command.
96
96
97
+
## Wich mode to use?
98
+
99
+
- For the development direct mode with SEGGER_RTT is recommended.
100
+
- Most use cases are coverable in deferred mode with TRICE_BUFFER == TRICE_RING_BUFFER (less RAM needs) in TRICE_MULTI_PACK_MODE (less transfer data).
101
+
102
+
## Project Status
103
+
104
+
Trice is full usable and there are no known bugs (see [issues](https://github.com/rokath/trice/issues)).
105
+
106
+
## Future
107
+
108
+
The documentation could get improved, for example by adding a quick start help. Additional features like remote procedure calls could be described and a separate tlog, maybe written in C, would allow logging on any platforms - not only **Go** supported ones.
Copy file name to clipboardExpand all lines: _test/ReadMe.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,16 +2,16 @@
2
2
3
3
## General info
4
4
5
-
This folder is per default renamed into`_test` to avoid vsCode slow down.
5
+
This folder is per default named to`_test` to avoid vsCode slow down.
6
6
7
7
The main aim of these tests is to automatic compile and run the target code in different compiler switch variants avoiding manual testing this way.
8
8
9
9
For the user it could be helpful to start with a `triceConfig.h`file from here and to adapt the Trice tool command line from the matching `cgo_test.go` if no close match in the `examples` folder was found.
10
10
11
11
## How to run the tests
12
12
13
-
- In `trice` folder first execute `go clean -cache`. Cleaning the **Go** cache is recommended, because the CGO tests somehow keep pre-compiled files and when editing C-files, this can led to confusing results.
14
-
- To run the tests `cd` into `_test` and execute `go test ./...`.
13
+
- In `_trice` folder first execute `go clean -cache`. Cleaning the **Go** cache is recommended, because the CGO tests keep pre-compiled files and when editing C-files, this can led to confusing results.
14
+
- To run the tests `cd` into `_test` and execute `go test ./...` fom there.
15
15
16
16
## Tests Details
17
17
@@ -27,7 +27,7 @@ To be able to run `go test ./...` successfully without running the [./updateTest
27
27
28
28
The folders `tf` are Go packages just for tests. They all have the same package name `cgot` and are not included into the trice tool. The different `cgot` packages are independent and could have any names. They do not see each other and are used for target code testing independently.
29
29
30
-
The `tf/triceConfig.h` files differ and correspondent to the `tf/cgo_test.go` files in the same folder. On test execution, the `./testdata/*.c` files are compiled into the trice test executable together with the trice sources `../src` using the `tf/triceConfig.h` file.
30
+
The `tf/triceConfig.h` files differ and correspondent to the `tf/cgo_test.go` files in the same folder. On test execution, the `./testdata/*.c` files are compiled into the trice test executable together with the trice sources `../src` using the `tf/triceConfig.h` file.
31
31
32
32
The individual tests collect the expected results (`//exp: result`) together with the line numbers into a slice to execute the test loop on it. The `triceLogTest` function gets the `triceLog` function as parameter.
33
33
@@ -46,7 +46,7 @@ The `testdata\cgoPackage.go` file contains a variable `testLines = n`, which lim
46
46
47
47
## Test Internals
48
48
49
-
The `./trice/_test/testdata/*.c` and `./trice/src/*.c` are compiled together with the actual cgot package into one singe Trice test binary, resulting in as many test binaries as there are test folders. Calling its TestFunction(s) causes the activation of the Trice statement(s) inside *triceCheck.c*. The ususally into an embedded device compiled Trice code generates a few bytes according to the configuration into a buffer. These bytes are transmitted usually in real life over a (serial) port or RTT. In the tests here, this buffer is then read out by the Trice tool handler function according to the used CLI switches and processed to a log string using the *til.json* file. This string in then compared to the expected string for the activated line.
49
+
The `./trice/_test/testdata/*.c` and `./trice/src/*.c` are compiled together with the actual cgot package into one singe Trice test binary, resulting in as many test binaries as there are test folders. Calling its TestFunction(s) causes the activation of the Trice statement(s) inside *triceCheck.c*. The ususally into an embedded device compiled Trice code generates a few bytes according to the configuration into a buffer. These bytes are transmitted usually in real life over a (serial) port or RTT. In the tests here, this buffer is then read out by the Trice tool handler function according to the used CLI switches and processed to a log string using the *til.json* file. This string is then compared to the expected string for the activated line.
50
50
51
51
Each `tf` is a **Go** package, which is not part of any **Go** application. They all named `cgot` and are only used independently for testing different configurations. The `tf/generated_cgoPackage.go` file is identical in all `tf`. Its master is `testdata/cgoPackage.go`. After editing the master, running the command `./updateTestData.sh` copies the master to all `tf` and renames it to `generated_cgoPackage.go`.
52
52
@@ -57,7 +57,7 @@ When running `go test ./tf`, a Trice tool test executable is build, using the Tr
57
57
During the test, the file `triceCheck.c` is scanned for lines like
58
58
59
59
```C
60
-
reak; case __LINE__: TRice( iD(3537), "info:This is a message without values and a 32-bit stamp.\n" ); //exp: time: 842,150_450default: info:This is a message without values and a 32-bit stamp.
60
+
break; case __LINE__: TRice( iD(3537), "info:This is a message without values and a 32-bit stamp.\n" ); //exp: time: 842,150_450default: info:This is a message without values and a 32-bit stamp.
61
61
```
62
62
63
63
Some C-code lines contain Trice statements and comments starting with `//exp: ` followed by the expected Trice tool output for that specific line. The **Go** testfunction collects these outputs in a slice together with the line numbers. Then for each found line number the execution of the **Go** function `func triceCheck(n int)` takes part, which in turn calls the CGO compiled C-function `TriceCheck(n)`. The now activated Trice C-code writes the generated trice bytes in a between **C** and **Go** shared buffer using the C-function `TriceWriteDeviceCgo`. After returning from the **Go** function `func triceCheck(n int)` and optionally calling `TriceTransfer` in deferred mode the Trice tool `triceLog()` function converts the Trice buffer bytes to the log string and compares the result with the expected data. The between **Go** and **C** shared buffer limits the executed Trices per line to one, because they use the same buffer from the beginning. This could be done better with an increment to allow several trices in one single line.
0 commit comments