View unanswered posts | View active topics It is currently Wed Nov 26, 2014 3:40 am






Reply to topic  [ 11 posts ] 
new firmware for NXC 
Author Message
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post new firmware for NXC
hi,
as I read in a German forum, there is a new release of NXC firmware that supports many features as in RobotC, e.g. trigonometric functions:
Quote:
Es gibt für NBC/NXC eine neue enhanced Firmware. Viele Funktionen der neuen Version 1.06a wurden noch nicht in NXC umgesetzt,
aber das Kopieren von Arrays funktioniert beispielsweise bereits viel schneller als mit der standard Firmware.

Zeitvergleich, Arrays kopieren (siehe "Quellen", 1. Link):
Standard Firmware: 22.5 s
Firmware 1.06a: 7.4 s

NEU:

1) Funktionen für Arrays, bereits anwendbar unter NBC:
OPARR_SUM, OPARR_MEAN, OPARR_SUMSQR, OPARR_STD, OPARR_MIN, OPARR_MAX, and OPARR_SORT OPARR_SORT

in NXC momentan nur über den asm Befehl verfügbar:
#define ArrayOp(_cmd, _out, _asrc, _idx, _len) asm { arrop _cmd, _out, _asrc, _idx, _len }

2) Folgende Funktionen wurden in die neue Firmware integriert:
(=> viel kürzere Laufzeiten als bisher.)
acos, asin, atan, cos, sin, tan, cosh, sinh, tanh, log, log10, exp, pow, ceil, floor, sqrt, atan2, fmod und fabs

3) In der endgültigen Firmware Version 1.06 wird die Motor Regelung evtl. mit derselben Präzision wie in RobotC arbeiten.
(Der Benutzer kann die Refresh Rate des PID Reglers selbst bestimmen. Die Umsetzbarkeit wird gerade geprüft.)

Quellen:
http://nxtasy.org/2008/01/12/pre-releas ... -firmware/

Zu 3): Bitte um neue Funktion per Email

Enhanced Firmware 1.06a:
http://bricxcc.sourceforge.net/lms_arm_jch.zip

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Sun Mar 16, 2008 5:52 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
Do not be confused by looking at the one line feature description. There is no other current firmware for the NXT that has the performance and breadth of functionality of the ROBOTC firmware.

An analogy is someone trying to make the argument that a Volkswagen and a Ferrari have the same functionality because they are both cars.

For the specific trig functions example:

ROBOTC supports floating point variables. NXC does not.

ROBOTC trig functions use native floating point precision, i.e. six decimal points. NXC has much less accuracy using a "fixed" precision integer format with three (I think) fractional digits; i.e. a integer value of 1305 really means 1.305.

ROBOTC uses native floating point library routines to calculate trig functions, i.e. fast real time calculcations. NXC uses slow NXT-G virtual machine interpreted instructions for the calculation, i.e. slow real time.

ROBOTC is C language which seamlessly converts between "int", "long" and "float" variable types. NXC uses "fixed precession arithmetic calculations" which requires end user programming to manage conversion to / from the "fixed precision fractional" numbers.


Sun Mar 16, 2008 3:51 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
yes Dick, surely you are right.
But featuring transcendent functions with fixed point vars comes quite close to RobotC, even if the accuracy is not quite as good.
I just wanted to point out what the competition is like...

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Mon Mar 17, 2008 4:51 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
Ford Prefect wrote:
yes Dick, surely you are right.
But featuring transcendent functions with fixed point vars comes quite close to RobotC, even if the accuracy is not quite as good.
I just wanted to point out what the competition is like...

It all depends on the end user application.

ROBOTC does sin, cos calculations in tens of microseconds. A subroutine written in VM instructions takes milliseconds (I believe) with less accuracy. Most dead reckoning calculations are likely to do several (four or more) trig calculations per iteration. The cumulative time can really add up.

