Max frame rate?

[gslender]

G'day folks, just looking at the max frame rate of MS2 vs the 115,200 bps serial connection speed and where the delay is at...

So, looking at straight serial, there is a max transfer rate of 14,400 bytes/sec (at 115,200 bps).

With the payload at around 175 bytes, that would indicate a maximum frames of ~82 frames per second.

Now I'd assume the serial port needs to be sent an 'A' from the PC and then the MS2 needs to see this command (via an interupt) and then respond with writing out txtbuf to the serial port... so this has some lag in response.

What I'm puzzled about is why does the frame rate reach nothing like 80 frames/second? It seems hard to reach even 20 which is 4x less than the serial port bandwidth... so why have the port at 115,200 bps ???

Would it not be more reliable to have a serial connection at 57,600 and if not, why not?

G

[Reverant]

Maybe because you don't want to calll realtime() 80 times per second?

[jsmcortina]

See scope shot:

MS2/Extra serial comms

100_3113b.JPG (45.82 KiB) Viewed 965 times

The "high" baud rate is useful for fetching and sending configuration data.

James

[LT401Vette]

What I'm puzzled about is why does the frame rate reach nothing like 80 frames/second? It seems hard to reach even 20 which is 4x less than the serial port bandwidth... so why have the port at 115,200 bps ???

What firmware are you using?
What USB to serial chip?
What version TunerStudio?

With the current beta TunerStudio, MS2E 3.3b and an FTDI chip USB to serial on Windows 7
I am getting ~52 reads per second. So that isn't a surprising loss.

With the FTDI chip, check the Advanced settings, make sure you set latency to 1, by default it is 16. That has a pretty good performance effect.

[mariob]

Hi,

the 3.1.1 Firmware with a payload of 169 bytes was able to supply around 67 frames/second which comes quite near to your 80 frames/s. This was achieved with an AVR logging to an SD-Card.

I have never seen more than >25 frames on a PC but it is nice to hear, that 52 are possible.

Best Regards, Mario

[gslender]

I wonder then if all those calls to "realtime()" are really effective and not just chewing up CPU time in the mainloop when perhaps a single realtime() at the end of the loop would achieve the same results and actually allow the main loop to run a little quicker?

My thinking is that the serial functions aren't actually occurring (for a MS2 using ~60 frame/second) any quicker than the total time it takes to step through the entire main loop - I mean it is only able to grab data from the outpc variables every 16 milliseconds and yet the main loop seems to execute in sub milliseconds... so it is unclear why all the realtime calls???

G

[gslender]

What firmware are you using?
What USB to serial chip?
What version TunerStudio?

With the current beta TunerStudio, MS2E 3.3b and an FTDI chip USB to serial on Windows 7
I am getting ~52 reads per second. So that isn't a surprising loss.

With the FTDI chip, check the Advanced settings, make sure you set latency to 1, by default it is 16. That has a pretty good performance effect.

I'm using the latest 3.3b firmware and unsure on the seria/usb chipset - I bought the cable that DIY are selling as being compatible (is it?). I'll check the latency settings and change it if not correct.

G

[robs]

I wonder then if all those calls to "realtime()" are really effective and not just chewing up CPU time in the mainloop when perhaps a single realtime() at the end of the loop would achieve the same results and actually allow the main loop to run a little quicker?

My thinking is that the serial functions aren't actually occurring (for a MS2 using ~60 frame/second) any quicker than the total time it takes to step through the entire main loop - I mean it is only able to grab data from the outpc variables every 16 milliseconds and yet the main loop seems to execute in sub milliseconds... so it is unclear why all the realtime calls???

G

