View Single Post
  #15   Spotlight this post!  
Unread 25-07-2005, 16:48
Hutch Hutch is offline
NOTAG
FRC #0461 (Westside Boiler Invasion)
Team Role: Programmer
 
Join Date: Jul 2005
Location: Indiana
Posts: 69
Hutch will become famous soon enoughHutch will become famous soon enough
Re: If you could write the default code...

Quote:
Originally Posted by mpob
I was new to the code this year, and noticed that the basic architecture is scan loops and ISR's.

Would it be useful to have an advanced version of the default code that contained an RTOS (Real Time Operating System).

With an RTOS the application code could be designed as indepently executing threads. I know it would add a layer of complexity as the programmers of this type of code kit would need to understand:
- what a semaphore is
- task priorities, and priority inversion
- designing and debugging multi-threaded code
- concepts like task switching, mutual exclusion, and race conditions
- Memory management
- Stack allocation, and management

a lot of complex things to understand, but a lot to be gained also,
which is why I was thinking in terms of offering this as a optional "advanced" code kit.

I have always been very comfortable working with real-time embedded code, and RTOS's. But it is an area of interest for me

But I am wondering what others think of this???

Is an RTOS to far out, and complex to be used in a FIRST Robot ?


--Mike O'Brien

I feel it's not entirely necessary at this point... Not to mention I doubt it's feasible with the current controller (think about the tiny memory size). That being said, if something more simplistic were done such as a simple cooperative multitasker (that's part of my design for next year), that would definitely be good. At the moment though, debugging is painful enough on the RC - no need to throw multithreading into the mix.

OP: I think maybe having cleaner code in general... No functions with comment headers longer than the functions, consistent naming, things like that.