If you could write the default code...

[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

[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.

[Kevin Watson]

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]

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]

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.]

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 ( ) 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]

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]

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]

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]

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]

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]

Yeah, I know, I removed read-only from everything as soon as I got the default code, but it's still annoying.

[Joe Ross]

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]

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]

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.