you would definately want to learn C before you learn assembler.
assembly code is tedious and error prone.
you would definately want to learn C before you learn assembler.
assembly code is tedious and error prone.
*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.
*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>
*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
*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
*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:confused:
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
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.
Finally, power real power. Now the programmers can take over the world.
Oh, sorry. I think I’m getting a little carried away:yikes:
*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:yikes: **
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.
*Originally posted by Andy Baker *
**Have fun, bit-twiddlers!Andy B. **
I predict many sleepless nights (not that anything will change, in that regard), lots of heads being banged on desks, datasheets and manuals scattered over the floor, and Mountain Dew / Jolt / [pick your poison] cases filling the garbage cans.
*Originally posted by Andy Baker *
**
Now, you’re gonna have to look for new excuses.
**
You know those Spark-Es… always SOMETHING to whine about.
Anyone know if the Edu kit includes the MPLAB-C18 C compiler? If anyone has experience with this or other compilers that will play nicely with MPLAB, would you share your recommendations? Looking at the Microchip recommended compilers, it looks like most are $450 or more per license, except the CCS one for $175 .
I believe each team will receive the Full MPLAB w/ C-18 and Innovation First’s Programming Tool/Library for the RC with the pre-season kit. I already DL’d MPLAB… Tinkered around a little…
There’s really not much to do until we get c18 and the Library file, or whatever addon innovation first supplies us with.
Also, Freeze!
I just noticed something…
The eduRC does not have team number dip switches on it!
Does this mean that the eduRC will respond to any control system in the area?
Or is IFI creating a new way of Identifying teams in the control system, Maybe through programming?
Perhaps the device has a small memory block set aside for holding the team number, and it must be defined in the header of the program?
Hmm…this is interesting.
I wonder if the full-size RC will be the same?
Also, the RC PWM-In looks like it is an input from the PWM outputs on the Main RC. I’m not entirely sure why… but it seems like a cool idea. It really seems like they like the idea of interfacing the edubot with the main RC (TTL serial, Digital i/o, PWM in/out) I’m really beginning to think they may actually let us use the eduRC in collaboration w/ the full one this year…
*Originally posted by FotoPlasma *
**I predict … Mountain Dew / Jolt / [pick your poison] cases filling the garbage cans. **
How about the recycle bin? A little extra money for the team?
*Originally posted by gwross *
**How about the recycle bin? A little extra money for the team? **
I seem to remember a certain Dr. trying to collect aluminum cans in New Hampshire to take back with him to Michigan to help fundraise for his team. Then again, I’m probably the only one who remembers that…
Matt
Heh, I like the guys optimism…
But illegal actions are kinda not-cool at the same time, and as much as I think that’s awesome, it is also quite illegal because you rob 5 cents a can from the state… not that they shouldn’t be supporting robotics, but maybe we should work on getting them to do it formally…
*Originally posted by Sachiel7 *
**
Also, the RC PWM-In looks like it is an input from the PWM outputs on the Main RC. I’m not entirely sure why… but it seems like a cool idea. It really seems like they like the idea of interfacing the edubot with the main RC (TTL serial, Digital i/o, PWM in/out) I’m really beginning to think they may actually let us use the eduRC in collaboration w/ the full one this year… **
Eyes glaze over with joy!
one good reason to have a PWM input is you can design separate sensors or electronics that the RC uses as an input
and a PWM is a digital signal. Unlike the analog inputs, if its putting out zero, its putting out exactly zero, and the RC will read zero every time.
So the PWM input will lend itself to teams developing sensors (position, heading, yaw, speed, torque…) with a standard output.
That will allow the design to be used from one year to the next, and for teams to produce white papers on their designs that other teams can easily implement.
Also, I think there might be some sensors or gyro things on the market for radio controlled airplanes that have PWM outputs.
*Originally posted by gwross *
**How about the recycle bin? A little extra money for the team? **
Good point. Or you could do like Dave Lavery, and forge your own prototyping material out of scrap aluminum and spare cans. Recycle, reduce, reuse, and close the loop!
Also, as an aside, I thought this was just funny, as the comic strip tends to be. But I thought it was very funny that it’s written in C.