i'll follow your progress, sounds interesting. lets see some code!
i'll follow your progress, sounds interesting. lets see some code!
Steveo,
I'll try to get some preliminary info up this weekend. Since it's based on the Arduino platform it's written in a C/C++ compliant language and right now is pretty rudimentary with a ton of "if" statements lol. I am interested in how much user adjustability people would be interested in. I.e. you want to raise line pressure or alter tps/map vs vehicle speed shift patterns. I have considered, initially, the use of a three position slider switch to choose from 3 levels of operation, since not everyone is comfortable writing code. But I am always open to suggestions as I wish this to be as user friendly as possible.
Buddrow
If it don't fit force it, if it don't force fit f&%@ it!
well, it's an arduino, so ensure you have a defined data section, and have a tunerpro xdf that alters the tables/constants in all of your patterns, and your customers could just load the altered bin. wouldn't be that hard. just think "im building an ecm here".
i could help you with that part, i'm not bad with c for embedded platforms (never had an arduino though)
It sounds like an interesting project. If you can make it work, using a MAP sensor instead of a TPS sensor could be handy since that would be easier to install.
If you expect much commercial success then you'll need to have it fairly adjustable. You pretty much need to have the ability to alter each shift curve.
Steveo, Im not building an "ecm" Im building a tcm lol :) but I hear what youre saying. I may bug you on how to integrate the tunperpro xdf since I have no exp with that.
If it don't fit force it, if it don't force fit f&%@ it!
if the language would allow (never used this compiler) an easy way to (usually) ensure something ends up as a constant in the data section with a pointer to it (instead of inline with the code), putting it as a pointer to a constant in global space is usually what you want:
of course the compiler will put it wherever the hell it wants in the binary, but locating it in the binary is easy after, just compile two versions, one 0x05 and one 0x06 and see what changes. then throw the location and any conversion in the xdf, and you're good to go.Code:char *lockup_min_spd = 0x05; void function() { if(lockup_min_spd >= current_spd) /* do whatever */ };
what you're trying to avoid by doing this, is the compiler going "oh! it'll be faster if we just replicate the data in this case" (or worse, using a #define, that pretty much forces it to replicate when used). that would mean you'd have to have two or more constants in your XDF that do the same thing, which would be dumb.
many compilers will screw you over and optimize it out sometimes if you put it in local function scope, or do all sorts of trickery or optimizations on the value..
Thanks for the input Steveo. I have the constants global so any part of the code can use those variables. With only basic inputs(more are in the code for different gear selections, manual/auto mode, etc) like tps/map and vss it seems easier that way. I have to admit its been 20+ years since ive written much code(BASIC) until this project. The code is a bit "clunky" but at 16mips its more than adequate for this project. As of now its a basic shift box that reads 2 inputs and has 4 outputs. Ill have to sit i front of the laptop this weekend and figure out how to make an xdf and linking it to the controller.
Buddrow
If it don't fit force it, if it don't force fit f&%@ it!
UPDATE:
Project is moving right along. Code is nearing completion and hardware testing is coming in the next week or two.
Looking for a tester or two if anyone is interested pm me.
If it don't fit force it, if it don't force fit f&%@ it!
Bookmarks