What language do you use?

[Alexa Stott]

Originally Posted by ThienAn

seems like everyone uses C for their robotics lol. (This is same person from original post, I was just using another person's account because I hadn't activated mine yet - darn school WebSense) What I want to know is there any way to use Java? because I'm taking/have taken a class on Java, whereas I know nothing about C or anything else except a little HTML. What would you guys recommend? Plus, I heard from my teacher/mentor that there was something else people use? EasyC/C and...RoboC or something like that (he didn't know himself, told me to find out )

I wouldn't recommend you no use EasyC. You said that you know some Java and, as JamesBrown pointed out earlier, C and Java are very similar.

[Kingofl337]

Here are some good video's of what you can do in easyC

http://www.checkmate40.com/Video/2006/ma_sf2m1.html

http://www.checkmate40.com/Video/2006/GSR_Auto.mov

http://www.checkmate40.com/Video/2006/new_096.html

This was a 3 speed, mecanum drive robot, with 8 autonomous modes
that could run from all 3 spots and adjust the final distance
from the goal. We used an xBox360 controller rewired to the
DB15. It was 100% programmed in easyC for FRC. I don't say
this to brag but just to point out the capabilities of this tool.
After working with the kids programming I very much doubt
there is anything you can't do with easyC in a FIRST robotics
environment.

This is what it comes down to. The function of easyC its not
to replace C as language its designed to teach C. It's a tool
designed to enable rapid testing and develop programs specifically
geared towards FRC and VEX robotic platforms. easyC was
developed after team 40 and mentors from intelitek coming
to the conclusion it's way to much work to program these robots
even to do the simplest of tasks. Like a simple closed loop proportional
drive system. Add to the fact that most teams give the robot
to the programmers 3 days before ship and say, "Get to work"
that or compromise a design because they don't think they can
program it.

In the end all I'm asking is open your mind and give easyC for FRC
a shot, a dedicated attempt to program your 05 or 06 robot.
For most experienced programmers I bet you can program your
entire Operator Control in under 1/2hr. easyC is just a tool,
designed to make life a little easier for the FIRST community.

[Sparks333]

C and Assembly for robotics - I'm a low-level guy
C++ when I need compiled OOP capability
JAVA when I want to have portability
Ti-Basic for fun
Dabbled in a few others, few compare to C in terms of versatility and reliability. Plus, several of the major programming languages use a similar syntax to C, so knowing C inside and out has other advantages.

I didn't like Java (and don't think I'd like EasyC) because of its inherent lack of settable pointers - I know, most people think they are the devil, and it's true they can royally screw something up if done incorrectly, but passing something by address is hugely faster than by value.

Sparks

[Qbranch]

Robotics: C
General Purpose Embedded: C
Fast Routines: Assembly
School: Java
Calculator: TIbasic and C (yes, there is a compiler)
Quick/Dirty Interfaces and I/O: VB6 (NOT .NET), C++, or QB

-Q

[gobeavs]

Robotics: C
Most other things: Ruby

Learning C# though as a sort of middle-ground.

[Cjmovie]

Robotics: C
Simple Programs: C+ (Yes, C and C++ mixture. If you can call it that)
Complex Programs: C++
Web Development: PHP, SQL (MySQL), XHTML, CSS, Javascript
Low-Level (Such as OS-DEV): x86 ASM
School: Java (which I used to hate with a passion; not so much anymore)

Among other things...
SX Assembly for the SX52 Microcontroller (Crazy thing, 80MHz! You can write a video kernel in it - software black and white NTSC :-) )
And I've experimented with many C-based scripting languages.

[Tom Bottiglieri]

C#

[dcbrown]

MICRO32 , for low-level h/w bit pushing projects
MACRO32, for assembler level
BLISS for high level...

Of course my first "electronics" class in high school votech did involve 6.3VAC and filaments....

But seriously, any programming language can be used... it is how you use it that counts as long as the resulting run-time execution profile, code size, or data space used doesn't put you at a disadvantage over some other language or tool.

