Programming languages in the embedded enviroment

[comphappy]

I really fail to see why so many people are not wanting to use C for embedded systems, 400mhz processors, what are you planning on doing that demands that much processing power it is crazy. Efficiency and overhead is what it boils down to.

I have nothing against python when it is used in an appropriate application, I have plenty of python scripts taking care of all kinds of tasks on my server, but that is because the C equivalents would take far to long to write and not offset the loss in performance. We are not doing anything close to powerful enough to justify co-processors of that magnitude, or a language of that high level. Yes I have considered implementing a co-processor, but it is just another microcontroller from freescale, which would allow me to load a RTOS.

The reality is C and asm are what people use for these applications in the real world, and while using other languages MAY allow you to work more efficiently in the 6-weeks we have, in the end what does it prepare us for?

I recommended that everyone reads this article by jon "madddog" hall, a programming god, http://www.linuxjournal.com/article/9647 he has been around from the beginning and has some very interesting insight.

Hope i did not step on too many toes.

Brennan Ashton

[ebarker]

Originally Posted by comphappy

Hope i did not step on too many toes.

If you are not stepping on toes then you are not making progress

[jtdowney]

The reason the team I help mentor (1646) is considering a co-processor is not the added processing power but the added flexibility. Such as being able to load MMC cards for different autonomous modes.

[Guy Davidson]

Have you looked into using the eeprom? Or just a switch connected to a few digital inputs and a few saved on the robot?

[jtdowney]

Originally Posted by sumadin

Have you looked into using the eeprom? Or just a switch connected to a few digital inputs and a few saved on the robot?

Auton modes was just an example. We really just wanted a solid platform we could extend and build on quickly.

[Guy Davidson]

Originally Posted by jtdowney

Auton modes was just an example. We really just wanted a solid platform we could extend and build on quickly.

Fair enough. I and the other programmers on team 8 (after trying to work with a coprocessor for the past few weeks) decided that it's more worth it to just program in regular C. We haven't been able to prove that the extra power is needed, while a coprocessor is much more complicated to run and maintain than regular C code.

[Salik Syed]

Python is often used on cellphones... which you could call an embedded system.

I think there are plenty of interesting things that could be done on a FIRST robot given a higher level programming language.

I don't think that first robots have anything interesting processing wise *yet* but there are MANY MANY things that can be done with that processing power, real time path planning with dynamics is one such thing:
http://scholar.google.com/scholar?q=...&b tnG=Search

We may need better sensing to make this stuff useful, but I can definitely see that happening in 2-3 years.
the 'real-world' also uses these high level languages for prototyping purposes and sometimes even for development because they are easier and more flexible.
I think it's better to develop algorithmic thought than to get better at writing C code. High level languages let you do that without worrying about minuscule details

I disagree with the article, understanding system level details is very low on the list of things that are important for computer scientists...programmers maybe, but not serious researchers.

[comphappy]

Personally i dont like how long it takes some of the apps on my phone to load.

Python is certainly better then Java (hello memory management). I guess the question becomes do we want to develop embedded systems or algorithms. I think we need to keep it low level like it is or step it up (in hardware too) to a hight level such as RTLinux or vxworks, then we can put databases and all kinds of other cool tool on it, which can be just as fun and not that hard with a little basic documentation (i would shy away from windows CE that some have mentioned, there is almost no ability for hardware interaction). I think FIRST has hit a split, and need to pick a path and not split the difference.

[Astronouth7303]

For what FIRSTers do, C is fine. As soon as you remove pointers & dynamic memory, C and Python become essentially equivalent.

Where interpreted languages shine is when you use things like objects/classes, dynamic memory, etc. It's hard enough to debug a memleak on a PC, much less on an embedded system.

When many teams struggle with programming at all, keeping programming simple should be a priority. Be it Python, C, Ruby, Perl, or another language, make easy to pick up.

The point of FIRST is to not train students for the workforce. FIRST does not replace school. No matter what language you use, some fundamental concepts (eg sensor feedback, control loops, autonomous programming) still apply.

[Foster]

I agree with the comment that none of the FIRST robots have pushed what could be done from a computing standpoint. But I applaud the people that are trying to push the edge with other languages, co-processors, other sensors, etc. From everything they learn pushes all of us along.

I'm working on a Vex based robot for a mini-DARPA road like challenge. One thing we want to use is a GPS to figure out where we are and where to go next. Rather than tying the main processor up talking to the GPS and doing the calculations, we are going to move it to a second Vex controller. The two controllers will talk across a serial connection. This knowledge will help other teams that want to do co-processors.

So don't discard the efforts in Python or OOCobol or additional hardware, next year YOU might be using that neural net interface to find the IR beacon.