Scripting Setup and the Camera + Serial Port Drivers

[Tom Bottiglieri]

Wow, I never even thought to daisy chain processors using the serial port.

*achieves the "aha!" moment*

[Kevin Watson]

Originally Posted by CJO

I have not had a chance to e-mail Mr. Watson yet, however, trying to integrate the Camera control system into the scripting code is becoming a real nightmare. The difficulty is in the serial port driver. The problem as I see it is thus:



1) There are really three different serial port drivers...

Yes, this a bit of a pain. I hope to work this out with IFI in the near future.

-Kevin

[Venkatesh]

These multiprocessor systems sound very familar, a la 2003. In 2003, the Basic Stamp 2SX which we used was ill-suited to working with complex feedback systems and autonomous mode, so hundreds of various kludges were put together to all increased speed and advanced features.

A few notes of advice with regard to multiprocessor configurations.

First, debugging a system with one microcontroller is hard. Debugging one with two processors is 4 times as hard. Three is 9 times as hard and so on and on. Unless you have very very good reasons for using them, do not bother. You need a lot more electrical and electronic skill than is the norm to make such things work.

If you are interfacing a Basic Stamp to the PIC in the IFI blackbox, the BS has 2 ports which can be used for serial communication very easily, the two data pins of the programming port. These can be linked to the serial port of PIC and Mr.Watson's serial driver (and PBASIC serin/serout) can be used for data transfer. Remember, the Stamp is not capable of working at high serial baud rates!

If you want to go way overboard in terms of power (ie you have at least ten electronics and programming experts on the team), you could look into the line of Rabbit microcontrollers. They feature Ethernet connectivity and are very easy to use, if you can convince the manufacturers to donate the programming software ($395). I once used a Rabbit, 2002 FIRST controller, a relay, and a car battery to make a toaster with a webserver on board. Truly useful tools, those Rabbits.

If you add a second processor to just service interrupts, an older PIC16 should be able to do just fine, with the serial code from Mr.Watson.

But if you want to use some more sophisticated electronics to add features, one more option is available. Connect the IFI controller and the aux microcontroller to 74LS138 decoder chips. Then connect the output lines of the decoders to 8 AND gates (8 gates per decoder line). This system allows you to build a rudimentary bus between the processors, on which peripherals (sensors, etc) can be connected. We used this arrangement in 2003 (with tristate gates rather than AND gates) and it worked great.

And lastly, Good luck!

[CJO]

Thank you,

The third option, this would be using another PIC 16 or 18?

[ButcherMan]

If one really looks into the code, you can see that usr_SerialDrv.c and PicSerialDrv.c are nearly identical (IFI alludes to this in their FAQ). The PicSerialDrv.c was used for the DDT and later changed for the “user_” naming convention (according to IFI’s tech support). These are just driver templates and give the user the ability to handle his own read buffering if need be. The callback function (located in the CheckUartInts routine) is primarily used for building your own state machines based on a unique device protocol (like the Breaker Panel Board or the CMU2 camera).

Serial_ports.c provides read buffering on either port. It will require you to use a parser to parse incoming data and sometimes this takes more resources than just using a simple state machine to record the incoming data and set a flag indicating that the data is available.

Each driver has it’s own trade offs and that’s were the fun begins.

[Kevin Watson]

Originally Posted by ButcherMan

Serial_ports.c provides read buffering on either port. It will require you to use a parser to parse incoming data and sometimes this takes more resources than just using a simple state machine to record the incoming data and set a flag indicating that the data is available.

Just sit in a loop and while data is in the buffer, send the data to your state machine a byte at a time.

-Kevin

[Venkatesh]

To obtain RS232 Signal levels from the TTL port, what do you guys think of the MAX232 IC? I have never used it, but have heard good things about it.

[googlecamera]

Originally Posted by dhoizner

Hey,

Can someone point me to a tutorial regarding interrupts, and their implementation? I would much appreciate it, thanks in advance.

Dan

white on interrutps.
http://www.ifirobotics.com/docs/time...004-jan-14.pdf

gc