servo controller
Guillaume
based on a PIC16F628. The design phase is practically done with.
So far:
* 10 servos outputs;
* all outputs independently controllable with
a 200 ns resolution;
* "intelligent" control: you can set a timed displacement
of any servo (position 1 to position 2 in a T amount of time),
the displacement is all handled by the controller itself;
* I2C communication;
* future: Maple Bus communication for interfacing
with a Dreamcast console (which is going to be my
next robot platform).
If anyone has any suggestion for other features, please let
me know.
I'm thinking of making the whole thing open source; if
enough people seem to be interested. I'll post the work
on something like SourceForge (source code + doc + schematics).
Nikki Casali
Are you using the 16F628 as an I2C slave? If so, how are you polling for
a start condition? Are you using RB0 for external interrupts?
I've got a routine in which I just poll the SDA and SCL lines
continuously in software. It's taxing, but it works.
I hope you don't mind me asking!
Thanks,
Nikki
Guillaume
> a start condition? Are you using RB0 for external interrupts?
The 16F628 has native synchronous serial comm. support.
(contrary to the older 16F84).
Check out the PIC16F628 data sheet:
12.5 USART Synchronous Slave Mode
The flag bit RCIF is set and an interrupt is generated
when reception is complete.
Nikki Casali
I was referring to the I2C communication. You've mentioned this in your
bullet points. Or can the USART be used for I2C? That would be interesting.
Regards,
Nikki
Guillaume
> bullet points. Or can the USART be used for I2C? That would be
interesting.
Actually I haven't written any code for the I2C part as of yet, but I was
thinking
it would be no big deal using the USART in synchronous slave mode, or would
it??
Nikki Casali
I don't know anything about the USART in synchronous slave mode, but now
it sound interesting to me because I realise it's addressable, and that
means networks. I've only every used the USART on the 16F628 in
asynchronous mode.
Regards,
Nikki
The Artist Formerly Known As Kap'n Salty
news:3d838fa3$0$11796$7a62...@news.club-internet.fr...
I2C != synchronous serial
The 16F628 will do synchronous communications via its USART nicely -- the
9-bit addressing mode is a big plus --, but I2C is a different beast
electrically. I don't think you'll be able to do this using the USART. There
are, however, lots of ways to do it in software, and probably a good bit of
code floating around out there. The 16F87X parts, on the other hand, support
hardware I2C very well -- Master, Slave and Multi-Master Mode (although I
haven't done the latter).
If cost is not a big deal (but these parts are still pretty cheap,
relatively speaking), you might try using the 16F87x parts. You may see much
better performance, and you'll have a good bit less coding to do. One of
the advantages of the I2C hardware is that no slave on the bus will be
interrupted unless it is addressed by the master. Using Sync serial with the
'28, a slave still gets interrupted on every address transmit. Additionally,
every device that is to use your controller will need to be able to do sync
serial with the 9-bit address byte. This is doable, but puts a more of a
burden on client devices.
On the other hand, if you use regular async serial, just about any device
from a Stamp on up can use your controller with relative ease. You could
also provide both an I2C and an asynch version.
Hoe that helps -- tafKaks
--
==
Teleoperate a roving robot from the web:
http://www.swampgas.com/robotics/rover.html
Nikki Casali
16F872. But I hope I'm wrong! Which IS the smallest reprogrammable
device that does I2C natively?
Nikki
Brill Pappin
poling can be relaxed, and only step up to working speed when you detect a
start condition (the SDA going low).
even better would be to interrupt on the SDA going low and step up speed
then.
- Brill Pappin
"Nikki Casali" <epoch...@SPlwcdialAM.net> wrote in message
news:3D835505...@SPlwcdialAM.net...
Nikki Casali
The only problem I have is that although I'm programming a 16F628, the
target MCU is a measly 16C505 running at 4Mhz. No interrupts. I have to
poll all the time because I need to achieve at least 57Khz in I2C. I
miss a start condition if I don't go flat out. It's OK for my particular
application because the MCU doesn't need to do anything until it
receives data.
In my next application, I think I will be using a 16F628 to drive one
stepper and one servo, via I2C, for a pan and tilt camera system.
Interrupts and 20Mhz will be very helpful indeed!
Regards,
Nikki
Guillaume
>
> The 16F628 will do synchronous communications via its USART nicely -- the
> 9-bit addressing mode is a big plus --, but I2C is a different beast
> electrically. I don't think you'll be able to do this using the USART.
There
> are, however, lots of ways to do it in software, and probably a good bit
of
> code floating around out there. The 16F87X parts, on the other hand,
support
> hardware I2C very well -- Master, Slave and Multi-Master Mode (although I
> haven't done the latter).
That's right... I might actually not go the I2C way, but use more simple
synchronous serial communication (unless it raises a big interest out
there).
I'm thinking of providing either synchronous or asynchronous communication
(depending on a compilation macro in my source code).
I could also make a second, chunkier version of my controller, based on a
16F877 for instance, and offering: I2C slave communication, 16 servos
outputs, more sophisticated control options, and why not USB too
(using for instance the USBMOD2 module which works a treat).
Any suggestions appreciated.
stardu...@webtv.net
Kevin Dooley
communications. Here's a page of info about it, if you're interested:
http://www.semiconductors.philips.com/buses/i2c/facts/
K
<stardu...@webtv.net> wrote in message
news:457-3D84...@storefull-2317.public.lawson.webtv.net...
The Artist Formerly Known As Kap'n Salty
> That's right... I might actually not go the I2C way, but use more simple
> synchronous serial communication (unless it raises a big interest out
> there).
> I'm thinking of providing either synchronous or asynchronous communication
> (depending on a compilation macro in my source code).
>
about any host can talk to your controller and using only a single pin for
I/O. If you are returning data to the host, then you can use a second wire,
but consider making it optional. After all, this is servo control we're
talking about -- you really don't need the high speeds attainable with sync
serial, and you can save on the IO lines required by the host to talk to
your controller.
Cheers -- tafKaks
simon
If you do get an I2C version going have a look at
www.i2cchip.com
and drop me a line so I can add a note about it.
-16F818/9 will be available "soon" microchip time, w/I2C slave.
-16F630/676 are also coming and are 14 pin 14bit devices. Probably the
16C505 won't retain much of a price edge if any.
The new flash parts will probably be in smaller geometries, and the
eprom parts won't die shrink in future, so they will just get dearer
Nikki Casali <epoch...@SPlwcdialAM.net> wrote in message news:<3D83F6AE...@SPlwcdialAM.net>...
Nikki Casali
simon wrote:
> Nick,
> If you do get an I2C version going have a look at
> www.i2cchip.com
> and drop me a line so I can add a note about it.
For which PIC, the 16C505 or 16F628?
For a 1us instruction cycle, I've had to unravel a lot of loops and do a
lot of hard-coding. It's an I2C subset.
In software, with a 10Mhz crystal, 100Khz I2C will easily be obtainable
for both read and write.
>
> -16F818/9 will be available "soon" microchip time, w/I2C slave.
>
Ahh, that explains why I couldn't find any of these being sold on planet
Earth. At first, I was licking my lips when I saw the specs at Microchip.
Regards,
Nikki