New Controller programmable in C

[dez250]

here is the latest email from first in it tells the truth with the new O/I and RC.

"The rumors are true; a new control system is coming. The new RC has a user programmable Microchip PIC" controller operating at 10 MIPS, gives direct access to I/O, has interrupts, and is programmable in C. Please do not contact Innovation First requesting information as more details will be available at www.InnovationFirst.com in the next few weeks when the product ships."

Thats a clipit form Bob Hammond's listserv email announcement!

~Michael

[Rickertsen2]

SWEET. I wonder what compiler they will be providing. I hope it is either Metrowerks, CCS, or Hi-Tech.

[djcapelis]

Any guesses on whether we can use gcc or derivitive with a library or something?

[KenWittlief]

If the new controller has a PIC Microchip on it then I would assume the C compiler will be the one from Microchip

I will have to check their website and see if you can get their C compiler for free. I know the assembler compiler and simulation tools for the Microchip devices are available for free.

PIC chips are pretty cool. You can do a lot of stuff with them fairly easy.

[KenWittlief]

looked at MicroChip's website. They do have SW development tools that include a C compiler and an assembler

It looks like its not a free download however, so if this is what FIRST is planning on using, I guess the SW will be part of the kit.

You can look around the MicroChip website to see what kind of stuff they have - here is a page that has one of their C compilers:

http://www.microchip.com/1010/pline/tools/picmicro/code/mplab17/index.htm

[Jeremy Roberts]

At Tech, an I'm sure at most other universities, we have embedded microcontroller classes. One of the classes uses the PIC18F452. Here is a link to the class website. If you click on PICbook you can access a few free downloads for this pic (not sure about the compatability with others). Take a look around, you may find something you can use. If not then as KenWittlief said, check the Microchip website.

http://piclab.ece.gatech.edu/

[KenWittlief]

I found the Microchip C compiler package at DigiKey

its $395.

if thats what we will be using, guess Ill wait till we get it from FIRST :c)

[djcapelis]

If it's a standard PIC controller... is there any reason we have to wait for their compiler?

Can't we just use an existing one?

[Rickertsen2]

Whoa!! since when does mirochip have their own compiler?

[FotoPlasma]

Originally posted by KenWittlief
I found the Microchip C compiler package at DigiKey

its $395.

if thats what we will be using, guess Ill wait till we get it from FIRST :c)

The MPLAB C18 C Compiler has a free demo available from Microchip's website.

http://www.microchip.com/1010/pline/tools/picmicro/code/mplab18/index.htm

[Ryan Foley]

Ok, I'm not good with this kind of stuff, so I have a few questions

What does 10MIPS mean?

What does it mean by "direct access to I/O"?

lastly, what does "has interrupts" mean?

[Jeremy Roberts]

Originally posted by Ryan Foley
Ok, I'm not good with this kind of stuff, so I have a few questions

What does 10MIPS mean?

What does it mean by "direct access to I/O"?

lastly, what does "has interrupts" mean?

MIPS is million instructions per second

Direct access to I/O means that you can access the pin inputs and ouputs for the controller and read and/or manipulate their values directly.

Interrupts are what a controller uses to perform other tasks outside the main program loop. The processor goes off for a while to process the interrupt and comes back to the main code where it left off (Could be used for sensor polling etc).

You should grab a good book on microcontrollers if you are really interested. It should explain all this stuff. Or just do a search on google.

[Ryan Foley]

Originally posted by skyman9000
MIPS is million instructions per second

Direct access to I/O means that you can access the pin inputs and ouputs for the controller and read and/or manipulate their values directly.

Interrupts are what a controller uses to perform other tasks outside the main program loop. The processor goes off for a while to process the interrupt and comes back to the main code where it left off (Could be used for sensor polling etc).

You should grab a good book on microcontrollers if you are really interested. It should explain all this stuff. Or just do a search on google.

Thanks.

[djcapelis]

So interrupts effectively facilitate good function jumps then?

[FotoPlasma]

Originally posted by djcapelis
So interrupts effectively facilitate good function jumps then?
I'm not sure exactly what you mean by a "function jump", but the way I understand it, when the system encounters an interrupt, it executes a predefined function, and then goes straight back to where it left off.

At the machine level, the system pushes the program counter (the address of the instruction it was at before it received the interrupt) into a stack, stores any important information, and jumps to the code of the function that should be run on the given interrupt. Once the interrupt's code has completed, the original address is popped out of the stack, and all of the aforementioned important information is put back in its original place.

I hope I got that all right. If not, please correct me.

[djcapelis]

Function jump, as in jumping to a function.

For example... (ignore the mix of c++ and the bad syntax, haven't used c-based programming in a bit)

void my_fuction();

void my_fuction()
{
cout << "Doggies run at midnight" << endl;
}

int main()
{
cout << "Jumping" << endl;
my_function();
return 1;
}

When the program calls my_function it would make a function jump and go to another place in the code, I believe... exactly as you described.

This can be hacked in PBASIC with GOTOs but isn't elegant in the least. So interrupts allow you to employ properly coded functions then... am I correct?

[FotoPlasma]

Ah. I don't think so. What you're doing is calling my_function() from within main(). What an interrupt would look like is this:
void main(void) {
/* these aren't the droids you're looking for, go about your business */
}

void interrupt1(void) {
/* do this stuff when interrupt 1 is encountered */
}

void interrupt2(void) {
/* do this stuff when interrupt 2 is encountered */
}
So, you wouldn't call interrupt1() or interrupt2() from anywhere in main() (although you could, if you wanted), but whenever the system received an interrupt signal, it would stop what it's doing in main(), and execute (or jump to, if you prefer) the predefined interrupt function, and then come back to main(). Another way of thinking of it might be to think of the system inserting a function call into the program at any point, depending on when it receives the interrupt signal. Whenever that signal is received, it automatically executes this predefined function.

Hrm. I just repeated myself a few times. I hope it makes some sense.

As for PBASIC, that language has subroutine functionality (through GOSUB and labels), which is sort of like a function, but it doesn't take any arguments and it doesn't return any value.

[djcapelis]

Oh, ic... an external interface triggers the interrupts, not the program itself.

I get it now... thanks.

(BTW, declaring main as void violates the language standards, technically that isn't legal. Compilers compile it anyways because people like breaking it... but exit codes are a good thing. Anyways...)

(Also, in case you were wondering where the jump part came from, I'd guess it's roots are probably in the ASM jmp instruction.)

[FotoPlasma]

Ah. I should have made that more clear.

Glad I could be of service, though.

(I never claimed to adhere to standards :) )

(Yeah, it is)

[Matt Leese]

I wanted to answer the question as to what 10 MIPS means: absolutely nothing. MIPS is really just a meaningless relationship because it doesn't show what type of instruction was executed. It could've been a series of NOP's. It can be rather frustrating trying to figure out how fast a CPU is just by manufacturer's information.

Matt

[DanL]

In my Cisco Networking class, we learned all about interrupts... if someone was playing a game on the computer rather than work, my teacher would go up to him...
"Do you know what an interrupt is?"
"...interrupt?"
*hits power button* "Yes, interrupt."

[Ian W.]

Hehe, learning interrupts the hard way...

The best part is that with ATX, you don't break Windows horrible when you hit the button.


Now, about these interrupts. Do they actually mean anything to us, if the code is structured at all like last year?

Last year, you could process all you wanted, but only output once per cycle. Will it be different now, since we can control all the pins, or will it be the same? If it's switch something whenever, however, then interrupts will be cool, otherwise, they seem nice, but kinda pointless.

Also, any ideas on whether or not we'll be getting a default code to build off of if we so choose?

[djcapelis]

Random wild speculations on your questions:

1) Interrupts will be useful for external first controlled operations so they can send signals to the bot that we can act on. (Auton triggers? Perhaps _optional_ auton triggers so teams that opt to go auton will be able to get a few extra points or something.) I dunno, just wild speculation. Or Interrupts allow us to press a button and have an action immediately take place.

2) Default code will probably be provided. Especially if the thing is done in C this year, they will need to give teams something to help them out. I can't imagine them not doing that....

