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]

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]

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! ;)

and i definately agree w/ seanwitte, see below

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

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]

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

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]

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]

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]

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.

[jdong]

I did some RTOS research with the PIC18 chipset last year, and concluded that it wasn't feasible; by the time the RTOS is on the chip, there's little/no resources for the actual code.

I've actually gone to the extreme and am experimenting with a Linux coprocessor setup via serial, using Kevin Watson's wonderful serial_ports code! It's working pretty successfully, and (if done correctly) is in full compliance with the 2004 and 2005 FIRST rules, so presumably the new rules, too, as long as we don't get a cease-and-desist for our work!

http://adambots.gotdns.com/cgi-bin/view/Main/DeltaForceCoProcessor

[Hutch]

The question I guess I have to ask is (and this is more directed at the content of the site than the actual idea), is that necessary? I mean it's cool and I like the idea, don't get me wrong. And I was the one defending shifting in drive trains, even though it's not necessary... But still, I think you kind of reach a point where you have to ask yourself, just how much processing power do you need? I mean, for most people, all their code does is map joysticks to motors (well ok, a little more than that but still). And if it really bothers you that much to write something in C, well maybe programming isn't for you :p.

I guess I just think it's kind of nice to program in a somewhat limitted environment because it makes it more challenging and fun.

EDIT: And this isn't just directed at you... I see a lot of people working on coprocessor projects and kind of wonder about it - no one seems to really use the power once they have it.

[Kyle T]

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.

If I want to add to the end of it, it's just a quick copy and paste; it's almost as simple as typing in include 'user_aliases.h';.

Speaking of which, I think any upgrades to the code should come in some kind of format (interpreted by the IDE, of course) which checks to see if the old blocks they replace are still intact and then and only then replacing them with the new ones. Having to re-insert all kinds of new sections of code in the event of an update is a real pain, and updates are sometimes neccessary.

[Hutch]

To solve the problem of that, I ended up with a file, user_nav.c, and it's header - I would include the header and call four functions in it (autoInit, autoDrive, userInit, userDrive or soemthing to that effect) and the calls to those four things were the only things I would ever have to change if all of the IFI code completely changed.