Personally, I always look at the assembler generated by the compiler to see if I'm using things correctly to match the processor architecture. If a line of C code is compiled into 30-40 instructions, then I probably didn't choose the best programming method for solving the problem. For example, in one piece of code I just finished I needed to walk an array and move all the entries up one until some end condition. Putting the code in a loop looked good in C - nice and compact - until I looked at the compiled code. It took some 196 cycles on average to do all the array indexing computations, move the data around, and do end condition check for just 2 array entries with the for loop. In contrast, unwinding the for loop across the whole array

array[0] = array[1];
array[1] = array[2];
...

takes only 64 cycles to always move the whole array even though its like 8-10x more C code. The particular chunk of code started life as a singly linked list structure, but computationally it was just too expensive in terms of compiled code size and execution time. Building a lookaside/ordered index table as a companion to the data structures was much more effecient on the current processor in this case.

The argument of using oop or this or that os is often moot - none of those run very well at all on the current architecture. Moving to a processor that does run linux, say, still doesn't begin to address the issues introduced by using a full blown os; namely no pre-emptive scheduling and very long latency issues in terms of use within a real-time system such as a robot. Yes, there are flavors and changes you can make to get linux to almost be rtos capable, but that typically means either throwing some serious h/w at it or reduction of kernel services to something that means you're really not running linux but some strangled subset there of.

The flip side is learning to program well with an architecture that is both powerful and weak at the same time.

The test of learning to program well is capitalizing on the PICs strengths while recognizing and avoiding its weaknesses as much as possible. If you can do this using some other language or interface - great! Go for it! But for now, I'll stick to C and EasyC as both put me only at a slight disadvantage over assembler if the proper programming method is found and utilized.

Bud

[cjelly]

For the robot I code in C. Last year, we started a dashboard in VB.NET (that was the main language that my friend and I knew) but eventually converted over to C# after discovering dashboard code that already had most of the work done on it (it was posted on ChiefDelphi somewhere).

Personally, I used .NET for a while, but I found that everything Microsoft makes for development products (that is worth using that is) is very expensive. I do like the express editions of .NET 2.0, but they are somewhat limiting, especially SQL Server Express.

For a job I was doing last year I was forced to switch over to PHP running on an Apache server with a MySQL database backend, and it was so much less restrictive than Microsoft, it was free, and it was more logical I found. I ended up switching my hosting from Microsoft Hosting (on IIS) to Linux Hosting (on Apache).

[teh_pwnerer795]

C for FIRST
Turing for School
Learnt abit of Java2 overr the summer
and

im learning visual basic and possibly python before the summer

[Eric Finn]