3) Raw I/O access seems to indicate that we will be able to pull data in and out of pins at any point in the program. For a good autonomous mode, this seems like it would kinda be neccessary.

Wild speculation that has nothing to do with your message:

4) Auton mode will probably be vastly expanded this year?

5) The game might be changed to include signals from FIRST controllers to the bot that signify special events?

6) Something is up for this year... it's going to be nifty.

[Lloyd Burns]

Interrupts might, for example, make it easy for you to implement shaft encoding on your axles, where a change of voltage level on a pin will cause the encoder service routine to be executed (right away, not after the next block of instructions has been successfully received from the OI, as has been the case).

It will ensure that your special on-board g5-based massively-parallel 49 YHz screamer can pass data to or from the IFI CPU (The little engine that though it might be able ?). Now you can write both computers' programs in the same language... well, maybe not.

BTW, in the microchip PIC series, an interrupt causes the various processor regs to be stored, and then execution always jumps to program memory location 4 hex, so you may have to write an interrupt check-and-sort-it-out routine (in C) to go at hex 4 which will have jumps to the routine appropriate to the interrupt; probably the compiler will insert a jump around all this for start up, which always commences at 0 hex.

[FotoPlasma]

Originally posted by Lloyd Burns
BTW, in the microchip PIC series, an interrupt causes the various processor regs to be stored, and then execution always jumps to program memory location 4 hex, so you may have to write an interrupt check-and-sort-it-out routine (in C) to go at hex 4 which will have jumps to the routine appropriate to the interrupt; probably the compiler will insert a jump around all this for start up, which always commences at 0 hex.
I have been reading about various PICs for the past couple days, and some of the higher-end processors have multiple interrupt priorities which you can set (high and low). In the PIC18 series, the interrupt vectors for high and low priority interrupts are 0x8 and 0x18, respectively. You can manually poll the interrupt flags from within an interrupt routine to determine where you're coming from (or perhaps why you're going there:p), luckilly.

I hope the compiler we're to use supports inline assembly...

[djcapelis]

Inline asm is pretty standard on good chips I think...

I'm just gonna be annoyed if it won't work on linux.

[KenWittlief]

Interrupts are used when input signals can change state at random times, and you have to respond to that signal immediately.

a so so example is the keyboard on your PC. The processor has no way to anticipate when you will push a key, so that would be an interrupt

whenever you hit one, the code would stop whatever it was doing, go see what key you pressed, put that in a que or buffer somewhere, then go back to its regularly scheduled program

(thats not a really good example because the speed at which we type is extreemly slow to a processor, so it has plenty of time to go see what key you pressed, but you get the general idea)

on a bot something like a shaft encoder that puts out a pulse on each revolution - that could be an interrupt

or important things that need immediate attention, like a kill switch.

But if you want to know what an interrupt REALLY is

back when I was in engineering school, if you were walking down the hall talking to a friend and a girl walked by, that was an interrupt (we would stop talking for a second to activate the track and scan function)

and when she was gone you execute the return-from-interrupt instruction

(ah, those were the days! )

[vladg12]

No one has mentioned the most useful purpose of interrupts: TIMERS! Every time a timer overflows (which is in the order of microsecs), an interrupt is generated. This would be important for generating PWM signals (unless the chip has special PWM outputs), as well as for "accurate" (well, more accurate than with PBASIC) dead-reckoning code.

[djcapelis]

But if you want to know what an interrupt REALLY is

back when I was in engineering school, if you were walking down the hall talking to a friend and a girl walked by, that was an interrupt (we would stop talking for a second to activate the track and scan function)

and when she was gone you execute the return-from-interrupt instruction

(ah, those were the days! )

You need an interrupt for that? I thought that was the main program loop...

You also seem to be missing the ask_number and make_conversation functions, file corruption perhaps?

[WakeZero]

I like C, this news makes me very happy :yikes:

[KenWittlief]

Originally posted by djcapelis
You need an interrupt for that? I thought that was the main program loop...

You also seem to be missing the ask_number and make_conversation functions, file corruption perhaps?

didnt have the processing bandwidth to peform those tasks and meet the real time requirements of the multiple engineering_class routines.

