Development enviroments orther than MPLAB

[mikew]

wine+mcc18+makefile+ifi_picloader

works way better than MPLAB since I can use vim or kate or whatever else I want, and the cli bootloader feels less clumsy than ifi's loader.

[Tom Bottiglieri]

i would do something else, but im too lazy

[deltacoder1020]

horray for vim, the true "programmer's text editor"

[wun]

Originally Posted by deltacoder1020

horray for vim, the true "programmer's text editor"

*cheers* Yup! Nothing like it.
(you know youve been coding with vim too long when you start hitting j and k when your on the web... Thank heaven FireFox knows to start searching when you hit /)

[deltacoder1020]

Originally Posted by wun

*cheers* Yup! Nothing like it.
(you know youve been coding with vim too long when you start hitting j and k when your on the web... Thank heaven FireFox knows to start searching when you hit /)

no, you know you've been using vim to long when you start typing :w for no reason at all into your word documents at school....

[Ryan M.]

Actually, I find vim scary.

My team used MPLAB + Windows since I was the only one with Linux on their machine. Plus, I didn't find out until later that others got the IFI_Loader to work with WINE with no major problems.

[mikew]

afaik, the ifi loader still doesn't work through wine. A new one was coded from scratch to do the job.

[Ryan M.]

Same thing.

[CrashZero]

I used the MPLAB IDE with windows cuz I was way to lazy to use anything else, I mean most of my code is just the default; My team was kinda picky about having it working b4 we shipped;

[Astronouth7303]

The bot barely worked when we shipped. And the code was screwed up so badly that the controller gave us a red-green. (RGOD!) Or an infinate loop.

[CrashZero]

Thats nothing all our robot did when we shipped it was spin in a circle. cuz the stupid build team put one of the fricking moters in backwards. I think that when we get there i can download a code that works but we will literally be testing it on our bot for the first time then. If anything goes wrong i am sure that all you programers out there know that it is me who will be blamed for screwing it up, even though if the builders whould have put it in right it would not have been a problem.

[fred]

Our situation is sort of weird. I definitely like where we went with the robot and if it turns out correctly, look out for Miss Daisy. We didn't make too many modications to the code, not enough to warrant switching from Windows or anything. The problem is that our code hadn't been tested with the robot at all before we shipped. But we have some good programmers and I think that we will definitely turn out okay. See ya at Chesapeake.

[hybrid]

Originally Posted by CrashZero

Thats nothing all our robot did when we shipped it was spin in a circle. cuz the stupid build team put one of the fricking moters in backwards. I think that when we get there i can download a code that works but we will literally be testing it on our bot for the first time then. If anything goes wrong i am sure that all you programers out there know that it is me who will be blamed for screwing it up, even though if the builders whould have put it in right it would not have been a problem.

You think that that's nothing. We shipped six pieces of metal with the rest of the requirements. And a few motors.

[Tom Saxton]

Originally Posted by CrashZero

Thats nothing all our robot did when we shipped it was spin in a circle. cuz the stupid build team put one of the fricking moters in backwards. I think that when we get there i can download a code that works but we will literally be testing it on our bot for the first time then. If anything goes wrong i am sure that all you programers out there know that it is me who will be blamed for screwing it up, even though if the builders whould have put it in right it would not have been a problem.

Our code has exactly one place in the code that knows how to run the drive motors.

// Set the left and right drive motors to the specified speed values.
//
// The speed values must be in the range [-127, 127].
// For both motors:
//    0 is stop
//    postive values move that wheel forward
//    negative values move that wheel backward
//
void SetDriveMotors(int speedLeft, int speedRight)
{
	pwmWheelL = pwm01 + speedLeft;
	pwmWheelR = pwm02 + speedRight;
}

This simple encapsulation has many advantages.

This chunk of code is the only place that has to keep track of "bigger than 127 goes forward, less is backward, proportional to the difference" or the other way around if either motor is wired the other way.

It's much easier to read "SetDriveMotors(10, -10)" than "pwm01 = 137; pwm02 = 117;" and know that it's asking for a slow right turn.

If one of the motors gets wired backwards, it's trivial to change the +/- for that motor in one well-defined place. (We also put polarized connectors on the motors, so that motors can't get reversed for anything less than a motor replacement.) It's also trivial to move the drive motor to a different PWM if need be.

The software team gets so little time with the working robot, it doesn't pay to spend time and energy blaming the build/electronics team for something being backwards. If you keep the knowledge localized in the code, it's trivial to adjust, compile and download. This is especially handy if you just finished a big repair two minutes before the next match and there's no time to crawl back in and reverse a couple of wires.