NBC speed
-
- Posts: 1818
- Joined: 02 Oct 2010, 02:19
- Location: Michigan USA
- Contact:
Re: NBC speed
Well, it's not so much the higher resolution that I was interested in, but more being able to time stuff with the number of OPCodes. Instead of checking the time, it would automatically know the time.
Matt
http://mattallen37.wordpress.com/
I'm all for gun control... that's why I use both hands when shooting
http://mattallen37.wordpress.com/
I'm all for gun control... that's why I use both hands when shooting
Re: NBC speed
Nope, I can confirm this new "not-busy-waiting" behavior for the standard firmware 1.28, too. I mean, I don't know how the firmware handles this thing internally, but the effect of using Wait() is that other tasks get more CPU. Having two tasks, with both a busy loop, and one task's loop just a "Wait(100)" in it, will give the other task nearly 100% CPU time. In the old 1.0x firmware, this would've been split to 50% : 50%.ronmcrae wrote:linusa wrote:I think it is accurate to say that NXC only frees up the CPU during a wait if you are targetting the V1.28 (or higher) ENHANCED FIRMWARE. If NXC code is compiled for, and loaded onto, the standard firmware then I believe that you still get the busy wait.
I'm not sure whether this change in behavior was caused by a compiler change in NXC/NBC, but for me, it was coincidental with the new 1.2x firmware. And also, I think I could reproduce it for 1.0x and 1.2x with the same NBC version...
RWTH - Mindstorms NXT Toolbox for MATLAB
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
Re: NBC speed
...mattallen37 wrote:Instead of checking the time, it would automatically know the time.
Commit to LEGO Mindstorms Robotics Stack Exchange:
bit.ly/MindstormsSE
Commit to LEGO Stack Exchange: bit.ly/Area51LEGOcommit
Re: NBC speed
As far as I remember, there is no timing with a higher resolution than the millisecond precision of the firmware. However, you can use statistics to get sub-ms precision. You know when the firmware "ticks", i.e. when the "user-space" program gets interrupted to do processing of internals (like updating sensors, handling Bluetooth, etc.). You can gather data about multiple runs, and look at the frequencies of the firmware "ticks". I tried to do this with my NXC profiler, but I played around with it and can't remember how exactly I settled and what other possibilities there were. If you have a look here http://www.mindstorms.rwth-aachen.de/tr ... XCProfiler at the second example, last section, where it says "PROFILER_BEGINSECTION(5);". There you can see "> 1.0 ms (in 27%)" and "< 1.0 ms (in 72%)". Which means, the 1ms-tick (i.e. the change from one ms to the next) occured in 27% of the times this code block ran. This would suggest the code block took 270µs on average (or I messed up my statistics just now).
If you go a level deeper (firmware), there was/is this "task priority" setting. I remember Dick Swan and John Hansen having discussions about performance comparision between NXC and RobotC (don't want to bring up that topic again, btw.). Somewhere, I believe on Lugnet, there was also a thread about task priority and the number of opcodes being executed within 1ms. (Maybe this wasn't even related to the aforementioned discussion). I think, it said something like 20 opcodes per ms, but that number seems too low to me (especially when I think back to my NXC performance benchmarks). Anyway, I you dig out that articles, let me know...
If you go a level deeper (firmware), there was/is this "task priority" setting. I remember Dick Swan and John Hansen having discussions about performance comparision between NXC and RobotC (don't want to bring up that topic again, btw.). Somewhere, I believe on Lugnet, there was also a thread about task priority and the number of opcodes being executed within 1ms. (Maybe this wasn't even related to the aforementioned discussion). I think, it said something like 20 opcodes per ms, but that number seems too low to me (especially when I think back to my NXC performance benchmarks). Anyway, I you dig out that articles, let me know...
RWTH - Mindstorms NXT Toolbox for MATLAB
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
Re: NBC speed
Found it myself, here: "NXT-G/ROBOTC Firmware Scheduler and Clump Priority" http://news.lugnet.com/robotics/nxt/?n=924
RWTH - Mindstorms NXT Toolbox for MATLAB
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
state of the art in nxt remote control programming
http://www.mindstorms.rwth-aachen.de
MotorControl now also in Python, .net, and Mathematica
-
- Posts: 1818
- Joined: 02 Oct 2010, 02:19
- Location: Michigan USA
- Contact:
Re: NBC speed
Very interesting indeed. However, I think current tick should do just fine. Thanks for all that info
Matt
http://mattallen37.wordpress.com/
I'm all for gun control... that's why I use both hands when shooting
http://mattallen37.wordpress.com/
I'm all for gun control... that's why I use both hands when shooting
Who is online
Users browsing this forum: Semrush [Bot] and 2 guests