had to establish strict priorities or the entire program might crash.

[djcapelis]

I wonder if larger hardware would have solved that problem.

(Yes, old joke and a bad one I know...)

[Rickertsen2]

lol



I wonder if there will be any sort of ICD capabilities. Does anybody know the specific pic?

[Jeff McCune]

Originally posted by Ian W.
Hehe, learning interrupts the hard way...

The best part is that with ATX, you don't break Windows horrible when you hit the button.

Now, about these interrupts. Do they actually mean anything to us, if the code is structured at all like last year?
They mean a ton to us. Have you tried to implement a shaft encoder with the basic stamp alone? Wouldn't it be nice if you didn't have to ASK the sensor for data all the time, and you could just be TOLD when the sensor tripped?
Last year, you could process all you wanted, but only output once per cycle. Will it be different now, since we can control all the pins, or will it be the same? If it's switch something whenever, however, then interrupts will be cool, otherwise, they seem nice, but kinda pointless.
I think you fell into the same trap many people fell into. First's default code is only an example that does I/O once per cycle through mainloop: There's absolutely nothing stopping you from reading in more data or writing out more data during the same iteration of the main loop. We implemented quite a few subroutines in our code that wrote data out to an external basic stamp and read it back in (External stamp was only counting clicks on a shaft encoder). In theory, if they gave you enough interrupts you could have a nearly empty main loop and do *everything* you need in interupt handling routines. And you'd probably be a lot better off, too, as you'd be only executing code you needed to execute at that particular time. About the only thing it would still be wise to poll would be the joystick axis.
Also, any ideas on whether or not we'll be getting a default code to build off of if we so choose?
I'd be surprised if they didn't give some example default code. Quite a few teams rely on the default code.

[JP_1163]

C programming (o:

PBasic programming )o:

The programming issue is here to stay. My only concern as a mentor to a team is providing my students with examples and assistance during the school year. Since my students do not have programming experience and will have to learn on the fly I have a question. Is there a viable, reasonable and teachable source of information on the C language available for student use? I am not a programmer and have limited (read none) access to programmers so anything I get will have to be understandable and teachable to non-programmers. Maybe if we start early enough we'll be able to get a workable autonomous program ready for the robot year!
Suggestions welcome.....

:D

[KenWittlief]

JP - my first suggestion would be to hook up with a SW engineer on another team who can be your mentor

even if that means you tell him what you want your SW to do, and he writes it all for you.

I have to assume that FIRST is going to supply a default program, like they always have, so each joystick will control a pwm output and each pushbutton will control a spike relay output

lots of teams use the default code and never change a line of it

so dont panic yet.

But if you can get a few students on the team able to understand C to some degree, they should be able to make minor changes to the 'new' default code.

[The Lucas]

Originally posted by vladg12
No one has mentioned the most useful purpose of interrupts: TIMERS!

Is anyone familiar enough with Microchip's line of processors to speculate whether or not the new Robot Controller will allow us to sample the system clock for timing purposes?

If you can not use the clock like in the current PBASIC Controllers, I would consider the whole upgrade a failure. If I have to count program iterations and change my timing constants every time I update the program with this new processor, then Innovation First is incompetent. It has interrupts and the highest priority interrupt is the system timer (just like in your PC). Can someone please tell me that I will not need to build a separate circuit for a simple crystal?

[KenWittlief]

Ive used MicroChips parts for many engineering designs. They are simply delightfull parts - you can get them with only 8 pins, or up to 40 or more

and they have all kinds of HW functions built in, timers counters PWM generators A to D converters, LCD and keypad interfaces

so the only thing we dont know yet is which PIC chip they are using, and how many of the functions and pins we will have access too?

Im pretty sure they all have at least one or two timers built in - bottom line is we will have to wait and see.

One thing to keep in mind in all of this. FIRST is not a robot building contest - its a program to teach students about the engineering design cycle.

Its not our purpose or intention to make the most sophisticated or elegant robot in the world - the idea is that we all start out with the same requirements, the same goals, and the same choices of what we can use, and see who comes up with the design that is most competitive.

