Author
Topic: My life, My coding (Read 17121 times)

OK, since I have ADD when it comes to coding, and always float around in my projects, here's a place I'll be posting my code, whatever section of project it belongs to

This morning's breakthrough.. I got a preliminary working test of my live tuning working... I was able to change the map values over the serial port.. it takes a lot of parsing.. and I will yet set some of the parameters in stone.

Attached is the project, I have it set to not read from EEPROM at this point because you won't have any valid data in there to load anyhow.So here's how I have the data structure laid out so far when sent from the serial monitor

int Command, int Address, int Value to read a variable, the low bit of Command is 0, to write the bit is 1The high byte of the address currently refers to which data structure to read from (0000 0001 for Boostmap), and the low byte the address of the map (0 to 9*14)

Update... VB now populates the cell values and correctly writes updated values to the map.. it is certainly a beta version, and I will *try* to find a better programatic way of addressing, either with bitflags or something to reduce the number of if-then-else and switch/case statements to reduce Arduino load, but this works for now.. I will also have to look at setting up an interrupt to write to the CAN bus, but that's a ways off yet.

I had a bit of an issue because I still wanted to print out debug statements to the serial port, but be able to separate the debugging lines from the data lines, so for now I have data lines starting with "Data:" and it's parsed out in the VB code easily enough. I will also have to figure out how to switch between different maps, and maps of different sizes... I currently have a control array of textboxes, I may have to try and use datagrids instead

Still to be tested, I put this in a function that will be used when reading in most analog inputs, and probably some outputs as well.. I just find it ties everything into one neat little function, even though it does take a bit of time to execute, it may be worth it.

float GetSmoothedValue(float Newvalue, float NewvalueOldvalue, float smoothing, float Minchange, float Maxchange) { //provides a decaying infinite average.. Smoothing goes from 0 to 1, where 0 will yield an unchanging output! (you have been warned) //depending on read frequency and desired aggressiveness The benefit to this method //is it doesn't require an array to hold the history //The Deadband will prevent any change at all below a certain value (You have been warned) //MaxChange will limit the maximum change any given iteration... Make sure it is bigger than the deadband (You have been warned)

then I have different smoothing, minchange and maxchange values for every different input to tailor the response curve.

Next I will work on a function to linearize/delinearize, which I have used before.. it's especially handy when you have something you'd like to look linear which isn't.. perfect example is the VGT nozzle size where a small change at wide open is negligible, while a small change near closed is significant.. I'll just have to port it out to C++.

To prevent getting huge numbers, overflows, etc, I map the value so it can only fall between 0 and 1, which makes the output of the power function fall between 0 and 1 as well, after that I remap it back to it's original bounds.if you want a quick response at the top end, use a Response value of about 2 (squaring it).. A linear response uses 1, and a Square root response (quick near 0) is 0.5

I have all this in a class right now, but I'm fighting another weird bug in the arduino.. my loop times are wildly varying... Sometimes it's doing 60000 loops per second, then it'll fall on it's face and only do 60... don't know what gives yet.

Oh, and I should mention something too.. Not to be offensive, but I'm only glancing over the code you folk are posting here, the reason being I'd like to write something unique, problem-solve (at this point only in theory since I don't have the hardware yet), and try to find other ways to do things... Once I get my software a little more ironed out, and at least basically functional, I'll gladly try and study other code.Cheers

So all my input variables, as well as some of the output variables (like VGT position, AFC position) are of my own data type.. a type which keeps track of the update times, smooths out the jitter, limits the rate of change (min and max), and limits the extents.. It also recurves from linear to non-linear, so you can get a faster response at one end than the other. Not only that, but it also calculates the acceleration and rate of acceleration, which could be very handy later when optimizing VGT nozzle size for best spoolup.. but I'm not at that point yet.. for now it's just really neat.

For example with the minimum change, you apply a deadband, so it won't move unless it's a certain amount greater than the last value, excellent for minimizing VGT workload, the maximum change is good to prevent overshooting a target and preventing hunting for a setpoint. VGT example of that would be greater motion when it's wide open than when it's near closed, despite the rest of the code staying linear (which is easier that way)

I know that if I did have everything set up in my truck, I wouldn't be playing around with the code so much and adding so many features (aka bugs)

digital pins 2 and 3 are for RPM sensors, I have them wired to pins 12 and 13 that I toggle on and off to simulate an input.

Analog pin 0 is wired to a 0-5V pot and simulates TPS position, this you will see in the serial monitor (115200 baud) when you sweep the pot.. you will see the raw TPS value, smoothed value, as well as the slope and rate of change of slope...

I commented out some parts in the Constants file that are incompatible with non-Mega2560's... specifically the definition of analog input pins A8-15

To play with the smoothing settings, look in the "Initialization" tab, modify whatever.. I haven't implemented "Multiplier" yet though.

I also just added a bunch of boolean checks in "MyVar.h" that can disable deadband and limit enforcing, as well as disabling the slope calculations to save some CPU cycles on variables that really don't need it.

You will notice I also only read my analog inputs once, but do a bit of stuff between reads.. It appears to be pretty steady, on my pot on A0 I get at most a 1 ADC point fluctuation, and that's to be expected really

it is, but unless you just happen to be dividing by 2, you gotta do it the long way...

I also read somewhere that as long as the code fits onto the unit, and can keep up with what it needs to do, optimizing more than that is a waste of energy... Of course you don't want to deliberately write bloated or inefficient code, but there comes a time when you shouldn't worry too much about it

[...]Running the division test again, we reach completion in 153236 us, the same as our original case. This makes sense; if the compiler wasn’t optimizing the division code to begin with, adding an empty assembly instruction wouldn’t affect the compiled code at all.

For the multiplication test, each run now completes in 3896 us. Holy difference-maker, Batman. That’s blazing fast. It also is much more realistic than the first case, suggesting that our compiler trick worked and the loops are no longer being optimized away.

The end result is that multiplication is 97.46% quicker, or alternatively, 39.3x faster than division in this case. Interestingly, results for addition and subtraction were exactly the same: 3896 us per test.

AMP2 Corinthians 8:21For we take thought beforehand and aim to be honest and absolutely above suspicion, not only in the sight of the Lord but also in the sight of men.

//the following values are all wild guesses.. There's a CERTAINTY that some will need to be negative, and some may be zero//for example with the EGPV we aren't concerned about what the actual number is, but rather to maximize it, in which case//the slope and rate of change of slope may be of greater interest... at least in theory

According to the arduino documentation I read, floats ARE doubles.. Same structure with a different name..

I wish they had 16 bit floats though.. that would be good enough for me in ALL my calculations.. ALAS.. no such luck.. I'll have to write my own!

Meanwhile, we had some rainy weather here and I took advantage of that to work on more code... Trailer brake controller is done.VGT control is done, but evidently will need tweaking.. lots of itVGT has normal mode, warmup mode (increases backpressure), and jake mode

AFC control is done.. again lots of tweaking will need to happenCruise control is in progress, will be done once I stop surfing... I'm getting the hang of these outputs.. they all have PID controls on them and feedback loops, greatly facilitated with the "MyVar" class that calculates slope over time regardless of when you're updated it (it keeps track of the last update time).