View Single Post
  #1   Spotlight this post!  
Unread 15-01-2005, 01:19
Unsung FIRST Hero
Mike Betts Mike Betts is offline
Electrical Engineer
no team
Team Role: Engineer
 
Join Date: Dec 2001
Rookie Year: 1995
Location: Homosassa, FL
Posts: 1,442
Mike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond reputeMike Betts has a reputation beyond repute
Re: Getting Started with Scripting

LBK,

I would love to give you a definitive answer be I'm stuck in the same quandary.

There are a few sources of good code, most notably IFI and Kevin's websites. You will have to decide for yourself.

My quandary is if my team should include the DDT (Dynamic Debugger Tool) support in the latest IFI default code into our system this year (it limits some other options).

And I am most definitely undecided if this scripting is such a good idea. C is the most popular embedded language because it allows very precise control of your hardware while remaining readable (vice assembler).

Higher language constructs, which were developed with appropriate disciplines (EBNF, et cetera), can remain useful for embedded applications. However, one starts to lose control of the hardware.

At a high level of abstraction, you lose all touch and feel with the hardware.

Where am I going with this digression? You may be comfortable with a desktop application locking up or giving you a Blue Screen of Death but would be at your lawyer's office in an instant if the airbag micro controller in your car malfunctioned.

The scripted language presented thus far seems to be very implementation specific and may difficult to maintain in the future. I'm not sure if this is the direction we should be following.

It is late and I am rambling... Excuse me please...

Bottom line, your team is responsible for the code in your robot and my team is responsible for ours. We cannot make anyone a scapegoat if our code does not function at the competition. Each of us may reach different conclusions.

Once again, sorry for not having an answer for you... Download it all and start dissecting...

Take what you need and leave the rest...
__________________
Mike Betts

Alumnus, Team 3518, Panthrobots, 2011
Alumnus, Team 177, Bobcat Robotics, 1995 - 2010
LRI, Connecticut Regional, 2007-2010
LRI, WPI Regional, 2009 - 2010
RI, South Florida Regional, 2012 - 2013

As easy as 355/113...