New Controller Specs Posted

[Ian W.]

No news on the OI yet, is there...

I'm thinking it'll be the same, because of the lack of an OI for the vetern teams to use with the EduBot RC.

One thing that I'm not sure about though, what about the dashboard port. Will that change this year, or will it stay the same? I'm hoping we have control over it this year, but I haven't seen any information on that yet.

[Rickertsen2]

there is really no reason to change the OI. (well i guess i can think of a few)...


Hrmmm.... Whats up with the "PWM in"?

[Sachiel7]

The Digital In/Out's got me thinking...
I wonder if we'll be allowed to interface the Digital In/Out from the eduRc straight to the Digital in/out on the Full RC for competition?
Then the eduRC could handle some low-level processing and data storage for auto mode, and the full rc would handle high-level processing, and main operation data...
Hmm...
I wonder if this will be allowed of not?
I'm tinkering with putting together some C headers w/ structures now, so I can get going as soon as we get our new RC
The fact that Vet's aren't getting new OI's pre-season is leading me to believe that there will be few changes to the new OI, if any. I assume the Dashboard port may change, and a new Dashboard program will be released.
Not much really needs to be done to the OI... Maybe a longer adapter cord?
Who Knows...

[Venkatesh]

Im quite impressed. I need to learn C for this, but it is worth the effort.

Also, since we (apparantly) can code in assembly, and I am quite fluent in x86 assembly, would it better for me to learn C or the PIC assembly?

Finally, I can't wait to see some default code.

[FotoPlasma]

Originally posted by Sachiel7
The Digital In/Out's got me thinking...
I wonder if we'll be allowed to interface the Digital In/Out from the eduRc straight to the Digital in/out on the Full RC for competition?
Then the eduRC could handle some low-level processing and data storage for auto mode, and the full rc would handle high-level processing, and main operation data...
Hmm...
I wonder if this will be allowed of not?

If the FRC RC has a TTL serial port, wouldn't it be easier (and faster) to use that link to communicate between systems?

Also, if there's an imposed limit on price for external electronics, again, it might not be legal to use an EduRC in conjunction with the FRC RC, depending on its price.

[KenWittlief]

you would definately want to learn C before you learn assembler.

assembly code is tedious and error prone.

[Dave Flowerday]

Originally posted by FotoPlasma
If the FRC RC has a TTL serial port, wouldn't it be easier (and faster) to use that link to communicate between systems?

You could almost certainly implement a faster data transfer protocol between the RC and an external microcontroller using the digital I/O than using a serial connection limited to 115k. Parallel I/O is nearly always faster than serial. However, it would indeed be quite a hassle.

[FotoPlasma]

Originally posted by Dave Flowerday
You could almost certainly implement a faster data transfer protocol between the RC and an external microcontroller using the digital I/O than using a serial connection limited to 115k. Parallel I/O is nearly always faster than serial. However, it would indeed be quite a hassle.

Ah. Sorry. My mistake. It makes sense that a parallel system would be faster than serial.

Also, concerning the posted specs, shouldn't the PIC18F8520 be running at 40MHz, instead of 50MHz, as IFI says? The processor is listed as having a maximum Fosc of 40MHz, on Microchip's page.

<edit>
Deleted something stupid. Thanks to Matt Leese for pointing it out.
</edit>

[Matt Leese]

Originally posted by Dave Flowerday
Parallel I/O is nearly always faster than serial.

That's true until you get to high transmission frequencies. Then crosstalk becomes such an issue that it's easier to send things over a smaller number of wires. This is why many computer interfacing technologies are switching from parallel serial (parallel ports to Universal Serial Bus; Parallel IDE to Serial ATA).

Now, obviously, that won't be an issue here (I'd be highly surprised if any team managed to even come close to maxing out the serial port) but I thought it was important to point out.

Matt

[Matt Leese]

Originally posted by FotoPlasma
Still, quite an improvement over ~40Hz.

The Basic Stamp runs at quite higher than 40 Hz. It executes somewhere in the thousands (tens of thousands?) of PBasic instructions per second. These are a much higher level construct than assembly language so it executes even more instructions per second.

I believe the ~40 Hz number you produced came from the fact that the robot controller received input data approximately 40 times a second. Given that it blocked before reading data, it basically meant you went through your loop 40 times per second.

Matt

[SarahB]

Originally posted by FotoPlasma
If the FRC RC has a TTL serial port

What exactly is a TTL serial port? What's the difference between it and a normal serial port?

I've been asking around and no one seems to know

[Matt Leese]

This is mostly an educated guess but I'm assuming TTL Serial port means that the line level outputs of the serial port are at TTL level. TTL level defines zero as from 0 to 0.8 V and a one as from 2 to 5 V. Now, normal RS232 Serial Ports have an operating range from -15V to 15V for their output. The TTL Serial Port is a serial port that is specifically designed to interface with either TTL or TTL-compatible circuits. This means that it's much more effective for controlling a custom circuit than a regular RS232 Serial Port.

Matt

[KenWittlief]

I agree with Matt. It would be an easy way to connect to a second PIC chip (if you want to use one for something else) and it would act just like an RS-232 link, expect you dont need the tranceivers to convert the voltage levels, since your second PIC chip will only be a few inches away from the robot controller.

This new robot controller is really going to open up a lot of possiblilites for teams with EE's and SW engineers to do some impressive stuff with the machines.

[ttedrow]

Finally, power real power. Now the programmers can take over the world.

Oh, sorry. I think I'm getting a little carried away

[Andy Baker]

Originally posted by ttedrow
Finally, power real power. Now the programmers can take over the world.

Oh, sorry. I think I'm getting a little carried away

Yeah, us mechanical guys have been asking you software guys to work your magic for years, but your excuse has always been "the processor is not fast enough!" or "we don't have enough memory!".

Now, you're gonna have to look for new excuses.

Have fun, bit-twiddlers!



Andy B.