2.x JimStim Support Request

MegaTunix is a cross-platform tuning application written and maintained by David J. Andruczyk. Discuss all things MTX here!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

mtx_man wrote:Committed/pushed, basic support for JimStim. *I need docs from jean about the "mode" bitfield and what it actually describes.

Docs on the wheel pattern loader would be nice too as that code doesn't make sense, and the file formats for the patterns aren't well defined/described. I can make sense of the dynamic rpm control stuff, which i plan on sticking into MTX's jimstim support once fred tests the basics..
.
The mode bit field is the wheel pattern number. The number 15 is not valid because that's the number used for serial communication and 31 is for when the user wants to use the DIP switches to control the wheel pattern (but this has to be done after powering up the JimStim and going to the serial comm mode). Numbers 47 and 63 are also invalid (ending in 0xF).

The names in the ini are for the patterns from the default wheel pattern file and what is loaded with the firmware. If a user uploads new patterns then the pattern names in the ini may no longer be correct as each pattern in the uploaded file is numbered sequentially (with the exception of 15, 31, 47 and 63 which are skipped). The numbering in the comments is not used by the code.

I'll see what I can do about documenting the wheel pattern loader. Let me just say that the wheel pattern file format defines one trigger transition per line (defined on one byte) where the first part is the state of the 2nd trigger and the first trigger as 2 bits and the second part is the number of degrees up to the next transition defined on 6 bits. If the actual pattern transition is more than 63 degrees then the transition is defined as many transitions of less than 63 degrees with the same 2 higher bit values for the trigger states. And the end of the pattern is done by using the terminating string 0xff (so using a 63 degree transition with both triggers set to on needs to be avoided as that would define the end of the pattern).

And the transfer is done in 2 steps. First, the wheel patterns are transmitted by parsing the wheel pattern file. The code is very simple and assumes the format is correct. The second part is the transmission of the relative position of each of the patterns in the first block (pointers to the wheel patterns). The first block is 3.5K and the second block is 512 bytes which means there could be up to 256 patterns.

As mentioned, the code is really simple and does not perform much validation of the inputs. And it does output a binary file which is the exact representation of the memory blocks. For most (all) users this output has not real use but it was useful during development and could be used for validation of MTX implementation.

Let me know if you need more details and what is actually problematic. I'll have to spend some time on this because it has been a while and I don't actually remember most of it except for the high level explanation above.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 2.x JimStim Support Request

Post by Fred »

Jean, I didn't read your post (though, I will later) but I did some testing:

http://stuff.fredcooke.com/jimstim.mtx.results.txt

Enjoy!

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

There definitely seems to be either a byte ordering or offset issue or some combination of both. Also, I'm not sure on which side the RPM limitation is in this case but some patterns will definitely be more limited than others on the JimStim side.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 2.x JimStim Support Request

Post by Fred »

Jean, I know, I found some limitations in the nippondenso one on my old jimstim chip, but that has 6x the teeth as the 4g63. Hmm, that rpm limitation could be roll over, I guess. Max is 32000 rpm, and that's exactly the difference to the measured figure. I'll have to look into that. In any case, the sound from my piezo was smooth, so i'm probably right about roll over and wrong about interrupt loading.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

The old chip was significantly slower: 8MHz vs 10MHz. I know the basic trigger will go above 50000 RPM and all the wheel patterns will go well above 10000 RPM with the slowest being the 60-2 pattern which has the smallest interval (I think it's still good for 14000RPM). I don't know the actual limit for all patterns but from the tests I've done with the pots (which limits RPM to about 16500 RPM) the only one that could be maxed out was the 60-2 pattern.

Also, RPM precision and granularity start to suffer somewhat at the upper end of the range due to the timer precision.

Jean
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

jean: is the endianness of this CPU different from MS-2?

I have the offsets defined in mtx exactly the same as the .ini, though the fpm input is screwed up, and feels like what you described where the upper and lower bytes are swapped.
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: 2.x JimStim Support Request

Post by jbelanger »

Dave,

The endianness is the same and I assumed you would use the same but I mentioned it because that would explain what Fred was seeing. I never even had to think about it with either MT or TS and the ini works with both (actually, I need to use a trimmed down number of wheel patterns with MT since it has a limit on the length of a line in the ini).

There are only 4 bytes that can be set with the rest of the 64-byte block being a placeholder for future stuff (which will likely not be used any time soon). Could there be an issue with MTx since the 16-bit word is aligned on an odd offset?

Jean
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

jbelanger wrote:Dave,

The endianness is the same and I assumed you would use the same but I mentioned it because that would explain what Fred was seeing. I never even had to think about it with either MT or TS and the ini works with both (actually, I need to use a trimmed down number of wheel patterns with MT since it has a limit on the length of a line in the ini).

There are only 4 bytes that can be set with the rest of the 64-byte block being a placeholder for future stuff (which will likely not be used any time soon). Could there be an issue with MTx since the 16-bit word is aligned on an odd offset?

Jean

Nope, cause MS2 does that all over the place and it appears to work perfectly fine there.. I did notice when testing via freds system remotely that the commanded rpm (via mtx TS or whatever) caused the rpm synthesized by the stim to be way off, I wanted fred to try TS for a comparison, but he doesn't trust TS (neither do I), so I can understand his reluctance to do so. I'm waiting for the chip i ordered from you a day or two ago plus the FTDI cable, so i can test locally.
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

I've found and fixed the bug in MTX with jimstim RPM control. The jimstim uses an API pretty close to MS-1, where a write is done one byte at a time since there's no "length" parameter in the write call unlike MS-2 which does have that. MS 1 write api is just "W + offset + 8bit value). however jimstim used a 16 bit variable, this is a fringe case that MTX never handled correctly (only applied to MS-1 style api where it was limited to one byte at a time writes). I've put in the proper checks to determine this and to send two separate writes, there is a very slight possibility this may break when being used on esoteric (bigendian host hardware), like some sparcs or PPC setups running in BE mode. I've tested this and verified it works as intended on fredcooke's setup. I can NOT yet push up to github as they are having a database server outage, though when it is resolved, I'll push back up with them.

Thx fred/jean for the help.

-- David
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: 2.x JimStim Support Request

Post by dandruczyk »

Added -P CLI option for megatunix to specifiy a specific serial port (disabled autoscanning). useful to prevent it from grabbing the wrong port on a multi-connected ecu 'puter or jimstim + ecu both plugged into the host computer..

i.e.
megatunix -P /dev/ttyUSB1 < starts up, prompts for ecu family, uses ONLY that port, interrogates and goes (or prompts if there's not response from the unit)

megatunix with no args, will prompt for ecu family, then auto-scan the seria lports looking for it, and SHOULD (it least it works here), properly honor serial port locks and scan all the usual ports looking for your ECU.

Thus allowing use of two mtx instances, one for jimstim and one for your ECU..

I'd like to see a fully automated stim with 6-8 DAC's that are all programmable from the tuning sw side, thus making automated regression testing possible, but that is only my wish, and I doubt I could afford it anyways...

-- David
Post Reply