View unanswered posts | View active topics It is currently Fri Oct 31, 2014 5:28 am






Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Found a bug in RobotC 3.5 
Author Message
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Found a bug in RobotC 3.5
I am in the process of porting our FTC library to use RobotC 3.5 and found the following bug:
Code:
task main()
{
    bool fTest = true;
    writeDebugStream(fTest? "true": "false");
}


Mon Sep 10, 2012 1:29 am
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: Found a bug in RobotC 3.5
work around if you haven't tried it
Code:
bool fTest = true;
writeDebugStream("%s", fTest? "true": "false");


writeDebugStream always expects a format string;

Code:
intrinsic void writeDebugStream(const string sFormatString, ...)
                   asm(opcdDebugStreamFcns, debugStreamFormat, variableRefString(sFormatString),  varArgListOfLongs);

_________________
Mike aka Spiked3
http://www.spiked3.com


Mon Sep 10, 2012 2:36 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
Code:
intrinsic void writeDebugStream(const char *pzFormatString, ...)

A format string is still a string even though there is no substitution parameters in it. In true ANSI-C, this is acceptable. Besides, this code was working in the previous RobotC version.


Mon Sep 10, 2012 3:41 am
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: Found a bug in RobotC 3.5
yeah, but even though they say 'ansi-C' I don't think anyone really expected it. I hope they never do go pure ansi-c. I'd hate to lose the C++ features they snuck in.

_________________
Mike aka Spiked3
http://www.spiked3.com


Mon Sep 10, 2012 4:21 am
Profile
Site Admin
Site Admin

Joined: Thu May 24, 2012 12:15 pm
Posts: 597
Post Re: Found a bug in RobotC 3.5
I'll make a note of this one, thank you both very much.

_________________
Check out our Blog! And our Facebook page!
Need help? Take a look at our Wiki and our Forums.

I just met you,
And this is crazy,
But here's my code now,
So fix it, maybe?
~ Carly Rae Jepsen parody


Mon Sep 10, 2012 9:09 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
Spiked3 wrote:
yeah, but even though they say 'ansi-C' I don't think anyone really expected it. I hope they never do go pure ansi-c. I'd hate to lose the C++ features they snuck in.

I wouldn't want to give up the C++ extension either but there is a difference. In general (i.e. not in this particular case), having extensions compliant to standard C++ is fine but having an existing C feature that is not compliant to ANSI syntax may not be a good idea especially for beginners because they will learn it wrong. When I teach our students RobotC, I always mention the departure of RobotC to ANSI-C so that they understand what to expect when using standard ANSI-C out there in the future. So explaining to them a certain features are C++ extension is not a problem since they will probably learn C++ too. But explaining a certain syntax that is non ANSI compliant is something I want to avoid.

PS. I wouldn't mind if they go full bloom C++ either. That will make our library one and the same for both FTC and FRC :)


Mon Sep 10, 2012 1:23 pm
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: Found a bug in RobotC 3.5
true, and agree.

writeDebugStream is not in ansi-c. I think the hope that robotC remain backward compatible is more of a justification. But with changes as major as new pointers, and a very easy work around, I can see how this could receive a low priority, maybe even be in a 'dropped' category, although john indicated they would look at it.

There are many elements missing from ansi-c, so I didn't take the statement 'ansi-c' literary, more of a marketing spin of 'more ansi-c like'. I think that's fair, no?

_________________
Mike aka Spiked3
http://www.spiked3.com


Mon Sep 10, 2012 2:24 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Found a bug in RobotC 3.5
If we REALLY wanted to be 100% ANSI-C, I guess we should get rid of the "bool" type since that wasn't in original C...

Anyways, we've actually fixed this issue. We're striving for ANSI-C is the goal, so if you find other things like this, we'll be happy to take a look and address it if at all possible.

We feel that the 3.5 update isn't 100% ANSI-C, but it's the direction we're headed and we feel we're making good progress.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Mon Sep 10, 2012 2:28 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
tfriez wrote:
If we REALLY wanted to be 100% ANSI-C, I guess we should get rid of the "bool" type since that wasn't in original C...

Anyways, we've actually fixed this issue. We're striving for ANSI-C is the goal, so if you find other things like this, we'll be happy to take a look and address it if at all possible.

We feel that the 3.5 update isn't 100% ANSI-C, but it's the direction we're headed and we feel we're making good progress.

Fair enough. We really appreciate you guys put in the effort of making it as ANSI-C compliant as possible. It would really help the kids to learn the language. Can't wait to see how it goes when I try passing function pointers to a function :)


