Continuous signal transmission in Vector CANoe - simulation

I have created a node in CANoe by using Vector software and I asigned the designed database for it.
I need to transmit a continuous messages, for that I created a panel with button. When I keep pressing on the buton the signal of the message should always take the value 1 otherwise its 0 (button released)
The message that should be transmitted have this caraczeristics:
My code for transmetting the message after pressing the button :
variables {
message messageDeclaredInDb myMessage;
msTimer cyclicTimer200ms;
}
on envVar ev_Button_Status
{
switch (getValue(this)) {
case 0: myMessage.Sig = 0;
write("button released");
break;
case 1: myMessage.Sig = 1;
write("button pressed");
break;
default: write("Default");
}
setTimerCyclic(cyclicTimer200ms, 200);
}
on timer cyclicTimer200ms
{
myMessage.Sig = getValue(ev_Button_Status);
output(myMessage);
}
And I visualize the result in the Graphics:
But the wanted result should be like this without the up and down of the signal:
Any tips please? knowing that I don't use any Interaction Layer.

Note the GenMsgILSupport = Yes attribute, meaning the Interaction Layer support is enabled for this message. The IL is responsible for receiving and transmitting messages according to the attributes (like cycle time) defined in the database.
Using IL support, you can access the signals directly. You neither need to define message variables nor timers, just put a $ character before the signal name and set the value. Example:
$Sig = 1;
Complete example 1:
on envVar ev_Button_Status
{
switch (getValue(this)) {
case 0:
$Sig = 0;
write("button released");
break;
case 1:
$Sig = 1;
write("button pressed");
break;
default:
write("Default");
}
}
If you don't use any Interaction Layer, make sure it is disabled for your message. Furthermore, the are some issues with you code:
You should start the timer in on start, not in on envVar.
Set the signal value in on envVar or on timer, but not in both.
Complete example 2:
variables {
message messageDeclaredInDb myMessage;
msTimer cyclicTimer200ms;
}
on start
{
setTimerCyclic(cyclicTimer200ms, 200);
}
on timer cyclicTimer200ms
{
myMessage.Sig = getValue(ev_Button_Status);
output(myMessage);
}

Related

How to code latch switch function using STM32?

I am looking a code to get the latch switch function using STM32.
The below code which I have tried is working in stm32 but only a push button function without latch.
while (1)
{
if(HAL_GPIO_ReadPin(GPIOC,GPIO_PIN_13)== GPIO_PIN_RESET )
{
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET);
}
else
{
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET);
}
}
Can some one help me to make the GPIOA,GPIO_PIN_5 pin high always on the first press of the button and the GPIOA,GPIO_PIN_5 low always at the second press ?
The function will be similar as in the below video https://www.youtube.com/watch?v=zzWzSPdxA0U
Thank you all in advance.
There are several problems with the code. There is no memory function and you are reading the button at max speed.
This is fixed by sleeping for a period of time to allow for human reaction speed and button noise. You also need a variable to store the previous state.
while (1)
{
if(HAL_GPIO_ReadPin(GPIOC,GPIO_PIN_13)== GPIO_PIN_RESET )
{
static bool state = false;
if(state == false)
{
state = true;
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET);
}
else
{
state = false
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET);
}
while(HAL_GPIO_ReadPin(GPIOC,GPIO_PIN_13)== GPIO_PIN_RESET){} // wait for button to be released, otherwise it will keep toggling every 500ms
}
delay_ms(500);
}
This is C++ code as it uses bool. int with the values 1 and 0 can be used for C.
What is done is a variable state is declared and kept in heap memory because of the static keyword. (Instead of stack memory which would be destroyed when the scope of the outer if statement is exited) It is initialized to false and then updated when you press the button.
Possible (crude) solution:
#include <stdbool.h>
#define BUTTON_DOWN() (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET)
#define LED(on) HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, (on) ? GPIO_PIN_SET : GPIO_PIN_RESET)
static bool _pressed_before = false;
static bool _led = false;
/* somewhere in main loop */
{
const bool pressed = BUTTON_DOWN();
if (pressed && !_pressed_before) { /* button pressed? */
_led = !_led; /* toggle LED state */
LED(_led);
}
_pressed_before = pressed; /* remember state */
}
Some notes:
Instead of constantly polling the state, you could use an external GPIO interrupt (search for GPIO EXTI). And it is almost always necessary to use hardware debouncing on the button pin (RC filter) and/or use software debouncing to prevent falsely detected edges. - Also: This question is not really STM32 / hardware specific, so you could find more general answers by searching the webs more broadly on these topics.