I'll give you another example. ROBOTC firmware has a background task that continuously polls the sonar sensor; when user program wants to access the sonar sensor it simply retrieves the latest polled value which takes about 3 microseconds. Solutions based on the NXT-G firmware (i.e. NXC) instead do an inline poll of the ultrasonci sensor which takes 4-milliseconds. Simple programs may not need the performance difference. Large programs, like you write, will appreciate the difference.

Here's another example to try. Create a 100 x 100 and measure the time to fill each value with the multiplication of (row index) * (column index). I haven't measured it but am convinced there will be dramatic performance differences in ROBOTC's favor.


Mon Mar 17, 2008 5:51 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
Dick Swan wrote:
I'll give you another example. ROBOTC firmware has a background task that continuously polls the sonar sensor; when user program wants to access the sonar sensor it simply retrieves the latest polled value which takes about 3 microseconds.


Maybe, if you didn't have these background tasks, RobotC could even be quite faster.
The polling of the sonar sensor also is not needed at this speed in every case.
if I should have the program code
Code:

SetSensor(S1, SensorSonar); // or sth. like this
 int i;

while true
{
   i=SensorValue(S1);
   // do sth else
   wait1Msec(50);
}


It is not necessary at all to call and get the sensor value every 3 msec - I just need it only every 50 msec, just in EXACTLY THAT moment, the loop calls the value !

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Mar 18, 2008 5:40 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
ROBOTC is already the fastest / highest performance solution for the NXT by a factor or 5 to 100. Proven by independent benchmarks; see for example http://www.teamhassenplug.org/NXT/NXTSoftware.html. and look for the row "Speed (loops/min)". Consequently, there is limited energy on improving the current execution speed vs other nifty features.


Tue Mar 18, 2008 12:54 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
yes, I believe RobotC is the fastest - I never doubted this 8)

but: is there any need to poll any sensors every 3 milliseconds, if the value is requested only every 50 or 100 or 1000000 msec ?

I mean: this is a waste of cpu time, isn't it? :shock:

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Mar 18, 2008 1:10 pm
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
Ford Prefect wrote:
but: is there any need to poll any sensors every 3 milliseconds, if the value is requested only every 50 or 100 or 1000000 msec

I never stated sensors were polled every 3 milliseconds. Reread my post.


Last edited by Dick Swan on Tue Mar 18, 2008 5:59 pm, edited 1 time in total.



Tue Mar 18, 2008 3:57 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
hi,
sorry, with the 3 msec was my fault.
I meant just this:
Quote:
ROBOTC firmware has a background task that continuously polls the sonar sensor

So it was just the background task that I meant, and which uses cpu time even if one doesn't need the sonar sensor value.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Mar 18, 2008 5:01 pm
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post 
Anywhere from 10 to 20% of the NXT CPU time is spent on background tasks. There's a built-in variable that gives you this value. But you can simply find it out by opening the debugger "System Parameters" window and it's one of the items that are displayed.

We've been having a dialog in other posts in this forum about the differences between ROBOTC and other programming environments. AFAIK no other programming system for the NXT continuously measures the background CPU level, let alone gives you such an easy way to monitor it. This is just one of the dozens of subtle differentiations between ROBOTC and the "other solutions".

Back to the ultrasonic sensor. The background polling is only enabled if a ultrasonic sensor is configured for the NXT. I'm quite sure the overhead of the polling is under 1% of the total CPU.

The main value of the background polling is that your program execution is not stalled for 4 milliseconds or so to read the ultrasonic sensor. ROBOTC has been optimized for speed of user program execution.

As long as your program is interrogating the sonar sensor at least once every 400 milliseconds it's better to have the background polling task rather than performing an inline poll transaction.

There's another subtle ultrasound sensor issue to be wary about. If you poll the sensor more that once every 20 millisecond or so, the returned results are corrupt / invalid. The ROBOTC background task manages this. Many alternative solutions do not but they don't encounter the problem because they're slow enought that user programs don't encounter this problem.


Tue Mar 18, 2008 6:18 pm
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
hi,
thx for this detailed explanation.
In fact, 1% of cpu time is really not much, and on the other hand the risk of getting invalid values is serious.

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Tue Mar 18, 2008 6:29 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


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 © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.