Mon Sep 10, 2012 2:35 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Found a bug in RobotC 3.5
MHTS wrote:
Can't wait to see how it goes when I try passing function pointers to a function :)


Yeah... that one feature might still be a while away.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Mon Sep 10, 2012 3:29 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
tfriez wrote:
MHTS wrote:
Can't wait to see how it goes when I try passing function pointers to a function :)


Yeah... that one feature might still be a while away.

Oh, are you saying function pointer is still not supported in RobotC 3.50? Hmm, that means I can't do event notification callbacks! It also means I can't do a true task manager that allows multi-task registration. Please confirm so I won't start porting the code in that direction only to find it not supported.

Thanks.


Mon Sep 10, 2012 3:32 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
I tried compiling my old robot code using the FTC library with RobotC v3.50 tonight. It seems my library is totally broken :(
The brick is hung during initialization. The first time I started RobotC v3.50 that automatically loads the last project, it always crash the first time, but then when started it again, it will say detected RobotC not properly shutdown and will recover, then it started fine. It looks like it will be long nights in the coming weeks.


Tue Sep 11, 2012 5:02 am
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Found a bug in RobotC 3.5
MHTS wrote:
Oh, are you saying function pointer is still not supported in RobotC 3.50? Hmm, that means I can't do event notification callbacks! It also means I can't do a true task manager that allows multi-task registration. Please confirm so I won't start porting the code in that direction only to find it not supported.


There is no way to have a pointer to a function with ROBOTC 3.50 - Nor is one currently planned.

The external explanation might be something like “This is a problem with all systems that use a Harvard architecture where programs are stored in a separate memory space than RAM.” NOTE; both Microchip PIC and Atmel AVR are Harvard architectures and have language extensions to support “pointers” to flash memory space.

The real reason is that it’s a lot of work and won’t make it into this release pool (3.5x). A lot of work means the current symbol type has many sub-classes of symbol type entries – variables, typedef, … -- and pointers to procedures is not something that it can handle easily. Yet.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Tue Sep 11, 2012 1:17 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Found a bug in RobotC 3.5
MHTS wrote:
I tried compiling my old robot code using the FTC library with RobotC v3.50 tonight. It seems my library is totally broken :(
The brick is hung during initialization. The first time I started RobotC v3.50 that automatically loads the last project, it always crash the first time, but then when started it again, it will say detected RobotC not properly shutdown and will recover, then it started fine. It looks like it will be long nights in the coming weeks.


If you can isolate the issue, we can look into why it is locking up the brick.

As for the registry toggles, you could go into regedit and take out the following key:
HKEY_CURRENT_USER\Software\Robotics Academy

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Tue Sep 11, 2012 1:22 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Found a bug in RobotC 3.5
tfriez wrote:
There is no way to have a pointer to a function with ROBOTC 3.50 - Nor is one currently planned.

When 3.50 came out, I was planning to fix 3 things in the FTC library:
1. Currently, all event callbacks are hard coded function calls in various object modules. So even if the caller of the module does not need event callbacks, it still have to provide a stub callback function doing nothing. With function pointer support, I thought I could pass the callback function pointer to the object's initialization function so that if the function pointer is NULL, then there is no callback. If there is, then it will do an indirect function call through the function pointer when the event occurs.
2. Currently, for all object modules in the library that require periodic callback (e.g. the gyro module needs periodic callback to do the integration for the robot heading), the module must provide a "xxxTask" function and the caller of the object module is required to call this xxxTask function in its main loop. If the caller forgot to do this, the gyro wouldn't integrate, for example. It's a subtle mistake that trips the students. With function pointer support, I could have a TaskManager providing a "task registration" API. The object module that requires periodic callback will register the callback function as a periodic task during its initialization. The main task template will have a single call to the task manager dispatcher in the main robot loop. The dispatcher will sequentially call each registered task. This will free the students from having to remember which object module has a periodic task and must be called in the main robot loop.
3. Currently, if an object is embedded within another object (e.g. the PIDDrive object contains two PID controller objects), there is no way to pass the pointers of the two PID controller objects to the PIDDrive object. So a global array of PID controller objects are created and the indexes to the array are passed to the PIDDrive object instead. With pointer support, this ugliness will go away.

So on the bright side, since function pointer is not supported, I can't do 1 and 2 so it is much less work now.


Last edited by MHTS on Tue Sep 11, 2012 2:19 pm, edited 2 times in total.



Tue Sep 11, 2012 1:50 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 18 posts ]  Go to page 1, 2  Next

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.