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 ???
LT401Vette wrote: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.
gslender wrote: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???
jsmcortina wrote: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.
jsmcortina wrote:Yes, but all of those calls are probably a smaller cost than a single 32bit divide.
gslender wrote:Is that why all the "realtime()" calls are there ?? to ensure it is realtime...
jsmcortina wrote: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.
gslender wrote: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???
racingmini_mtl wrote:Look in isr_sci.s and you'll see that it should be ok to remove it.
Users browsing this forum: rcr1978 and 1 guest