Hmmm. Interesting. Last time I looked at realtime() (unless my memory's playing tricks on me again) it was sending bytes one at a time without using the Tx interrupt. So it would need to be called every 0.086ms (86µs) in order to keep the SCI unit busy at 115,200 bps, hence the scattering of calls to realtime() through the mainline. But looking now at recent versions, SCI0.TIE gets set, i.e. the transfer is being done by interrupt, so there is no longer any need for that part of realtime() to be called repeatedly. I haven't looked into what ck_log_clr(), chk_crc(), cp_page() at the top of realtime() do. Perhaps they still need to be called frequently. In that case, for a very minor saving, I suppose the lower part of realtime() could be pulled into a separate function and called, as you say, at just one place in the mainline.

I seem to remember that the avoidance of a SCI Tx interrupt was to avoid jitter in the more important things (sparks and squirts).

Have fun,

Rob.

[jsmcortina]

Robs is spot on with the historical reasoning there. But if you look at the scope trace, the big hit on frame rate is the 5ms when the firmware is waiting for a command. The processing and sending are quite close to max efficiency.

James

[gslender]

Robs is spot on with the historical reasoning there. But if you look at the scope trace, the big hit on frame rate is the 5ms when the firmware is waiting for a command. The processing and sending are quite close to max efficiency.

James

Sure, but it would seem the numerous realtime() calls are chewing up CPU time with zero benefit yeah? I mean it is just slowing down the mainloop and not much else... or am I missing something?

g

[jsmcortina]

Yes, but all of those calls are probably a smaller cost than a single 32bit divide.

James

[gslender]

Yes, but all of those calls are probably a smaller cost than a single 32bit divide.

James

Mmmm, so your saying that many times of calling realtime() doesn't cost much mainly because rtsci isn't #1 and drops straight through to the bottom at skip_rt and the benefit is that when the serial port is ready, it is filled with the most recent/ready information from the ecu at that time?

Is that why all the "realtime()" calls are there ?? to ensure it is realtime...

G

[jsmcortina]

Is that why all the "realtime()" calls are there ?? to ensure it is realtime...

With the change to interrupt driven sending, we likely could remove a few. However, I'd expect the change in mainloop time to be barely measurable.

James

[gslender]

With the change to interrupt driven sending, we likely could remove a few. However, I'd expect the change in mainloop time to be barely measurable.

Removed all but one (1) realtime() call out of the mainloop. Went for a drive and found the logging behaviour to be as consistent as before. Probably need to do some more before/after testing but given how quick the mainloop cycles, I doubt having just one realtime() will impact the overall "realtime-ness or freshness" of the data being sent to the serial buffer.

Obviously I also need to confirm what the change has produced in terms of benefits, but from a clean code perspective, it would have benefits by keeping the number of bytes used down and reduce clutter etc, I know it is only small amounts, but every byte can impact and needless calls that don't add value surely should be removed - certainly didn't have an ill effects and can't see how it could either.

There is also some calls in the realtime() that I need to better understand - like cp_page() that only really runs if flagbyte6 & FLAGBYTE6_PAGECOPY is set, yet nowhere I could find in the code that actually sets that bit to be on, so from what I can quickly find, nothing would result in that code running, yet it takes up ram space???

G

[gslender]

There is also some calls in the realtime() that I need to better understand - like cp_page() that only really runs if flagbyte6 & FLAGBYTE6_PAGECOPY is set, yet nowhere I could find in the code that actually sets that bit to be on, so from what I can quickly find, nothing would result in that code running, yet it takes up ram space???

Well, removed (commented out) the entire cp_page() function and no ill effect (at least with my limited testing). I guess it was a redundant bit of code?

G

[racingmini_mtl]

Look in isr_sci.s and you'll see that it should be ok to remove it.

Jean

[gslender]

Look in isr_sci.s and you'll see that it should be ok to remove it.

Jean

Sweet. Well that's a few more bytes of space and a small improvement in the main loop time.

[piledriver]

FWIW I'm getting 49-52 fps with my old zombie killer Itronix Gobook3/PentiumM @1.8 Ghz, 16550a (real) serial port under Linux 2.6.38.
I get ~10-11 fps with a Class1 BT connection to an HTC Hero running Cyanogenmod 7 (Honeycomb)/Shadowlogger , will check with my Microconnectors dual USB setup tomorrow and also using XP, and BT>TS under Linux and XP.

[gslender]

Where do you measure frame rate in TS.... I've drawn a blank?

G

[racingmini_mtl]

I don't know if there is a better way now but I count the number of frames in the same second in a log file. Make sure you set the communications to the fastest data rate.

Jean