New Controller programmable in C

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

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