CANopen CiA 401 input polarity - embedded

I'm trying to implement the CiA 401(I/O). But I don't know how the device should behave if the object 6002 (input polarity) changes.
Should the value in object 6000 (read input) also change and if so, a PDO should also be sent, although nothing has changed at the physical input?

The only mandatory input polarity objects are 6002:0 and 6002:1, and it should affect the polarity of the corresponding digital on/off objects objects mapped at 6000. Note that DS-401 lists an "Entry Category" which dictates which objects and indices that are mandatory and which that are optional.
If you map the input polarity, it will be a RPDO in your application, and affect whatever TPDO that 6002 is mapped into. As far as I remember, the values inside 6000 should not change, only the values of the relevant TPDO. This TPDO will only be sent when it should - that is, depending on how it is configured: cyclic, on change, on request etc.

Related

Accessing a combination of ports by adding both their offsets to a base address. How would this work?

Context: I am following an embedded systems course https://www.edx.org/course/embedded-systems-shape-the-world-microcontroller-i
In the lecture on bit specific addressing they present the following example on a "peanut butter and jelly port".
Given you a port PB which has a base address of 0x40005000 and you wanted to access both port 4 and port 6 from PB which would be PB6 and PB4 respectively. One could add the offset of port 4(0x40) and port 6(0x100) to the base address(0x40005000) and define that as their new address 0x40005140.
Here is where I am confused. If I wanted to define the address for PB6 it would be base(0x40005000) + offset(0x100) = 0x40005100 and the address for PB4 would be base(0x40005000) + offset(0x40) = 0x40005040. So how is it that to access both of them I could use base(0x40005000) + offset(0x40) + offset(0x100) = 0x40005140? Is this is not an entirely different location in memory for them individually?
Also why is bit 0 represented as 0x004. In binary that would be 0000 0100. I suppose it would represent bit 0 if you disregard the first two binary bits but why are we disregarding them?
Lecture notes on bit specific addressing:
Your interpretation of how memory-mapped registers are addressed is quite reasonable for any normal peripheral on an ARM based microcontroller.
However, if you read the GPIODATA register definition on page 662 of the TM4C123GH6PM datasheet then you will see that this "register" behaves very differently.
They map a huge block of the address space (1024 bytes) to a single 32-bit register. This means that bits[9:2] of the the address bus are not needed, and are in fact overloaded with data. They contain the mask of the bits to be updated. This is what the "offset" calculation you have copied is trying to describe.
Personally I think this hardware interface could be a very clever way to let you set only some of the outputs within a bank using a single atomic write, but it makes this a very bad choice of device to use for teaching, because this isn't the way things normally work.

What is lower and upper multiplicity in autosar configuration element?

What is lower and upper multiplicity in autosar configuration element (module, container, parameter or reference). What does it mean in code. I mean if a parameter is has lower multiplicity = 1, and upper multiplicity=5, how is it reflected in code when generated?
Multiplicity means how many times this element (parameter or container) can exist.
If lower and upper multiplicity are equal, there must be exactly so many instances of the element. Most common with lower == upper == 1.
If lower and upper multiplicity are not equal, then there may be as few elements as the lower multiplicity, and as many as the upper. Most common with lower == 0 and upper == 1, which means the element can exist 0 or 1 times. That is, it's optional.
If the upper multiplicity is denoted with an asterisk (*), it means infinite. So an element with lower == 1 and upper == * must have at least one instance, and can have arbitrarily many.
Multiplicity is not directly reflected in the generated code, but the number of instances in a particular configuration is.
As a very common example, the multiplicity of ComSignal under ComConfig is 0 to *. So there may be no ComSignal containers at all, or there may be any number of them. The generated code will certainly have a signal ID in Com_Cfg.h for each ComSignal element, but the details of the generated code depend on the generator used.
As per Autosar Software Architecture, General Requirements on Basic Software Modules.
“Multiplicity” defines how many times an entity (in this case configuration
parameter) is instantiated.
The multiplicity of each configuration parameter has to be documented.
Description:
It shall be documented what determines the number of entries (e.g. “one per
frame”).
Additional Info not in the documentation:
1.Containers are named as such because containers contain Configuration parameters.
A container /sub container can refer to other container/sub container, now the reference can hold a multiplicity value, multiplicity then defines the possible number of instances of the contained parameters.
Ofcourse an example always is better illustrious than these words
Example:
Dcm module contains(when I say contains it actually means a sub container from here), DcmConfigSet(exists one config for one set of Dcm configuration), if you need multiple Dcm Configuration you could add many of them, One DcmConfigSet contains
(DcmDsd[1],DcmDsl[1],DcmDsp[0..1],DcmGeneral[1],DcmPageBufferCfg[1],DcmProcessingConditions[0....1])
This means for subcontainers having referenced as [1] has the same lower and upper multiplicity hence one instance of each subcontainer should be configured, whereas for DcmDsp,DcmProcessingConditions (you can have 0 instantiation "no need to configure" or can be configured based on your functional needs- higher multiplicity 1).
I really hope I can share you some code, but autosar code is not open source so I can't share it. Still I hope you understand the gist.
The reference link is General Software Architecture

