Sure, but that's not normal driving and even though it should be possible this situation should simply never occur outside of a racetrack, a regular driver will move their one foot from the gas and move it to the brake.
It is better to leave options open rather than to lock things behing explicit configuration in the abscence of readily available documentation.
Which I assure you, Service/Operators manuals are not.
Global variables in that kind of codebase might be -really- hard to keep track of how you are accessing and writing them :/.
This gets really fucking nasty when you're doing things like setting it to volatile and potentially accessing it across threads and you end up with a partial write and then doing a read, etc.
I'm sure the axiom of "it's never tested as much as we want" still probably applies here and that's slightly terrifying.
also FTA: 2272 - global variable declared with different types
“Spaghetti code”: Incomprehensible code due to unnecessary coupling, jumps, gotos, or high complexity
Yeah that sounds fun. really fun. This is why I purposefully never work on any system that could kill someone. I just can't imagine being in charge of something like that and not wanting to go insane with knowing my code wasn't checked enough. or I wasn't careful enough.
(It's specifically Matlab Simulink for those playing along at home)
The thing that I never got is why there are plenty of high level languages that have 'global' more or less as the default. This is asking for trouble. Side effects should be very carefully introduced and reasoned about and kept to an absolute minimum, not be the default sauce to sprinkle across your codebase, the possible number of states increases very rapidly if you do that.
1. Please don't do circus on public roads.
2. If you're on private roads, well, you know, front-wheel-drive cars tend to handle poorly in fast corners. Do yourself a favour and get a RWD or AWD or something.
This does not seem like a valid use case for driving on public roads.
Driving in the snow often requires this because the brake acts as a poor man’s diff lock which gives you more traction. You can see the effect at speeds as low as 30kph in snow – a nice slow speed even in the city.
You just hold the brake (lightly) with one foot, and gas with the other? This doesn't sound as useful as putting the car in 2nd, or rocking back and forth?
Neither of those cause the wheel with more traction to get any torque. Applying the brakes lightly will. Rocking and manually preventing wheelspin with the brake can be combined.
In theory, traction control will as well, but traction control may also intervene and decrease power right when you need it as you're getting unstuck, so there's potential merit in turning it off and preventing excess wheelspin with the brake yourself.
Source: I learned to drive in Alaska, and I have used this technique.
Thanks!
If people don't come out of a system interaction smarter than they went in, you're not doing it right. You're writing checks their continued ignorance will increasingly extort hogher costs from, and which will culminate in the formation of a lever of control in the form of manufacturers making decisions for people, usurping ultimate end agency.
I just don't buy that that's how the world should work. You can't build a better world without building better, more knowledgable people. We engineers spend too long making machines that do things for people without making clear why they exist and how they work.
I'm done with the "for their own good" BS.
We should empower people, not manipulate them through engineering usecases to/to not accommodate.
https://www.mazdamotorsports.com/2019/02/07/a-better-faster-...
And Spec Miata is a pretty terrible example anyways... at the point where you're dumping 10k into a $500 motor I don't think you can talk about stock anything...
Worth noting that 'statically allocated' and 'global' aren't the same thing. Whether they're making that distinction in the powerpoint I'm not really sure because it's more of a language specific thing and the document isn't quite that technical.
As for how you do that, in C/C++ you can add `static` to a global variable declaration to make it "local" to the file/compilation-unit it is declared in. The variable itself still works the same from within the file, but a static variable cannot be "seen" outside the file even with an `extern`, so it can only be (easily) modified from functions inside the file. Doing it this way allows you the big advantages of static allocation (in many cases the only real option) while still allowing you to encapsulate the variables within a sane API that the rest of the code uses.
Edit: Actually page 39 references this, saying that 89% of the variables are not locally scoped. There are still ways to achieve some level of encapsulation even without using `static` but it's effectiveness drops a lot since anyone can just write an `extern` line and ruin your day...
If you want a race car, buy a race car.
Why do you need the brakes? The nearest freeway on ramp to my home is unusually short, and it's a 270 degree turn. I've had to get very good at getting my vehicle to accelerate as quickly as possible around that curve so that I can merge safely when the on ramp ends.
I don't need the brakes to do that, in fact the front brakes in most vehicles are usually much stronger and the braking bias is usually weighted greatly in favor of the front brakes. So again, I really don't know why you need the brake, especially in a front wheel drive car... you're just fighting the engine and the brakes can usually win that fight (except for in high powered rear wheel drive cars where the rear brakes are weak and the engine can overpower them).
This isn't relevant for your example as in your example, you are entering the freeway on-ramp at a low speed and accelerating throughout the entire corner. Navigating a corner at highest possible speed means you're arriving at the corner at a high speed and must decelerate in order to make the corner.
It's not immediately clear to me why you would use gas and brake at the same time in an automatic transmission vehicle. The only reason I can think of would be to keep the revs of the engine in the powerband and prevent the car from downshifting so that you can immediately have full power when you accelerate out of the apex. In a manual transmission vehicle, there's a technique called heel-and-toe where you blip the gas pedal with your heel to rev-match the engine on your downshift while braking with your toe and depressing the clutch with your left foot, but you're never introducing force to the front wheels that would counter the force of the brakes.
When cornering hard, because of weight transfer, the inner wheel loses almost all traction, which makes it impossible to send any torque to it without wheel spin. This means that you can't really accelerate out of a sharp turn with an open-diff vehicle, because an open diff always sends the same torque to both wheels, i.e. if the inner wheel spins without much resistance, that resistance equals the torque sent to the outer wheel.
A poor-man's-LSD-solution to this is applying a bit of brakes while also giving it a lot of gas. The brakes prevent the inner wheel from spinning freely and add artificial resistance, which increases the torque available at the outer wheel.
Ideally you'd only want to apply the brake on the inner wheel, which is what some cars actually do automatically as a fake-LSD solution, but applying both and wasting engine power is better than nothing.
As a professional in the embedded and safety critical systems space: No, they aren't "the way to go". You often end up with a small number (think "singletons" for OO people) but the rest can be done properly with local variables or more limited scope variables instead of garbage global variables to manage complex system state.
Function-scope static or file-scope static variables are the best place for variables in an embedded system written in C. They don't pollute the shared namespace, nor do they require allocation and de-allocation.
In an Arduino program, for example, you might have something like this, with a sketch.ino file:
#include <stdint.h>
#include "MyFile.h"
uint32_t Bad_Global_Variable;
// This doesn't conflict with same name in MyFile.cpp
static uint8_t state = 1;
void setup() {
setup_myFile();
state = 0;
}
void loop() {
loop_myFile();
}
#ifndef _MY_FILE_H_
#define _MY_FILE_H_
#include <stdint.h>
void setup_myFile(void);
void loop_myFile(void);
#endif // End include guard
#include "MyFile.h"
static uint32_t MyFileScopeVariable = 0;
// This doesn't conflict with same name in sketch.ino
static uint8_t state = 0;
void setup_myFile(void)
{
MyFileScopeVariable = 1;
// Can't access or have conflicts with myFunctionScopeVariable here
state = 1;
}
void loop_myFile(void)
{
static uint32_t myFunctionScopeVariable = 0;
MyFileScopeVariable++;
myFunctionScopeVariable++;
}
Statically allocated global variables are easy and available, suitable for small embedded systems written by one person or a small group of collaborators who can be expected to know about every variable in the program or at least to be able to refactor their code if it collides with an existing name. Adding a prefix to your statically allocated global variables (eg. 'mf_state' for a global variable in the MyFile library above) is another way to reduce collisions, but isn't compiler-enforced.
Statically allocated file-scope or function-scope variables are a best practice in an automotive ECU scale projects, and can reduce issues if you've got lots of vendors each contributing code and not a lot of visibility between projects.
Mario, when you do this move, is your third foot on the clutch?
Heel-and-toe shifting is used before entry into a turn while a vehicle is under braking, preparing the transmission to be in the optimal range of rpm to accelerate out of the turn.
There are vastly more people who are just bad drivers who use both feet like this out of poor skills or bad habit. Afaik this was the main cause of "unintended acceleration" with panicked drivers.
No you won't.
> As an Arduino enthusiast I see statically allocated (global?) variables are frequently the way to go for an embedded system, the frontier is to be able to prove the correctness of what you're doing.
When you have 2kB of RAM to play with you haven't got a lot of stack or heap to sling function parameters around on, so it's Through The Looking Glass and you do it all backwards - everything goes in a global unless you have a really really good reason for having local scope (loop counters would be a good example).
If you’re going around corners as fast as possible in a front wheel drive car, sell it and buy an AWD or RWD car that doesn’t understeer.
If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
The article also says that global variables will kill you, putting variables on the stack will kill you but doesn't say where it is safe to put variables. I can't imagine the heap is any better, that a garbage collector isn't going to pause and kill you, etc.
As an Arduino enthusiast I see statically allocated (global?) variables are frequently the way to go for an embedded system, the frontier is to be able to prove the correctness of what you're doing.