View unanswered posts | View active topics It is currently Mon Jan 25, 2021 10:41 am



Reply to topic  [ 56 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
2.x JimStim Support Request 
Author Message
LQFP112 - Up with the play

Joined: Sun Apr 06, 2008 6:30 pm
Posts: 100
Fred wrote:
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...

_________________
-- David
http://www.megatunix.com
http://megatunix.sourceforge.net


Tue Nov 16, 2010 7:31 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15376
Location: Home sweet home!
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.

_________________
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!


Tue Nov 16, 2010 7:50 pm
Profile WWW
LQFP112 - Up with the play

Joined: Sun Apr 06, 2008 6:30 pm
Posts: 100
Fred wrote:
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.

_________________
-- David
http://www.megatunix.com
http://megatunix.sourceforge.net


Tue Nov 16, 2010 7:54 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15376
Location: Home sweet home!
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.

_________________
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!


Tue Nov 16, 2010 8:01 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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.


Tue Nov 16, 2010 8:19 pm
Profile WWW
LQFP112 - Up with the play

Joined: Sun Apr 06, 2008 6:30 pm
Posts: 100
jbelanger wrote:
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)

_________________
-- David
http://www.megatunix.com
http://megatunix.sourceforge.net


Tue Nov 16, 2010 10:32 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15376
Location: Home sweet home!
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.

_________________
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!


Tue Nov 16, 2010 11:19 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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


Wed Nov 17, 2010 1:36 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15376
Location: Home sweet home!
Perfect :-)

_________________
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!


Wed Nov 17, 2010 3:46 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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


Thu Nov 18, 2010 6:18 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 56 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.