View unanswered posts | View active topics It is currently Thu Nov 27, 2014 12:24 am






Reply to topic  [ 13 posts ] 
inline functions with RobotC 3.x 
Author Message
Rookie

Joined: Tue Feb 21, 2012 12:38 pm
Posts: 7
Location: Paris, France
Post inline functions with RobotC 3.x
Hello,

I was using RobotC 2.x since a few weeks and now, I use RobotC 3.0 with the same programs. I have now new warnings, and for most of them, I can do with it. But there are two new different warning about "inline" keyword :
*Warning*:'inline' not supported, changing to normal function call.
*Warning*:Use 'inline' to avoid possible simultaneous variable memory access conflicts for
subroutine 'function1' called from multiple tasks 'task1' and 'task2'?

The first tells me I can't use inline anymore, the second tell me I should use it. But it's only warning.

Does someone has the same problem? What if I use inline with RobotC 3.x?

Bichon, for BrickStory.

_________________
Bichon, Brickstory team for Eurobot


Tue Feb 21, 2012 12:54 pm
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
inline functions are not supported in 3.0, the warnings you are seeing are confusing. The bottom line is, you can't have two tasks accessing the same function without implementing some kind of locking mechanism.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Tue Feb 21, 2012 1:03 pm
Profile WWW
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: inline functions with RobotC 3.x
This is still painful. Just curious, is there a plan in the future to fully support local variables on the stack? This seems very fundamental.


Tue Feb 21, 2012 4:28 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
The initial choice was not made by ROBOTC, it was made by LEGO. The ROBOTC firmware has its roots in the original firmware. "Adding" support for such a feature is not merely bolting some new stuff to it, it requires a fundamental redesign.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Tue Feb 21, 2012 5:04 pm
Profile WWW
Rookie

Joined: Fri Apr 15, 2011 10:29 am
Posts: 37
Post Re: inline functions with RobotC 3.x
mightor wrote:
The initial choice was not made by ROBOTC, it was made by LEGO. The ROBOTC firmware has its roots in the original firmware. "Adding" support for such a feature is not merely bolting some new stuff to it, it requires a fundamental redesign.

- Xander


That's not completely true. *ALL* of the different virtual machines have their roots in the original firmware from LEGO, but only RobotC has the issue where there isn't a stack. I will agree that it's not trivial to just change that, but at the same time, this limitation of RobotC ends up causing more problems than it's worth. This is especially bad when I'm trying to mentor my kids on the proper way of doing things, and often more times than not we end up creating monsterous, hard-to-maintain programs due to the lack of a real stack.

Nate


Tue Feb 21, 2012 9:52 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
Neither LEGO's nor John Hansen's EFW have a stack that allows you to execute functions concurrently. I can't speak for NXOS, Lejos or nxtOSEK. I am pretty sure that apart from perhaps the bootstrapping code, those three previously mentioned firmwares have very little in common with LEGO's original firmware, if anything at all.
The ROBOTC developers have said many times before that there are no plans to change the current architecture of ROBOTC's firmware, the ROI is too small.
Most kids don't use multi-tasking and the current issues of not having re-entrant functions is admittedly a pain in the arse, but certainly not something that must necessarily end up in the creation of "monsterous, hard-to-maintain programs". It requires a rethink of some things but I can assure you that that will be a lot less effort than trying to get kids working with nxtOSEK or NXOS :) Lejos is nice but you'll have to teach the kids to use either NetBeans or Eclipse.

All programming environments, firmwares and platforms have their weak points. It's a matter of choosing the one that causes the least amount of pain in the places that matter the most to you.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Feb 22, 2012 3:33 am
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
Yeah backwards compatibility is always a pain in the horse's rear but sometimes you don't have a lot of choice.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Feb 22, 2012 9:52 am
Profile WWW
Rookie

Joined: Tue Feb 21, 2012 12:38 pm
Posts: 7
Location: Paris, France
Post Re: inline functions with RobotC 3.x
OK,

Thanx for your answers. I'll write two functions, one for each task.
But may I suggest to alert with an error and not anly a warning. It will compile but it won't work....Just say that "inline" is not declared.

Bichon, for BrickStory

_________________
Bichon, Brickstory team for Eurobot


Wed Feb 22, 2012 12:58 pm
Profile WWW
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
Can you send a mail to support@robotc.net to submit a ticket for this issue?

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Feb 22, 2012 2:04 pm
Profile WWW
Rookie

Joined: Fri Apr 15, 2011 10:29 am
Posts: 37
Post Re: inline functions with RobotC 3.x
mightor wrote:
Neither LEGO's nor John Hansen's EFW have a stack that allows you to execute functions concurrently.


