====== Snaiks Study ======
**Signals and Systems from KiCad to C++**
{{ ::snaiks-logo.png?nolink&200|}}

7.4.2016\\
For Updates please see [[Snaiks]]

----

===== Introduction =====

Signals and Systems is here a collection of C++ classes on one hand, and a collection of corresponding KiCad components on the other hand. 

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 can be used to implement PLCs or digital signal processing like filtering. 

The C++ classes are based heavily on templates, so most of the components can be used either for floating point or for integer calculations. 

===== Goals =====
  * Generate beautiful C++ code from a KiCad schematic
  * Compiles without dynamic memory allocation (embedded, savety)
  * Read and write system states during runtime (e.g. with a simple terminal)
  * Simple custom system creation (KiCad component editor + sub-class implementation)
  * 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 =====
  * https://gitlab.com/KarlZeilhofer/Snaiks-cpp-lib
  * https://gitlab.com/KarlZeilhofer/Snaiks-kicad-lib
  * https://gitlab.com/KarlZeilhofer/Snaiks-manual-tests

===== 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 ===
Every System has a flag **transparent** which is by default false. \\
If it is true and sample() is called, update() is called from the sample() function:
<code C>
class MySystem
{
	...
	bool transparent;
	bool sampled=false;
	...
	void sample()
	{
		sInput = *input;
		sampled = true;
		if(transparent)
		{
			update();
		}
	}

	void update()
	{
		if(sampled)  // avoid double update
		{
			sampled = false;
			output = ...
		}
	}
	...
}
</code>

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 ====
A Snaiks component can have properties. For example:
  * monoflop period
  * schmitt trigger limits
  * saturation limits
  * corner frequency or filter-type of a digital filter
  * filter coefficients
  * gain value
  * value of constants

A property consists of 
  * a value
  * a name
  * a persistent initial value
  * a setter method
  * a getter method
  * a method to store a changed value into the persistent memory
==== Info-System ====
A system generated by Snaiks should be fully discoverable and manipulatable during runtime. 

=== Use cases ===
  * change filter characteristics
  * change regulator parameters
  * adjust offset or gain
  * change system constants
  * change enable/disable flags
  * reset a component or the whole system
  * start/stop recording

=== Needed Features ===
  * list inputs and outputs of an object
  * 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. 


==== Any-Type Inputs/Outputs ====
Perhaps it would be useful, that not all inputs must have the same type. For example a mute gate, where the enable is bool and the signal is double. 

Pros:
  * more flexible systems

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. 

=== Proposal ===
  * in cases, where this is really needed, a specific C++ class could be implemented
  * mixture of numbers and bool shouldn't be any problem

{{tag>english software signals kicad snaiks technical}}