2.x JimStim Support Request

[dandruczyk]

At the risk of having my head removed, how hard would it be to reconfigure the serial port to a different speed and rewrite the config (which seems to get overwritten anyway, i made some by-hand changes and they got nuked!! :-p)? It seems like you could just pass a message to whatever handles that and have it quickly re-init and carry on. Maybe something structural in mtx means thats not possible, but...

As for reflash, no. I believe that A (from above post) it's a different clock rate B you need a bdm C the code/binary isn't available anyway. I asked James the same question several days ago.

Thanks for the explanation and fixes. I'll try them out soon

Fred.

It sounds nice and easy, but it can get messy. Mtx uses a parallel config file system, one "static" set system wide and a shadow one in ~/.MegaTunix, which is unpopulated by default allowing the user to override system wide files or add their own custom ones. I could put in yet another hacky special handler for that control to do what you want, but I don't want to. I think that control being user changeable in SW is a bad idea. (thats something that should be HARDWARE changeable (jumper, dipswitch, etc), not software.

It IS doable, but its hacky and can lead to future issues (which config file again?). it would be the simplest and most elegant if the baud rate was fixed at 9600 with no chance of changing it...

[Fred]

Fair enough. Some bad news, for you, though. I'll be exposing the serial speed in FreeEMS through a control, too. In a more raw way, though, and definitely buried in an advanced tab because it's already the right speed, it will just be for people with issues to tweak to match the clock of their device.

[dandruczyk]

Fair enough. Some bad news, for you, though. I'll be exposing the serial speed in FreeEMS through a control, too. In a more raw way, though, and definitely buried in an advanced tab because it's already the right speed, it will just be for people with issues to tweak to match the clock of their device.

WHY!!?? What's the point? "issues to tweak to match the clock of their device" doesn't make much sense? That causes a chicken and egg problem. Let's say user "super-fred"
flips his baud to somethign else, then tunes happily away, sells the car someone else trys to connect and tune and finds they can't either talk to it or they just get garbage back from the uinit... Bound to happen in more creative ways than that too..

Allowing the user to change the baud in software is a BAD DESIGN decision in my opinion.

[Fred]

The point is, that you can not get an exact clock rate from most of these chips. You can only get close. Same goes for most serial adapters, they are only close. If close and close are in the same direction, you're fine. If one close is low and the other close is high, you get framing errors. I'll put it in for the purposes of choosing which exact close (high or low) the user wants based on their dodgy serial adapter. It can be in advanced tab, hidden, greyed out, "are you sure you wanna"ed, etc. Hell, I don't care if you don't support it, and hide it all together, but it'll be there in the config, probably, and for the above reason. If some numb nuts wants to change it to something weird, that'll be his problem. We're OT now. I can see perfectly why it was done on the JimStim, though. Limited IO, limited resources, balance comms with core functionality, etc. It makes sense. There is no need to support it. Just allow it to be changed and then the user needs to close mtx, reconfigure and reopen. No big deal.

[jbelanger]

Dave,

I agree that having the baud rate in the GUI could cause issues and that in most cases faster won't be better. But there might be specific cases where faster would be better and the side effects of the higher baud rate might be of less importance. This is why it has been put there but I don't see a problem in not having it available in MTX for the reasons mentioned.

In this case, losing 1 or more input pins for changing the baud rate would be a much worse idea than having it in software because all the pins are used for other uses and this is a minor feature (in that the target audience is very small percentage of JimStim users). But even if there is no support for changing it within the GUI, I find it a bit strange that the baud rate would be hardcoded within MegaTunix.

And no the firmware can't be updated using the serial port since there is no bootloader. All the memory is used for the primary use and also the code is protected from accidental modifications (much like the bootloader code would be). You'd need a BDM but in any case the code has not been made available.

Jean

EDIT: I started my answer a few hours ago so I'm a bit off sequence with my post but still valid.

[dandruczyk]

Dave,

I agree that having the baud rate in the GUI could cause issues and that in most cases faster won't be better. But there might be specific cases where faster would be better and the side effects of the higher baud rate might be of less importance. This is why it has been put there but I don't see a problem in not having it available in MTX for the reasons mentioned.

In this case, losing 1 or more input pins for changing the baud rate would be a much worse idea than having it in software because all the pins are used for other uses and this is a minor feature (in that the target audience is very small percentage of JimStim users). But even if there is no support for changing it within the GUI, I find it a bit strange that the baud rate would be hardcoded within MegaTunix.

And no the firmware can't be updated using the serial port since there is no bootloader. All the memory is used for the primary use and also the code is protected from accidental modifications (much like the bootloader code would be). You'd need a BDM but in any case the code has not been made available.

Jean

EDIT: I started my answer a few hours ago so I'm a bit off sequence with my post but still valid.

The baud rate for any ecu setup is currently not set in the gui, mainly because I really don't want to give user enough rope to hang themselves, nor do I think it's a good idea to allow that setting to be changed, since once its changed, we're in an indeterminate state, i.e. which baud rate is it actually talking at, did it change right now, howabout after a burn, or only after power cycle? I donno, the user doesn't know and neither does the tuning SW, which is a potential for data loss and/or corruption. Probably not much of a concern on the jimstim, but with reports of MS2's randomly erasing their firmware due to suspected serial corruption issues, I don't want to give the user the flexibility of shooting themselves in the foot THAT easily. Baud per ecu family is currently defined in a personality specific configuration file (Interrogator/Profiles/<family>/details.cfg)

[Fred]

Are you OK with leaving it in the gui, ignoring the fact that some idiots might hang themselves and thus allowing me to adjust it, restart mtx and do testing at a higher and smoother rate of change? I'd like it to stay there even if when you set it, mtx goes offline instantly or something.

How does it work, anyway, is it on reset of the device? Is it immediate? Does it need to be burned to stick? If we have the way it works clearly defined and in a text box near the control or in a tooltip or something, then it's fine, right? It's not like your average JimStim user is even going to hook up a PC to this thing. I think you can safely assume a minimum intelligence level that is fairly high ;-)

Fred.

[jbelanger]

Serial port speed is set at startup and never again. So you need to change the setting, burn it and do a power cycle.

Jean

[Fred]

Perfect :-)

[jbelanger]

I've loaded the latest MTX version on Windows and it went well. Quick install and JimStim detected fine. Static RPM setting works fine but I can't get the dynamic RPM to work. No matter what I enter, the JimStim RPM is unaffected and only the GUI goes through the sequence.

I also noticed that you can't enter a down going RPM sequence, i.e., a higher start than end.

Jean