Does anyone have a guide on how to use Easy C user functions?
Do you want to Create a User Function, or Call a User Function???
In EasyC V2.x, Load/Start your Project, Right Click the “User Functions” item in the “Function Blocks” window.
Selecting “New Function”, lets you Type In (Create) a Function in your Current Project.
Selecting “Existing Function”, lets you Import (Copy) a Function from another Project, in to your Current Project.
To Use those Function in the main() Function, you can now Drag and Drop from the “User Functions” item to the main() Function, or any other Functions that your Create.
Spurflys,
I have a few basic suggestions about function use as it relates in general to computer programming. You haven’t included much detail in your question so I am not sure what level you’re at, but hopefully my advice won’t be entirely old news to you.
**One of the most basic rules of writing functions is that each should be short enough to fit entirely on your screen all at one time. **Note that at the top of your EasyC user interface you can adjust the text size, but obviously you won’t want to make the text so tiny that it is hard to read. If a function gets too long to fit entirely onto one screen then you should try to break it down into two or more functions, so that each of the newly broken out functions each will fit entirely onto one screen at a time. Let me give an example.
Suppose you want to write a function to make your robot move from one back corner of the Clean Sweep field to the furthest hole under the fence to push some balls under. And maybe on the way your robot needs to pick up some footballs from the centre of the field. Below is a list of behaviours which you might want to have your robot do as part of this routine:
[LIST]
*]move forward 3 feet
*]turn left 90 degrees
*]move forward 3 feet
*]scoop up 5 footballs
*]move forward 3 feet
*]turn right 90 degrees
*]move forward 3 feet[LIST]
*]eject balls under fence
[/LIST]
So you begin to write this out as one program (or one function). Once you have all the code written out you find that it runs to two and a half screens. Since we have broken the “must fit on one screen” rule, we should break this function down into 3 or 4 functions which when run in succession will accomplish the same task.
Function 1 we might call “MoveFromCornerToFootballs”; function 2 we might call “ScoopUpFootballs”; function 3 we might call "MoveToSlotUnderFence; and function 4 we might call “EjectBallsUnderFence”.
Once these functions are created, in our main program we can now place a call to each of them in succession. Keeping each short means they are easy to understand when we (or especially someone else) goes back to inspect them later. And by the way, this rule of “all on one screen” should apply equally to the main program. For instance, the main program can consist simply of two functions, one called “AutonomousCode” and the other called “DriverControl”. Functions can call other functions as well, so you can develop something similar to an outline that one develops for an essay.
One other bit of programming advice which isn’t specific about functions but rather about programming in general is to make good use of comments. This takes discipline, and many people feel like they “don’t want to be bothered”, but it sure makes a difference when you are debugging or going back to a program after not looking at it for some time. Or where it is really useful is when your buddy has written the autonomous code for some big competition, but ends up falling sick the day of, then you need to tweak his code. Well, in this instance, the comments serve as bread crumbs leading you through it all.
Anyhow, hopefully some of this has been useful to you. If you have any further questions, post up again.
Vman
Vman,
Just to show my antiquity:
When I was an undergraduate, the rule of thumb for writing subroutines and functions was that they had to fit, when written by hand, on a standard 80-column punch card. That’s a bit tighter :rolleyes: than your single-screen rule, but it did teach us to structure the hell out of our code.
These days, I don’t know if it would be harder to find scrap cards on which to write code or to find a user interface that doesn’t have a screen. (I remember when the 30 character/second DECWriter was the high-end terminal in the room.)
Eric
My take on user functions is that they should be used either to break up code into manageable sections, e.g. one autonomous routine per user function and also for stuff that is used very regularly
For example, we have
bot_forward
bot_backward
bot_left
bot_right
arm_up
arm_down
Inside each of those we just set the respective motors to 255/0 which makes life much simpler.
Or not fit
There are at least 10 kinds of people in the world.
“at least”?
I’ve heard that there are “only 10 kinds of people in the world, those who think in binary and those who don’t”.
Eric