If they threw the doors wide open and let us use whatever we want, then the winning team would be the one with the most engineers and money.

Having one hand tied behind your back by the tradeoffs you are forced to make, is part of the challenge.

and thats how it is in real-world engineering too. We cant put the most expensive parts in everything we build. Cost, performance, and time to market are a three sided triangle that must be balanced.

in the FIRST program the constraints are imposed artifically - they have to be, we only get 6 weeks. In the real world engineering programs can take anywhere from 6 months to 10 years.

[JP_1163]

[QUOTE]Originally posted by KenWittlief
[B]JP - my first suggestion would be to hook up with a SW engineer on another team who can be your mentor

Ken,

That would be the best. I'm not in panic mode yet...
Thanks.

[dez250]

JP, pm me here or email me at m.dessingue@team250.org and i will try to get you some good instructional items or learning materials on C.
~Mike

[catlin101]

Hey, I was looking at a few examples of PIC micro code, and the ones with interrupts didn't say anything about thread synchronization. Does anyone know of any functions like LockInterrupts() or anything like that, or are we just supposed to hope that an interrupt doesn't modify data while the main thread or another interrupt is using it

[Rickertsen2]

thread synching is minimal. about as sophisticated as it get is disabling interupts( at least in assembly ). Its your job to handle thread synching.


And yes there are at least 2 hardware timers on most PICs.

[Dave Flowerday]

Originally posted by catlin101
Hey, I was looking at a few examples of PIC micro code, and the ones with interrupts didn't say anything about thread synchronization. Does anyone know of any functions like LockInterrupts() or anything like that, or are we just supposed to hope that an interrupt doesn't modify data while the main thread or another interrupt is using it
Microcontrollers have an assembly instruction to disable interrupts. I'm guessing Innovation FIRST will provide a library that will implement a DisableInterrupts() type function in C which will simply call that assembly instruction (to prevent the need for teams to deal with assembly directly).

BTW (and it sounds like you probably know this already), you should never "hope" that an interrupt (or thread in a multithreaded system) won't modify data at the same time as another task. It will happen eventually, and it causes problems that can be really tough to debug.

[KenWittlief]

I had an old german professor in college, Dr Schmidt. Every few days he would give us one of his golden rules.

Concerning interrupts. First you have to design your system (SW and random input signals) so that your code runs by polling the inputs periodically.

once you have gone through the task of calculating how often each input signal will require attention, and how long it will take to service that signal

THEN you can use interrupts to implement the SW routines.

But if you cant service the interrupts by knowing how often to poll them, then if you blindly give each on an interupt instead, sooner or later they will pile up on you and the system will crash.

In other words: Interrupts should never be necessary to make your system work, use them only as a convienence.

[vladg12]

Has anyone been able to find the info about the new controllers that was supposed to be posted today? I can't find it either at innovationfirst.com or at usfirst.org. I called up both companies, and Innovation First told me that it's on FIRST's website, while FIRST told me that it's on Innovation First's website....:confused:

[Mike Betts]

http://www.innovationfirst.com/FIRSTRobotics/edu-rc.htm

[Merle]

I don't know what compiler First will give us or what version of MPLAB IDE, but these are available from the Microchip website:

MPLAB IDE (free download) ver 6.31
http://www.microchip.com/1010/pline/tools/picmicro/devenv/mplabi/mplab6/index.htm#mplab1


A 60-day demo version of the Microchip C18 compiler (MPLAB C18 ver 2.20) can be downloaded here:
http://www.microchip.com/1010/pline/tools/picmicro/code/mplab18/10167/index.htm

C18 Compiler User guide:
http://www.microchip.com/download/tools/picmicro/code/mplab18/51288b.pdf

C18 Compiler "Getting Started" guide:
http://www.microchip.com/download/tools/picmicro/code/mplab18/51295b.pdf


Later,
Merle
571 Team Paragon
Windsor, CT
father of 4 future FIRSTers :cool:

[ttedrow]

Rob,

How is the new emulator coming? Yes, yes, yes, we know you are a freshman in collage. You are going to have to skip a few frat parties...WE NEED YOU.

[mikew]

I think there's already PIC emulators out there.