Part of my PlayerExpChangeEvent is being overridden by vanilla

I'm making a spigot plugin (version 1.8.8) that has an function that I know works because it fires flawlessly through my command. However, when I call it at the end of a PlayerExpChangeEvent, it seems like vanilla leveling overrides the bar, making it go up way more that it is supposed to. Running the command/function after this happens makes the bar go back to how it is supposed to be. I've tried setting my event's priority to highest (and when that didn't work, to lowest) but no matter what my function appears to be completely ignored when called inside the event.
Here is some code:
#EventHandler(priority=EventPriority.HIGHEST)
public void onXpGain(PlayerExpChangeEvent event)
{
// Load custom levels from config
ArrayList<String> levelList = new ArrayList<String>(plugin.getConfig().getStringList("levels"));
if (!((String)levelList.get(0)).equals("none"))
{
Player player = event.getPlayer();
Iterator<String> var4 = levelList.iterator();
while (var4.hasNext())
{
String s = (String)var4.next();
String[] splits = s.split(" ");
int levelCompare = Integer.parseInt(splits[0]);
int playerLvl = player.getLevel();
// Detect if on correct tier, else continue iteration
if (playerLvl == levelCompare - 1)
{
// Calculate the player's new XP amount
int totalXp = player.getTotalExperience() + event.getAmount();
player.setTotalExperience(totalXp);
updateBar(event.getPlayer()); // <-- THIS IS THE FUNCTION
return;
}
}
// At max level
player.setTotalExperience(player.getTotalExperience() + event.getAmount());
player.setLevel(getHighestLevel(levelList));
player.setExp(1.0f);
}
}
And here is the function itself. Keep in mind that it works fine when called through a command and not an event. It's purpose is to use the player's total XP to set the level and bar. Neither set correctly in the event; it instead embraces vanilla leveling.
public static void updateBar(Player player) {
ArrayList<String> levelList = new ArrayList<String>(plugin.getConfig().getStringList("levels"));
int totalXp = player.getTotalExperience();
player.setLevel(getHighestLevelForXp(totalXp, levelList));
if (player.getLevel() < getHighestLevel(levelList)) {
int lvlDiff = getTotalXpToLevel(player.getLevel() + 1,levelList) - getTotalXpToLevel(player.getLevel(),levelList);
int xpDiff = totalXp - getTotalXpToLevel(player.getLevel(),levelList);
player.setExp((float)xpDiff/lvlDiff);
} else {
player.setLevel(getHighestLevel(levelList));
player.setExp(0.0f);
}
return;
}
The command where the function works correctly is a bare-bones call to the function and doesn't need a mention here. Does anyone know how to get my event to override vanilla xp gain? The update works through the command, just not natural xp gain. It is already confirmed that the event DOES fire, as the rest of the event changes the internal xp amount, but the visual effects are overridden by vanilla. Can anyone help? Thanks.
Only setting the Player's EXP won't be enough for your desired behaviour. The Vanilla behaviour will still complete, as you're not changing how the event will add EXP to the player.
Currently, your event is working like this:
And PlayerExpGainEvent isn't cancellable, so you cannot undo it's addition of EXP.
What you can do instead is to set the EXP the event will add to 0, therefore not changing the player's EXP after your interception.
event.setAmount(0); //Cancelling the EXP addition
I would recommend to set your event to a high priority, so that other events that depend on Experience gain won't trigger when you set the amount gained to 0.