C for the robot,
C or C++ for applications (C++ for our team's dashboard),
Perl for what I don't know how to do in C/C++,
and I'm probably going to learn C# for Microsoft's Robotics Studio.

[JBotAlan]

C for FIRST
PHP and MySQL for web design (not very good yet)
VB6 (yuck) for prototyping Windows apps (hey, it's my primary language and what got me interested in programming for robotics)
C++ for whatever apps I need for programming class.

That's about it. I've known a ton more, but forgotten them because they don't matter (like Not Quite C for the Lego RCX).

JBot

[Jake M]

Personally, I always look at the assembler generated by the compiler to see if I'm using things correctly to match the processor architecture.[/quote]

Not to sound like an idiot, but how do you do this? I know assembly language quite well, but I never really found an application for it in practical programming. Is there a way to do this in FRC programming as well?

[Astronouth7303]

Originally Posted by Jake M

Not to sound like an idiot, but how do you do this? I know assembly language quite well, but I never really found an application for it in practical programming. Is there a way to do this in FRC programming as well?

Use the list file. It's optionally generated by the linker.

[dcbrown]

In MPLAB IDE, View->Disassembly Listing or View->Program Memory.

If using Program Memory view, I select the "Symbolic" tab at the bottom of the window.

For example,

void EventHandler_Remove( void )
{
unsigned char ndx;

    for (ndx=0; ndx<MAX_EVENT; ndx++)
    {
	EV_Links[ndx] = EV_Links[ndx+1];
	if (EV_Links[ndx] == 0xFF ) break;
    }
    return;
}

Generates 33 instruction cycles per loop plus 9 instruction cycles of overhead/setup. It could take a maximum of 537 instruction cycles to complete if the event array is full.

526:                   for (ndx=0; ndx<MAX_EVENT; ndx++)
  6002    6ADF     CLRF 0xfdf, ACCESS
  6004    0E10     MOVLW 0x10
  6006    5CDF     SUBWF 0xfdf, W, ACCESS
  6008    E21D     BC 0x6044
  6040    2ADF     INCF 0xfdf, F, ACCESS
  6042    D7E0     BRA 0x6004
527:                   {
528:               	EV_Links[ndx] = EV_Links[ndx+1];
  600A    28DF     INCF 0xfdf, W, ACCESS
  600C    6AEA     CLRF 0xfea, ACCESS
  600E    0FE0     ADDLW 0xe0
  6010    6EE9     MOVWF 0xfe9, ACCESS
  6012    0E07     MOVLW 0x7
  6014    22EA     ADDWFC 0xfea, F, ACCESS
  6016    50EF     MOVF 0xfef, W, ACCESS
  6018    6EE6     MOVWF 0xfe6, ACCESS
  601A    50DF     MOVF 0xfdf, W, ACCESS
  601C    6AEA     CLRF 0xfea, ACCESS
  601E    0FE0     ADDLW 0xe0
  6020    6EE9     MOVWF 0xfe9, ACCESS
  6022    0E07     MOVLW 0x7
  6024    22EA     ADDWFC 0xfea, F, ACCESS
  6026    52E5     MOVF 0xfe5, F, ACCESS
  6028    50E7     MOVF 0xfe7, W, ACCESS
  602A    6EEF     MOVWF 0xfef, ACCESS
529:               	if (EV_Links[ndx] == 0xFF ) break;
  602C    50DF     MOVF 0xfdf, W, ACCESS
  602E    6AEA     CLRF 0xfea, ACCESS
  6030    0FE0     ADDLW 0xe0
  6032    6EE9     MOVWF 0xfe9, ACCESS
  6034    0E07     MOVLW 0x7
  6036    22EA     ADDWFC 0xfea, F, ACCESS
  6038    50EF     MOVF 0xfef, W, ACCESS
  603A    08FF     SUBLW 0xff
  603C    E101     BNZ 0x6040
  603E    D002     BRA 0x6044
530:                   }
531:                   return;
  6044    D005     BRA 0x6050

This is executed at interrupt time and looks a bit wordy. An alternative is code that does the following:

void EventHandler_Remove( void )
{
    EV_Links[0] = EV_Links[1];
    EV_Links[1] = EV_Links[2];
    <snip>
    EV_Links[15] = EV_Links[16];
    return;
}


533:                   EV_Links[0] = EV_Links[1];
  6046    C7E1     MOVFF 0x7e1, 0x7e0
  6048    F7E0     NOP
534:                   EV_Links[1] = EV_Links[2];
  604A    C7E2     MOVFF 0x7e2, 0x7e1
  604C    F7E1     NOP

This generates 32 instruction cycles for processing the whole array. So this code has more C code but executes faster than even the minimum 1 time through the arrray using the for loop. Although I can easily read the code and what it is doing, I'm really only interested in instruction counts. If the instructions being generated for each line of C code look a bit high in count, then I usually investigate and possibly re-think what I'm doing based upon how often the code is being executed and how time critical the code is. One of the weaknesses of the PIC18F architecture is array and pointer manipulation - for example - but there are other programming methods of organizing and processing the data to avoid or mitigate those weaknesses.

Bud