uCANca

h1. Flows

A flow is a [[magnitude]] (logical or physical) "flowing" through the system.  Examples are:

* The voltage sensed by an ADC in an MCU pin.

* The voltage through a connector pin.

* The signal that enables the CAN transceiver.

* An internal data of the Microcontroller.

* A CAN signal.

...

The flow is described by:

|_.Property|_.Description|_.Required?|

|name| Name of the flow| (v) |

|type| [[Flow Type|Type]] of the flow| (v) |

|primary flow direction| Describes the primary [[direction of the flow]].  A flow can be used in many parts of the system with different directions, but this is the global "intention" of the flow towards the system | (x) |

We can see a flow that is representing a digital input of the system: the ignition button of the car.

http://ucanca.gatatac.org/flows/34-in-but-ignition

{{iframe(http://ucanca.gatatac.org/flows/34-in-but-ignition,1024,400,yes)}}

In this web page we can see:

* Flow properties:

** Type (in this case is a DIO - digital input output -).

* SubSystem flows: the subsystems that are using the flow.  In this example we can read:

** The CU subsystem (CU is the abbreviation of ControlUnit in this project) is using it as an input located the first pin of its J3 connector.

** The CU_micro subsystem (it is actually the microcontroller inside the ControlUnit system) is using it as an input located in the pin 11 of its {{fn(PINOUT, microcontrollers do not have different connectors, we usually use a virtual PINOUT connector that groups all the inputs and outputs.  Sometimes we make a partition of the real pinout, f.i. FUNCTIONAL pins and MCUSUPPORT pins for functonal I/O and support I/O like the oscillator, the power or the ADC reference of a microcontroller)}} connector.

** The CU_micro_lights subsystem (actually a functional software module called LIGHTS inside the microcontroller software) is using it as pin {{fn(7,when dealing with software modules, this number is irrelevant)}} of its {{fn(DRE,Data Runtime Environment, another virtual connector that represents the pool of sofware variables shared by all the software modules as an internal bus)}} connector.

* The automatically generated source code.  If a flow is relevant to software it normally has a software data variable inside the DRE.  Here we can see how that variable will be declared and how will be acquired or synthesized.  We will review how this is done later in this tour.

* The automatically generated {{fn(calibration configuration code,uCANca does not include the calibration module yet, as it has been implemented as standalone tool and still have to be merged into uCANca.  See the roadmap at http://gatatac.org/projects/ucanca/roadmap)}}.

In the next chapter we will visit a subsystem.