Thanks for that, we'll look into it. I have seen it take a long time to bring up the edit dialog so it may just be running out of time and Android nukes it. Time to get the profiler out.
MS2 is proving to be the most timing sensitive ECU, we already got bitten by the need to put a delay in the middle of the page read command for MS2Extra. MSLogger tries to keep as much as possible out of the communications thread in order to maximise the number of reads. Calculations and logging are handled elsewhere whilst we wait for BT to do its thing in its own time; so the gap between the end of one read and the start of the next is no more than the time to calculate how many reads per second we're doing, and we only do that about once a second. Throwing a user-selectable delay in there as a fudge factor wouldn't be tricky (if a little disappointing).
I am rather amused how the MSlogger devs have been commenting on Shadow Dash today, you're commenting on MSLogger, all we need now is Phil to post something about msDroid and the circle will be complete
Trev16v wrote:
Just one other quick thing you might want to add an inter-write delay option for MS2. I think this won't be a problem once the new MS2 software comes out with the inter-write delay requirement solved, but at the moment with my current MS2 version (2.905 or something I think), MSLogger tries to do something in the order of 15 reads per second which immediately causes my MS2 to throw the toys out of the pram. I've got an option on msDroid to allow manual or automatic selection of this; the automatic selection basically sets the inter-write delay to about 25ms IIRC because I had to stretch it out that far to get a reasonable chance of the bytes being spaced at the other end.
You might have old MS2 firmware which doesn't behave correctly. I've got it running fine at 24 rps on 3.2.4 release and zero problems. I'm not sure it makes sense to support really old firmwares with known serial issues? I can't even imagine the other engine issues associated with running an old release.
I think this is my fault for being a bit of a berk and not properly understanding the MS2 / MS2Extra development paths. I asked Bruce about this issue only a few weeks back and he said that it will be fixed in the B&G MS2 2.910 to be released shortly. But what he's talking about there is the base MS2 code, and presumably then the MS2-Extra code which I guess was forked off at a certain point has already long had the issue resolved. Is that pretty much right? I confess I am not sure if or how many people would actually be using the base MS2 code, hence the attempts to try to account for everything.
Trev16v wrote:But what he's talking about there is the base MS2 code, and presumably then the MS2-Extra code which I guess was forked off at a certain point has already long had the issue resolved.
MS2/Extra was forked from the MS2/BG code in around 2006 and has long been the dominant code (6:1 ratio.)
Thanks James. Confirms that there are at least some people out there then who will be using MS2 with the serial susceptibility. But, to be honest, I'd guess anyone advanced enough to want to use various mobile applications would be the sort to be running MS2/Extra firmware.
piledriver wrote:Any possibility of getting std serial support as an alternate to BT ?
(via /dev/ttyUSB0 etc? not OTG etc, real rs232)
Running Android-x86 4.2.2 on a Thinkpad.
BT is borken (work in progress due to large changes in BT stack) but std USB <>serial is well supported.
Like Trev said in the other thread, Dave and I are now working on MSDroid. FTDI USB chip support was juuuuuust added in this release of MSDroid and Prolific is coming very soon. So, do you have an FTDI based usb to serial cable you can try ? Or an MS3
1993 Chevrolet Cavalier Z24
3400 Turbocharged Inter-cooled
MS3 v3.57+MS3X
Have ms3 running the latest pre-1.3 alpha1, hopefully the bleeding edge fw won't be an issue..
I also have a mos7840 dual unit that is supported by my current Android Linux kernel, all the modules are present and load/create std devices.
Should I be loading the modules on boot to create the std linux serial /dev/ttyUSBx devices or is it all reimplemented in userspace?
Always doing things the hard way, MS2 sequential w/ v1.01 mainboard, LS2 coils. 80 mile/day commuter status.
piledriver wrote:Have ms3 running the latest pre-1.3 alpha1, hopefully the bleeding edge fw won't be an issue..
I also have a mos7840 dual unit that is supported by my current Android Linux kernel, all the modules are present and load/create std devices.
Should I be loading the modules on boot to create the std linux serial /dev/ttyUSBx devices or is it all reimplemented in userspace?
I'm using pre1.3 alpha 1 to test so it should be fine
I would assume you need to load the modules on boot but this is a pretty specific application so I'm not sure, you will have to try, and share your experience afterward I would love to see pictures of MSDroid on a big screen TV!
1993 Chevrolet Cavalier Z24
3400 Turbocharged Inter-cooled
MS3 v3.57+MS3X