So, you're saying that you can't call a functions like this in NXC (written in RobotC style off the top of my head, not compile checked).

Code:
task addTask() {
  int num1 = 0;
  while (true) {
    nxtDisplayString(0, "add=%d", add(num1, num1 -1));
    wait1Msec(50);
  }
}

task Main() {
  StartTask(addTask);

  int num2 = 0;
  while (true) {
    nxtDisplayString(0, "add=%d", add(num2, num2 -1));
    wait1Msec(33);
  }
}

int add(int num1, int num2) {
    return num1 + num2;
}


In RobotC, this will end up with corrupted additions. Without a stack, there can not be a thread safe function which has no global variables, only local variables. The above is very similar to something we attempted to do using RobotC which failed due to corrupted variables.

Most kids don't use multi-tasking and the current issues of not having re-entrant functions is admittedly a pain in the arse, but certainly not something that must necessarily end up in the creation of "monsterous, hard-to-maintain programs".

Doing anything remotely significant means the use of tasks makes things *much* *much* *much* simpler and safer. Think of projects that use gyros or anything else that needs to happen in the background while other things are going on in the foreground.

Take for example last year's robot, which had a dual gripper arms. We had an external task that ran a state machine that allowed the robot to 'grab' a platform. Yes, we could run one monsterous single-tasked program to do all of that, but by breaking the grabber functions into their own tasks, they can be written completely independently of all the other functions in the program. Plus, they don't have much if any side-effects (aside from badly written code that could potentially lock out all other tasks, but that's no different than writing a function/method in the 'single threaded' program which does the same same thing.

Unfortunately, any methods or routines that are common to them have the potential to cause unforseen corruption of data (see above). Things that you may want to share are PID functions, methods. The solution is to make *EVERYTHING* a global variable. Last time I did that was dozens of years ago in Fortran. Not something that I think we should be teaching our children of today. :(

Quote:
It requires a rethink of some things but I can assure you that that will be a lot less effort than trying to get kids working with nxtOSEK or NXOS :) Lejos is nice but you'll have to teach the kids to use either NetBeans or Eclipse.


Having used both for my Robot students [RobotC is for the First-FTC program, and NetBeans is used for the First-FRC program], the students I'm mentoring are finding NetBeans *MUCH* *MUCH* easier to understand and use vs. RobotC. Things behave as they expect, and they aren't constantly chasing weird bugs and strange behavior that is hard to track down.

In other words, they end up dealing with their own logic bugs, not bugs in the environment that appear 'sometimes'.

Quote:
All programming environments, firmwares and platforms have their weak points. It's a matter of choosing the one that causes the least amount of pain in the places that matter the most to you.


Agreed, but with the First Robotics programs, there is less opportunity to choose the platform. For FTC, it's either Labview (NXT-G on steroids), or RobotC. The latter is much less flexible than RobotC and doesn't really equate to what most software engineers are using the in the real world. The former has too many 'quirks' that must be worked around. However, given a choice (and we do have a choice), we're choosing to deal with the quirky, often-times frustrating world of RobotC, because in the end, it's more of a 'real' programming language than Labview.

However, everytime I use it I with it had a stack so I could write routines that multiple threads could call. At one point, Tim mentioned the ability to use semaphores, which *might* help make some of the routines 'thread safe', but the dearth of documentation has made it a moot point to date.


Nate


Fri Feb 24, 2012 10:32 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: inline functions with RobotC 3.x
I totally agree with you. I find it so painful that I almost do not use tasks at all. Instead, we created a Cooperative Multi-tasking library to simulate multiple tasks using a single task. This is similar to the IterativeRobot template in FRC where the main robot loop becomes the multi-tasking scheduler that calls all the tasks in sequence. There is no preemption. The only caveat is that each "task" must be well behave and non-blocking. To help alleviate the desire to block, the library provides an extensive event driven state machine support. So instead of calling Wait1Msec, there are SetTimer and WaitForEvents functions to call in the state machine. Our students learn to use this library very well. It really reduces the complexity of writing autonomous code and debugging it. To show you how simple it is, here is an excerpt of our autonomous code for this year's competition. Notice that all the calls are non-blocking, for example, PIDMotorSetTarget, ServoSetAngle and PIDDriveSetTarget are executed as separate "Coop tasks" so they are concurrent. So while the elevator is coming down, the arms are closing in and the robot is driving forward at the same time. When there is nothing else to do but wait, it calls SMWaitEvents for PIDDrive to finish, for example.
Code:
void ParkFront1(SM &sm, ALLIANCE alliance)
{
    switch (sm.currState)
    {
        case SMSTATE_STARTED:
            //
            // Move elevator to the bottom.
            // Close arms to avoid hitting things.
            // Drive forward ~5 ft.
            //
            PIDMotorSetTarget(g_Elevator, ELEVATOR_DOWN_POS, true);
            ServoSetAngle(g_LeftArm, ARM_LEFT_CLOSED);
            ServoSetAngle(g_RightArm, ARM_RIGHT_CLOSED);
            PIDDriveSetTarget(g_EncoderDrive, 62.0, 0.0, true);
            SMAddWaitEvent(sm, EVTTYPE_PIDDRIVE, -1, -1);
            SMWaitEvents(sm, sm.currState + 1, 0, SMF_CLEAR_EVENTS);
            break;

        case SMSTATE_STARTED + 1:
            //
            // Backup ~1 ft before turning to avoid hitting the crates.
            //
            PIDDriveSetTarget(g_EncoderDrive, -12.0, 0.0, true);
            SMAddWaitEvent(sm, EVTTYPE_PIDDRIVE, -1, -1);
            SMWaitEvents(sm, sm.currState + 1, 0, SMF_CLEAR_EVENTS);
            break;

        case SMSTATE_STARTED + 2:
            //
            // Turn robot to the 90-degrees so that it is facing the ball
            //
            PIDDriveSetTarget(g_EncoderDrive,
                              0.0,
                              (alliance == RedAlliance)? -90.0 : 90.0,
                              true);
            SMAddWaitEvent(sm, EVTTYPE_PIDDRIVE, -1, -1);
            SMWaitEvents(sm, sm.currState + 1, 0, SMF_CLEAR_EVENTS);
            break;

        case SMSTATE_STARTED + 3:
            //
            // Open the arms, drive towards the bowling ball.
            // Curve a little to better align to the ball.
            //
            ServoSetAngle(g_LeftArm, ARM_LEFT_OPENED);
            ServoSetAngle(g_RightArm, ARM_RIGHT_OPENED);
            PIDDriveSetTarget(g_EncoderDrive,
                              30.0,
                              (alliance == RedAlliance)? -10.0 : 10.0,
                              true);
            SMAddWaitEvent(sm, EVTTYPE_PIDDRIVE, -1, -1);
            SMWaitEvents(sm, sm.currState + 1, 0, SMF_CLEAR_EVENTS);
            break;

        case SMSTATE_STARTED + 4://Go forwards to the read parking zone
            //
            // Continue forward to the parking zone.
            // Curve a little to better align to the parking zone.
            //
            PIDDriveSetTarget(g_EncoderDrive,
                              66.0,
                              (alliance == RedAlliance)? -10.0 : 10.0,
                              true);
            SMAddWaitEvent(sm, EVTTYPE_PIDDRIVE, -1, -1);
            SMWaitEvents(sm, sm.currState + 1, 0, SMF_CLEAR_EVENTS);
            break;

        default:
            SMStop(sm);
            break;
    }
}


Fri Feb 24, 2012 11:11 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3293
Location: Rotterdam, The Netherlands
Post Re: inline functions with RobotC 3.x
Could I make a suggestion. I agree with you guys that there are a lot of things that could certainly be improved upon, some things are broken and unclear. If each of you could send me a mail with up to 5 points with issues that you have with ROBOTC and mail them to me at mightor_at_gmail_dot_youknowhat, I will be happy to pass them along to the people that should read this stuff. Most of this thread is preaching to the choir and it's not them that need to hear this :)

Mail them to me before 1 March, please, so I can collate. Don't send me long rants, I need short, to the point things:
What bugs you, why it bugs you and also why you think fixing this should be a priority. No more than 3 lines for each issue, no run on sentences to cheat either. Look at it as making a business case for these things.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Sat Feb 25, 2012 5:15 pm
Profile WWW
Rookie

Joined: Fri Apr 15, 2011 10:29 am
Posts: 37
Post Re: inline functions with RobotC 3.x
mightor wrote:
Could I make a suggestion. I agree with you guys that there are a lot of things that could certainly be improved upon, some things are broken and unclear. If each of you could send me a mail with up to 5 points with issues that you have with ROBOTC and mail them to me at mightor_at_gmail_dot_youknowhat, I will be happy to pass them along to the people that should read this stuff. Most of this thread is preaching to the choir and it's not them that need to hear this :)


Thanks Xander. I'll do my best to get them to you soon!


Nate


Sun Feb 26, 2012 11:51 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 13 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.