Signals and Systems from KiCad to C** {{ ::snaiks-logo.png?nolink&200 }} 7.4.2016 —- ===== 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. ===== Mini-Demo =====




===== 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:

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 = ...
		}
	}
	...
}

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.

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 system generated by Snaiks should be fully discoverable and manipulatable during runtime.

• 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

• list inputs and outputs of an object
• list properties of an object
• change property values permanently