[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