Using signal() inside handler function

I have taken this example from GNU library. And I wonder why they call signal() function twice, first time in main() when setting up the signal handler and second time inside handler function itself.
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
/* This flag controls termination of the main loop. */
volatile sig_atomic_t keep_going = 1;
/* The signal handler just clears the flag and re-enables itself. */
void
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}
void
do_stuff (void)
{
puts ("Doing stuff while waiting for alarm....");
}
int
main (void)
{
/* Establish a handler for SIGALRM signals. */
signal (SIGALRM, catch_alarm);
/* Set an alarm to go off in a little while. */
alarm (2);
/* Check the flag once in a while to see when to quit. */
while (keep_going)
do_stuff ();
return EXIT_SUCCESS;
}
Now my code...
void createTimer(long freq_nanosec)
{
timer_t timerid;
struct sigevent sev;
struct itimerspec timerint;
struct sigaction saction;
/* Establish handler for timer signal */
saction.sa_flags = 0;
saction.sa_handler = OnTimer;
sigemptyset(&saction.sa_mask);
sigaddset (&saction.sa_mask, SIGIO);
if (sigaction(SIGALRM, &saction, NULL) == -1) error("sigaction");
else printf("OnTimer handler created\n");
/* Create real time signal */
sev.sigev_notify = SIGEV_SIGNAL;
sev.sigev_signo = SIGALRM;
sev.sigev_value.sival_ptr = &timerid;
if (timer_create(CLOCKID, &sev, &timerid) == -1) error("timer_create");
else printf("timer ID is 0x%lx\n", (long) timerid);
/* Arm the timer */
timerint.it_value.tv_sec = timerint.it_interval.tv_sec =
freq_nanosec / 1000000000;
timerint.it_value.tv_nsec = timerint.it_interval.tv_nsec =
freq_nanosec % 1000000000;
if (timer_settime(timerid, 0, &timerint, NULL) == -1)
error("timer_settime");
else printf("Timer armed\n");
}
From the man page for signal, we see that when a signal arrives:
first either the disposition is reset to SIG_DFL, or the signal is blocked (see Portability below), and then handler is called with argument signum.
So after the signal arrives, further signals will revert to default behavior. In your sample code, the handler is choosing to re-set the signal handler so further signals will be handled in the same manner as the first.
This is noted in the comment for the function catch_alarm in the code you found.
There are two popular versions of signal, which differ in whether the disposition of a signal is reset to the default when the handler is called, and whether a signal is blocked for the duration of its handler's execution.
The standard says those two behaviors are implementation-defined. The first code sample
void
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}
is assuming that the implementation may reset the signal disposition to the default when the handler is called. That's like calling signal(sig, SIG_DFL) in the first line of the handler. You almost never want that, because the next time a SIGALRM signal comes in, the default action is for the program to be killed. So the handler calls signal(sig, catch_alarm) to re-establish itself as the handler.
Your second code sample
saction.sa_flags = 0;
saction.sa_handler = OnTimer;
sigemptyset(&saction.sa_mask);
sigaddset (&saction.sa_mask, SIGIO);
if (sigaction(SIGALRM, &saction, NULL) == -1) error("sigaction");
uses sigaction, which is generally preferred over signal because you can specify exactly the behavior you want. The standard says
new applications should use sigaction() rather than signal().
When .sa_flags has the SA_RESETHAND flag on, the disposition of the signal is reset to the default when the handler starts, just like in (one version of) signal.
But in your case, that flag is off because you set .sa_flags to 0, so you don't need to write any code to re-establish the handler.

Android SensorManager registerListener - not possible to set custom interval of sensor events

