Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   If you could write the default code... (http://www.chiefdelphi.com/forums/showthread.php?t=38812)

Kevin Watson 01-07-2005 14:55

If you could write the default code...
 
Just out of curiosity, if you could design the RC default code, what would the architecture look like? What do you like about the current default RC code? What don't you like?

-Kevin

Matt Krass 01-07-2005 15:16

Re: If you could write the default code...
 
I think functions names could be shortened, with explanatory comments. I know (well, I don't know but I suspect very strongly) you are trying to make the function names self-explanatory, but after a while it gets annoying to be perfectly honest typing out those long names. And maybe make the flow a little bit easier to follow, otherwise I commend your work, it's quite helpful.

Kevin Watson 01-07-2005 16:08

Re: If you could write the default code...
 
Quote:

Originally Posted by Matt Krass
I think functions names could be shortened, with explanatory comments. I know (well, I don't know but I suspect very strongly) you are trying to make the function names self-explanatory, but after a while it gets annoying to be perfectly honest typing out those long names. And maybe make the flow a little bit easier to follow, otherwise I commend your work, it's quite helpful.

Thanks. Comments about my code are always welcome, but I'm more interested in how the default code included with the RC is perceived. What do you like? What don't you like? What improvements (if any) would you make?

-Kevin

RbtGal1351 01-07-2005 21:31

Re: If you could write the default code...
 
Quote:

Originally Posted by Kevin Watson
Just out of curiosity, if you could design the RC default code, what would the architecture look like? What do you like about the current default RC code? What don't you like?

-Kevin

It'd be really nice if it was easier to debug... Mostly debugging isn't necessary with the default code, but it's annoying to go hunting around to figure out where that function is called, when, why, if it ever happens, etc.
Maybe a more logical flow (altho im not sure what, but you asked for feedback), so you don't have to go hunting through every file for that function!

Personally i dont mind the long names - i'd rather them than, 'what does this do again?!'

~Stephanie
Team 1351

ps- i'll think about what to change next time im programming! ;)

[edit] and i definately agree w/ seanwitte, see below [/edit]

seanwitte 01-07-2005 22:15

Re: If you could write the default code...
 
It would be nice if was organized with hooks for discrete events since the programs all follow a similar lifecycle. This is rough, but something like:

masterSystemInit() - runs once at startup to configure the device
masterUserInit() - runs once at startup to configure user information
runDisabled() - runs while robot is disabled
initAutonomous() - runs once when state changes to autonomous
runAutonomous() - runs each cycle during autonomous
initTeleoperation() - runs once when state changes to teleoperation mode
runTeleoperation() - runs each cycle during teleoperation
readInputs() - runs at the start of each cycle to collect any inputs
writeOutputs() - runs at the end of each cycle to update relays and motors

This framework would allow you to focus on these relatively simple stubs. The flow of the framework code would be something like:

masterSystemInit()
masterUserInit()
while 1=1
wait for master uP

readInputs()

if runState != previous runState then
if runState = AUTO then
initAutonomous()
elseif runState = TELEOP then
initTeleoperation()
end if

if runState = DISABLED then
runDisabled()
else if runState = AUTO then
runAutonomous()
else
runTeleoperation()
end if

writeOutputs()
wend

Ryan M. 02-07-2005 08:03

Re: If you could write the default code...
 
Quote:

Originally Posted by seanwitte
It would be nice if was organized with hooks for discrete events since the programs all follow a similar lifecycle. This is rough, but something like:

...rest of post..

Interesting idea. I like it. :)

Two things: I can't stand the fact that spaces are used instead of tabs (:rolleyes: ) and it might be nice (especially for new FIRST programmers) if all "never editable" files were moved into a subdirectory. That would make it more obvious what you are supposed to edit as well as make finding individual files easier.

Kevin Watson 02-07-2005 12:33

Re: If you could write the default code...
 
Quote:

Originally Posted by Ryan M.
...all "never editable" files were moved into a subdirectory. That would both make it more obvious what you are supposed to edit as well as make finding individual files easier.

Good idea. How about just putting those functions into a library? The library source code could be provided as a separate project.

-Kevin

Bharat Nain 02-07-2005 16:40

Re: If you could write the default code...
 
Quote:

Originally Posted by Kevin Watson
Good idea. How about just putting those functions into a library? The library source code could be provided as a separate project.

-Kevin

Now that is an excellent idea. That would make it a lot easier to play around with different versions of a code.

Orborde 16-07-2005 02:56

Re: If you could write the default code...
 
I personally like being able to modify main.c, and I think that "DO NOT EDIT THIS FILE" should be sufficient warning for the clueless.

I like how the code is put together to some extent, but I sometimes wish it weren't so massively splayed out across 15 files.

Kyle T 23-07-2005 21:17

Re: If you could write the default code...
 
I just hate how they made all those 'don't touch' read only. What if I want to add my own aliases to ifi_aliases.h? I have to go out of MPLAB, find the file, un-read-only it, and then re-open it with MPLAB.

RyanMcE 24-07-2005 16:46

Re: If you could write the default code...
 
Quote:

Originally Posted by Kyle T
I just hate how they made all those 'don't touch' read only. What if I want to add my own aliases to ifi_aliases.h? I have to go out of MPLAB, find the file, un-read-only it, and then re-open it with MPLAB.

Or in the open or save as dialog you can right click on the file, select properties, uncheck the read-only box, and then open or save the file. Or you could make all the files writable before starting work. Hope this helps speed up the process!

Kyle T 24-07-2005 20:49

Re: If you could write the default code...
 
Yeah, I know, I removed read-only from everything as soon as I got the default code, but it's still annoying.

Joe Ross 24-07-2005 21:07

Re: If you could write the default code...
 
Quote:

Originally Posted by Kyle T
I just hate how they made all those 'don't touch' read only. What if I want to add my own aliases to ifi_aliases.h?

It's a bad idea to modify ifi_aliases.h. If IFI ever releases a new version of the default code with a new ifi_aliases.h, you'll have to redo all your changes which leads to errors and extra work. It's also almost impossible to pass your code on to the next set of programmers.

Instead, you should create a new file, perhaps "kyles_aliases.h" and add everything you want there.

mpob 25-07-2005 12:34

Re: If you could write the default code...
 
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

Hutch 25-07-2005 16:48

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.


All times are GMT -5. The time now is 00:35.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi