Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- snaiks [2017/03/17 09:31] – [Goals] dokuwikiadmin
+++ snaiks [2024/09/19 12:14] (aktuell) – dokuwikiadmin
@@ Zeile 1: / Zeile 1: @@
 ====== Snaiks ======
-**Signals and Systems from KiCad to C++**
+**Signals and Systems from KiCad to Cpp**
 March 2017
@@ Zeile 12: / Zeile 12: @@
-**Snaiks** provides a tool chain to get from a signal plan, drawn in **KiCad**s schematic editor to a generated standard **C++** code, runnable on **any platform**.
+**Snaiks** provides a tool chain to get from a signal plan, drawn in **KiCad**s schematic editor to a generated standard **Cpp** code, runnable on **any platform**.
 This tool chain consists of following parts:
   * **Snaiks KiCad Library**, providing all the symbols
-  * **Snaiks Compiler**, generating C++ code out of KiCads netlist
+  * **Snaiks Compiler**, generating Cpp code out of KiCads netlist
-  * **Snaiks C++ Library**, defining the functionality of the KiCad symbols
+  * **Snaiks Cpp Library**, defining the functionality of the KiCad symbols
-It's purpose is to create complex systems by drawing them in KiCad's schematic editor and generate out of the netlist a working C++ code, which also compiles for micro controllers without dynamic memory allocation.
+It's purpose is to create complex systems by drawing them in KiCad's schematic editor and generate out of the netlist a working Cpp code, which also compiles for micro controllers without dynamic memory allocation.
 It can be used to implement PLCs or digital signal processing like filtering.
 ===== Goals =====
-  * Generate beautiful C++ code from a KiCad schematic
+  * Generate beautiful Cpp code from a KiCad schematic
   * Compiles without dynamic memory allocation (embedded, safety)
   * Read and write system states during runtime (e.g. with a simple terminal)
@@ Zeile 30: / Zeile 30: @@
   * Hierarchical design (sub-systems)
   * full documentation within the schematic
-===== Mini-Demo =====
-{{ ::2016-04-07_001.png?direct&900 |}} \\
-{{::2016-04-07_002.png?direct&400 |}} \\
-{{::2016-04-07_003.png?direct&400 |}} \\
-{{::2016-04-07_005.png?direct&500 |}} \\
-{{::2016-04-07_006.png?direct&700 |}} \\
-===== Source Code =====
+===== Status =====
-  * https://gitlab.com/KarlZeilhofer/Snaiks-cpp-lib
+==== Implemented ====
-  * https://gitlab.com/KarlZeilhofer/Snaiks-kicad-lib
+  * A set of basic blocks in KiCad and Cpp
-  * https://gitlab.com/KarlZeilhofer/Snaiks-manual-tests
+  * Snaiks Compiler, in alpha state
+  * auto arrangement of block-execution to provide transparent behavior
-===== Blue Prints =====
-==== Sampled vs. Transparent Systems ====
-=== The Problem ===
-For some systems it would be handy, if they are transparent from input to output. \\
-This means, that they do not consume a whole clock cycle. An example could be a simple And-gate. Perhaps one do not want this gate to introduce an extra clock-cycle, until the combined signal is visible on the output. \\
-The drawback of this method is, that the update-order of all the systems is very important. If the user is aware of this problem, he can shorten latencies of complex systems.
-In Snaiks example test1 we had a undesired behaveour, because the And-gate befor the middle output indroduced a delay of one clock. In transitions from "within range" to "too high" and to "too low" undesired states were produced, were either 2 outputs were true at the same time, or where no output was true for one clock cycle. \\
-This made the antiGlitchDelays necessary.
-=== The Proposal ===
+==== Open Tasks ====
-Every System has a flag **transparent** which is by default false. \\
+  * communication with the system in runtime
-If it is true and sample() is called, update() is called from the sample() function:
+  * unit tests of all Snaiks Objects
-<code C>
-class MySystem
-{
-	...
-	bool transparent;
-	bool sampled=false;
-	...
-	void sample()
-	{
-		sInput = *input;
-		sampled = true;
-		if(transparent)
-		{
-			update();
-		}
-	}
-	void update()
+===== Mini-Demo =====
-	{
+[[https://gitlab.com/KarlZeilhofer/snaiks-demo-2|This demo project on GitLab.com]] shows the usage of snaiks in a simple console application, a Qt app with GUI and a realtime-application running on the [[RevolutionPi]]
-		if(sampled)  // avoid double update
-		{
-			sampled = false;
+===== Installer =====
-			output = ...
+TODO: make an installer repo, which clones all the sub-repos, compiles and installs the snaiks compiler, installs kicad and a demo project.
-		}
-	}
+  # using git clone --recursive to check out all submodules
-	...
+  git clone --recursive https://github.com/chaconinc/MainProject
-}
+===== Source Code =====
-</code>
+  * https://gitlab.com/KarlZeilhofer/snaiks-cpp-lib
+  * https://gitlab.com/KarlZeilhofer/snaiks-kicad-lib
+  * https://gitlab.com/KarlZeilhofer/snaiks-compiler
+===== Library Presentation =====
+  * https://gitlab.com/KarlZeilhofer/snaiks-kicad-lib-presentation
+  * {{ ::snaiks-lib-presentation.pdf |Presentation as PDF}} (perhaps outdated)
+===== Blue Prints =====
-This also makes the flag sampled necessary. Becaus the normal clock master calls every sample() and then every update(). A second update-run shouldn't change anything, but consumes perhaps unnecessay processing time.
 ==== Properties ====
@@ Zeile 119: / Zeile 96: @@
   * list properties of an object
   * change property values permanently
-==== Hierarchical Systems ====
-It should be possible to combine a set of systems to a sub-system, where new inputs and outputs are defined.
-KiCads hierarchical schematic structure could be used out of the box, but in C++ we do not see anything from this. Similar to the KiCad PCB layout, which also doesn't know anything about a hierarchical sheets. Altium Designer has the so called rooms, which group and synchronize footprint arrangement and traces between multiple instances of one hierarchical sheet.
-For the systems we should make something similar to the properties, which live in a SnsPropertyContainer. We should make a SnsSystemContainer, which provides on one hand memory for the different objects of a sub-system and on the other hand new inputs and outputs.
@@ Zeile 136: / Zeile 106: @@
 Cons:
   * every pin must have a type specified in KiCad (could be done with net-annotators, similar to PWR_FLAG).
-  * we cannot use a simple template-interface class any more, such as the SnsHybrid or SnsNumeric.
+  * we cannot use a simple template-interface class any more
 === Proposal ===
-  * in cases, where this is really needed, a specific C++ class could be implemented
+  * in cases, where this is really needed, a specific Cpp class could be implemented
   * mixture of numbers and bool shouldn't be any problem
-{{tag>english software signals kicad snaiks}}
+{{tag>english software signals kicad snaiks technical}}