I wanted to set an individual interval of sensor events beside:
the given delays: "SENSOR_DELAY_NORMAL, SENSOR_DELAY_U, SENSOR_DELAY_GAME, ENSOR_DELAY_FASTEST".
But non of the "registerListener" methodes seems to support an individual value:
Looking into the implementation of the SensorManager class shows:
public boolean registerListener(SensorEventListener listener, Sensor sensor, int rateUs,
int maxBatchReportLatencyUs) {
int delay = getDelay(rateUs);
return registerListenerImpl(listener, sensor, delay, null,maxBatchReportLatencyUs, 0);
}
private static int getDelay(int rate) {
int delay = -1;
switch (rate) {
case SENSOR_DELAY_FASTEST:
delay = 0;
break;
case SENSOR_DELAY_GAME:
delay = 20000;
break;
case SENSOR_DELAY_UI:
delay = 66667;
break;
case SENSOR_DELAY_NORMAL:
delay = 200000;
break;
default:
delay = rate;
break;
}
return delay;
}
Is there realy no way to set an individual value for the sensor event interval?
SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, etc are all simply integers, as shown in your code. Saying you want SENSOR_DELAY_UI is the same as telling the sensor manager to use an interval of 66667 microseconds. However, per the docs, you can simply input your own interval in that field:
The desired delay between two consecutive events in microseconds. This is only a hint to the system. Events may be received faster or slower than the specified rate. Usually events are received faster. Can be one of SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME, SENSOR_DELAY_FASTEST or the delay in microseconds.
However, it's important to note the other part of that quote:
...The desired delay between two consecutive events in microseconds. This is only a hint to the system....
At the end of the day, it's just a suggestion and the Android system doesn't seem to be too good about respecting your request. If you really care about the interval I would suggest adding a method in your callback that checks the time delta between now and the last time you recorded a sensor value and then only recording it if its been sufficiently long.
Source: Android Link
You can simply use a Timer and a boolean flag to handle this problem:
imagine you want to check sensor event values every 1 seconds(for example):
boolean mustReadSensor;
Timer timer = new Timer();
timer.scheduleAtFixedRate(new TimerTask() {
#Override
public void run() {
mustReadSensor = true;
}
}, 0, 1000); // 1000 ms delay
and here is onSensorChanged:
#Override
public void onSensorChanged(SensorEvent event) {
if (!mustReadSensor) {
return;
}
mustReadSensor = false;
//handle sensor values here
}

How do I implement a timer for this code?

-(void) play
{
CMMotionManager *motionManager = [[CMMotionManager alloc] init];
[motionManager startDeviceMotionUpdates];
BOOL timeReached = NO;
while(!self.stopButtonPressed)
{
if(motionManager.deviceMotion.userAcceleration.y >= ... && motionManager.deviceMotion.userAcceleration.y <= ...)
{
//start timer
}
while(motionManager.deviceMotion.userAcceleration.y >= ... && motionManager.deviceMotion.userAcceleration.y <= ... && !timeReached)
{
if(//check timer & if timer is >=300ms)
{
timeReached = YES;
NSLog(#"acceleration on Y-axis stayed between ... & .. for at least 300ms");
}
}
}
}
It seems like you're going about this the wrong way; instead of running a clock, you should be setting accelerometerUpdateInterval to whatever you're looking for and using startAccelerometerUpdatesToQueue:withHandler: to receive the data.
From the Apple documentation:
Handing Motion Updates at Specified Intervals
To receive motion data
at specific intervals, the application calls a “start” method that
takes an operation queue (instance of NSOperationQueue) and a block
handler of a specific type for processing those updates. The motion
data is passed into the block handler. The frequency of updates is
determined by the value of an “interval” property.
Accelerometer. Set the accelerometerUpdateInterval property to specify
an update interval. Call the
startAccelerometerUpdatesToQueue:withHandler: method, passing in a
block of type CMAccelerometerHandler. Accelerometer data is passed
into the block as CMAccelerometerData objects.
Once you've set everything up, let it run. When you've received a completion notice from the block look at the data you've received.