What kind of states and transitions does Spin's "depth reached" consider?

For verifications (with ispin) that use never claims, I get outputs with depth reached larger than the number of states and the number of transitions, e.g.:
Full statespace search for:
never claim + (REQ5)
assertion violations + (if within scope of claim)
cycle checks - (disabled by -DSAFETY)
invalid end states - (disabled by never claim)
State-vector 60 byte, depth reached 87, errors: 1
41 states, stored
10 states, matched
51 transitions (= stored+matched)
9 atomic steps
hash conflicts: 0 (resolved)
I find that a bit unintuitive. Is there a precise description of the semantics of "depth reached" somewhere (more thorough than pan's output format description)? Maybe the meaning of
longest depth-first search path contained 87 transitions
does not refer to the 51 transitions, but to the transitions of the system automata composed with the never claim?
Yes, you are (kind of) right when you say it refer to the transitions of the system automaton composed with the never claim. Yet in the same time it is the length of the path in the system being verified, because one step of system composed with never claim is exactly one step of the system. Of course depending on never claim one might need to explore more or less transition than system has. Paths are not even necessary loop free (depending on the claim) and even not minimal (unless special option is set).

Method to get non-base units?

Is there a method of using the exponent properties of LabView units for carrying custom units? For example I would find it convenient to use milli-Amperes instead of Amperes in my data wires.
My first attempt at doing so looks like this, but trying to get the value out at the end gives me nothing.
I would find it convenient to use milli-Amperes instead of Amperes in my data wires
For a wire, it's not possible, and it's not a problem, here's why:
I'm afraid what you want make little sense, since you're milli-Amperes instead of Amperes refers to representing your data, while a wire is just raw data. Adding the milli- to a floating point changes the exponent, not the mantissa, so there's no loss or gain of precision in the value that your number carries.
Now if we talk about an indicator which is technically a display of the wire value, you change the unit from "A" to "mA" to have the display you want.
Finally, in your attempt with "set numeric info", the -3 factor added next to Amperes means the unit is A^-3, not mA.
You can use data that don't use units, however than you will loose your automatic check of the units.
For display properties you can tweak the display format to show different outputs:
This format string is constructed as following:
% numeric
^ engineering notation, exponents in multiples of three
# no trailing zeros
_6 six significat digits
e scientific notation (1e1 for instance)
The prefix is the best way to affect the presentation of the value on a specific front panel.
When passing data from VI to VI, the prefix is not passed, and the data uses the base ( Amps, Volts, etc...)
In my example below, the unitless value 3 is assigned units of Amp in mA.vi. The front panel indicator is set to show units of mA.
In Watts.vi I multiply the Amps OUT of mA.vi by a constant of 9V and the result is wired to the indicator x*y.
x*y has units of W and I changed the prefix to k for presentation.
The NI forums have several threads that report certain functions (square and square root specifically) can cause unit errors or broken wires. Most folks don't even know the units capability exists, and most that do have tried and abandoned them. :)

Custom EQ AudioUnit on iOS

The only effect AudioUnit on iOS is the "iTunes EQ", which only lets you use EQ pre-sets. I would like to use a customized eq in my audio graph
I came across this question on the subject and saw an answer suggesting using this DSP code in the render callback. This looks promising and people seem to be using this effectively on various platforms. However, my implementation has a ton of noise even with a flat eq.
Here's my 20 line integration into the "MixerHostAudio" class of Apple's "MixerHost" example application (all in one commit):
https://github.com/tassock/mixerhost/commit/4b8b87028bfffe352ed67609f747858059a3e89b
Any ideas on how I could get this working? Any other strategies for integrating an EQ?
Edit: Here's an example of the distortion I'm experiencing (with the eq flat):
http://www.youtube.com/watch?v=W_6JaNUvUjA
In the code in EQ3Band.c, the filter coefficients are used without being initialized. The init_3band_state method initialize just the gains and frequencies, but the coefficients themselves - es->f1p0 etc. are not initialized, and therefore contain some garbage values. That might be the reason for the bad output.
This code seems wrong in more then one way.
A digital filter is normally represented by the filter coefficients, which are constant, the filter inner state history (since in most cases the output depends on history) and the filter topology, which is the arithmetic used to calculate the output given the input and the filter (coeffs + state history). In most cases, and of course when filtering audio data, you expect to get 0's at the output if you feed 0's to the input.
The problems in the code you linked to:
The filter coefficients are changed in each call to the processing method:
es->f1p0 += (es->lf * (sample - es->f1p0)) + vsa;
The input sample is usually multiplied by the filter coefficients, not added to them. It doesn't make any physical sense - the sample and the filter coeffs don't even have the same physical units.
If you feed in 0's, you do not get 0's at the output, just some values which do not make any sense.
I suggest you look for another code - the other option is debugging it, and it would be harder.
In addition, you'd benefit from reading about digital filters:
http://en.wikipedia.org/wiki/Digital_filter
https://ccrma.stanford.edu/~jos/filters/