This Forum is Dedicated For all The Object Oriented PIC Lovers .......... The concept behind OOPic is straight forward. Use preprogrammed multitasking Objects from a library of highly optimized Objects to do all the work of interacting with the hardware. Then write small scripts in Basic, C, or Java syntax styles to control the Objects. During operation, the Objects run continuously and simultaneously in the background while the scripts run in the foreground telling the objects what to do.

Saturday, September 15, 2007

[oopic] Re: Roboteq motor controller.

> I have to send only a few numbers of charachters and numbers.

If your character set is limited, it is easy to precompute even parity
characters. But a lookup table is better.

> I can make a lookup table to check for the correct hex to send,
> withhout calculating anything. Will be a time consuming operation for
> the oopic?

Use the oEEPROM object and put a lookup table in EEPROM. Do all 256
chars (then you don't need to worry about only 128, etc.). Write one
program to initialize the table in a high location that won't get
overwritten when you load your application or write it in the E1
EEPROM space of the S board.

>
> (PS. i can't control by r/c radio because of problems with cable
> configuration).

Solving a cable issue will be a lot easier than dealing with this
serial problem!

>
> Other solution: does exist an ic that accept a serial comunication in
> 8N1 and reformat it to 7E1? Can a second MC do this for me or i will
> create a lot of delays?

Probably not but it would be easy with any chip containing 2 USARTs.
But, if you are going to use a separate uC, why use the OOPic at all?
Sure, object orientation is nice but it isn't the be-all, end-all of
controllers. When it doesn't fit, get something else.

In any event, there would be a 1 char delay (insignificant compared to
the execution rate of the OOPic) and it could easily be done with an
ATmega128 or any other AVR with 2 USARTs.

The cheap solution is to use the oEEPROM and have a base address where
the table is stored. Add the char to the base address to form the
EEPROM address and read the value. This will be reasonably fast but
it is character by character. If you want to send strings (like
numbers converted by STR$) then you have to iterate through the string
and that may be slow relative to the serial port. OTOH, if you use
oSerialL then everything will be slow.

A terrific solution for 2 motor controllers using serial interface
would be any of the AVRs with 2 USARTs. My absolute, all time,
favorite controller is the MAVRIC-IB http://www.bdmicro.com/mavric-ib/
because it has additional SRAM. Another favorite is the
http://www.bdmicro.com/mavric-iib/

Both of these are expensive.

A cheaper alternative is
http://www.sparkfun.com/commerce/product_info.php?products_id=37 which
has 2 serial ports but they need external RS232 level shifters.
Another choice would be the
http://www.sparkfun.com/commerce/product_info.php?products_id=35 which
is about as cheap as it gets. Obviously, both USARTs need level shifters.

My favorite level shifter: http://www.pololu.com/products/pololu/0126/

The ATmega162 is available in a 40 pin PDIP and it has 2 USARTs so it
is somewhat easier to breadboard.

Richard



Yahoo! Groups Links

<*> To visit your group on the web, go to:

http://groups.yahoo.com/group/oopic/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:

http://groups.yahoo.com/group/oopic/join

(Yahoo! ID required)

<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

http://docs.yahoo.com/info/terms/

No comments: