Searching \ for '[PIC] PIC-Friendly "serial expansion bus"' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'PIC-Friendly "serial expansion bus"'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC-Friendly "serial expansion bus"'
2008\08\17@195317 by Forrest W Christian

flavicon
face
I'm working on selecting a "expansion bus" for a PIC project I'm working
on.   In short, the architecture is that I'll have a master controller
which will need to poll several slave modules.

Characteristics which are requirements are:

1) Cheap.

2) Two-way communication and messaging.   Think digital and analog I/O.

3) Implementable using PIC's on both the master and slave side.  A PIC
implementation should not require any external logic to the PIC.

4) Daisy-chainable architecture.   This means either bus or in/out
architectures are acceptable.   Star architectures are not.   Note this
kills SPI, since \CS is a problem in this regard.

5) Slaves should be able to be detected by the master, and should not
have to have addresses set via dip-switches or other means.   Globally
(factory set) unique addresses are ok (aka 1-wire style), dip-switches
are not (aka i2c is not an option).

6) Very low pin count.   Lower the better.   Like 2-3 or fewer, not
counting Vss.

Some additional preferred characteristics:

1) Bit-bangable is preferred.   Bit-bangable without lots of nasty
timing issues is even better.  In fact, I almost added bit-bangable to
the requirements, since it is pretty common for me to have both the MSSP
and the EUSART tied up - although if I had to choose required hardware
I'd say the EUSART would be less likely to be used.

2) Easily implementable or libraries are available for C18.

I keep coming back to 1-wire, but I really don't like the looks of how
big of a pain it is to implement and some of the nasty timing requirements.

I have also been thinking about a multidrop or "ring" async.   That is,
either connecting the tx of one unit to the rx of the next one and so on
back to the start - or tying tx (through a fet and pullup resistor) and
rx together on all of the units, and do it that way...  but I really
don't like bit-banging serial data.

In short, I haven't found the perfect solution yet...   Ideas?

-forrest

2008\08\17@202842 by John Coppens

flavicon
face
On Sun, 17 Aug 2008 17:52:40 -0600
Forrest W Christian <spam_OUTforrestcTakeThisOuTspamimach.com> wrote:

> In short, I haven't found the perfect solution yet...   Ideas?

Maybe combine spi and i2c? Have a dataline that runs around, ring-style,
but instead of clocking with a fixed (serial-style) clock, which the
peripherals could hold low to 'brake' the master.

This would mean 3 lines on each device: In/Out/Clk.

John

2008\08\17@204503 by Harold Hallikainen

face
flavicon
face
I've done an open collector UART based bus with multiple devices. There's
a pull-up resistor on the bus. UART RX pins tie directly to the bus.
Transmit pins have a diode to the bus with the cathode at the TX pin so
the TX pin can pull the bus down. Design a packet protocol that includes
to and from addresses, length, and CRC. On identifying new units, all
units could have a unique ID (serial number) of whatever length is
appropriate (16 or more bits, perhaps). Any device newly powered up sends
a packet announcing its ID. It does this again every minute or so unless
it has heard from the master. The master can poll all devices as often as
necessary, resetting the timer that triggers the ID announce.

This open collector bus can also be run in an Aloha network mode where
remote devices just send their data now and then, occasionally colliding.
You send enough data so an occasional loss is tolerable. I did this in an
electric car battery monitor. Each battery had its own monitor that drove
an opto coupler to the open collector bus.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\08\17@211208 by John Day

flavicon
face
At 07:52 PM 8/17/2008, Forrest W Christian wrote:
>5) Slaves should be able to be detected by the master, and should not
>have to have addresses set via dip-switches or other means.   Globally
>(factory set) unique addresses are ok (aka 1-wire style), dip-switches
>are not (aka i2c is not an option).

Nothing that you have said actually rules out I2C. If you use the
'general call' address, you can discover the devices on the bus and
then dynamically assign an I2C address. In reality it depends almost
entirely on how dynamic you little network is, if it is highly
dynamic then this may result in a slow start-up each time.

But if a slave in that network (so it needs to know which network it
is in at any given time) stores the assigned address and your address
mechanism discovers all of the identified devices first, then any new
devices can be given otherwise unused ID's.

Not being a PIC-head I can't really comment on implementation, but
I2C can be bit banged pretty easily and apart from actual I2C devices
which require a hard configured address, there are a vast array of
cable drivers, extenders and speed-up devices out there.

John

2008\08\18@044852 by Alan B. Pearce

face picon face
>>5) Slaves should be able to be detected by the master, and should not
>>have to have addresses set via dip-switches or other means.   Globally
>>(factory set) unique addresses are ok (aka 1-wire style), dip-switches
>>are not (aka i2c is not an option).
>
>Nothing that you have said actually rules out I2C. If you use the
>'general call' address, you can discover the devices on the bus and
>then dynamically assign an I2C address. In reality it depends almost
>entirely on how dynamic you little network is, if it is highly
>dynamic then this may result in a slow start-up each time.

That is my reaction also. You don't say how these devices are connected into
the network, are they in a card cage, separate devices connected by cables,
some other scheme? None of this removes the possibility of having an
appropriate number of pins on the connection plug that sets the device
address for that node, which gets around your dislike of dip switches.

The other possibility I thought of would be the CAN bus, which has a rather
different way of setting who receives what, but does have limited message
length, which requires a bit of thinking about to send long messages.

2008\08\18@054825 by Xiaofan Chen

face picon face
On Mon, Aug 18, 2008 at 7:52 AM, Forrest W Christian <.....forrestcKILLspamspam@spam@imach.com> wrote:
>
> In short, I haven't found the perfect solution yet...   Ideas?

CAN? Some CAN controllers are really quite cheap. Maybe Microchip's
CAN controllers are a bit more expensive and it is said that C18's built-in
CAN implementation is of demo quality only).

Xiaofan

2008\08\18@054938 by Xiaofan Chen

face picon face
On Mon, Aug 18, 2008 at 4:48 PM, Alan B. Pearce <A.B.PearcespamKILLspamrl.ac.uk> wrote:
>
> The other possibility I thought of would be the CAN bus, which has a rather
> different way of setting who receives what, but does have limited message
> length, which requires a bit of thinking about to send long messages.
>

8 Bytes not enough for the OP? And there are fragmentation protocols
for CAN.

Xiaofan

2008\08\18@060721 by Forrest W Christian

flavicon
face
To address both items at once:

My past experience with I2C is rather old... and pretty much limited to
the port-expander and ADC/DAC hardware.  That experience pretty much got
me thinking along the lines of each device has a hardwired address and
there isn't much flexibility on most parts as to what addresses are
available to you.   I've now corrected my thinking in that regards...

As far as how these are connected together...  These are devices which
are intended to be din-rail (or wall) mounted right next to each other
with a short, but pin-limited jumper cable between them.  I'm also
providing power and ground via that jumper.   I figure the jumper will
likely be a 6p6c or a 8p8c connector.  Right now, I'm toying with the
idea of using power, ground, and data on a multidrop serial bus, and
assigning each device a globally-unique serial number at manufacture
time so that the probed order can be preserved from run to run.  The
3-wire bus will let me use a 6p6c, but double up each pin so that I can
use either "reversed" or "straight" 6p6c jumpers.

That said, I'm still open to ideas..

-forrest

Alan B. Pearce wrote:
{Quote hidden}

2008\08\18@061753 by Alan B. Pearce

face picon face
>8 Bytes not enough for the OP?

Well, he doesn't say how big a message he needs ...

>And there are fragmentation protocols for CAN.

I know it is possible to send large messages, we do it on a satellite
instrument, it is 'just' a case of sorting out a suitable protocol for the
bus.

2008\08\18@071423 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam.....mit.edu [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu] On
Behalf
> Of John Day
> Sent: 18 August 2008 02:12
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] PIC-Friendly "serial expansion bus"
>
> At 07:52 PM 8/17/2008, Forrest W Christian wrote:
> >5) Slaves should be able to be detected by the master, and should not
> >have to have addresses set via dip-switches or other means.
Globally
> >(factory set) unique addresses are ok (aka 1-wire style),
dip-switches
> >are not (aka i2c is not an option).
>
> Nothing that you have said actually rules out I2C. If you use the
> 'general call' address, you can discover the devices on the bus and
> then dynamically assign an I2C address. In reality it depends almost
> entirely on how dynamic you little network is, if it is highly
> dynamic then this may result in a slow start-up each time.

One thing that would tend to make it undesirable IMO is the complexity
of implementing a slave in software, especially if you want it to work
at reasonable speeds.  If the SSP/MSSP is available on the slave devices
then it's not a problem, but having the heardware available on the
slaves is less likely than on the master IMO.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\08\18@072812 by olin piclist

face picon face
Forrest W Christian wrote:
> I'm working on selecting a "expansion bus" for a PIC project I'm
> working on.

I don't think there is anything that meets all your requirements.

You also failed to separate what you want it to accomplish from how you
imagine it will accomplish it.  The latter doesn't belong in a spec.  If you
specify the former correctly, then you will, by definition, be happy with
anything that meets it, no matter how that is accomplished.  A spec like
must be big bangable is silly, since that is not a end in itself.  And of
course "easily implementable" is no spec at all.

You left out some important and obvious requirements, like speed, bus
length, whether it will go outside the box or not, and the kind of external
noise it must tolerate.  All in all, you need to go back and figure out your
real spec.  You're not ready for answers to your spec yet since you don't
have a spec.

All that aside, CAN sounds like it meets most of your needs.  It is built
into many PICs, but does require a separate small tranceiver chip at each
node.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\08\18@102905 by Bob Axtell

face picon face
You didn't indicate what speed you needed.

I have had good luck with Manchester coding. It is almost completely
insensitive to timing
differences, so I use it between RC-timed PICs or RC-timed PICs and
crystal-controlled PICs.

Normally I have an OUT and an IN channel seperately, so two pins are
needed. A MASTER sends a command, and the correct slave answers. But
max the speed is about 1K BPS.

--Bob

On Sun, Aug 17, 2008 at 4:52 PM, Forrest W Christian <forrestcspamspam_OUTimach.com> wrote:
{Quote hidden}

> -

2008\08\18@145751 by peter

picon face
Harold Hallikainen <harold <at> hallikainen.org> writes:

> I've done an open collector UART based bus with multiple devices. There's
> a pull-up resistor on the bus. UART RX pins tie directly to the bus.

That works well and is not limited to pics. 8051s also work with such a bus. It
can also be debugged and controlled from a PC. I have also used such a bus in
the past. The only problem is the requirement for a stable clock, which excludes
RC parts. A solution is the Dallas 1-wire bus which is self clocked.

Peter


2008\08\18@164416 by Harold Hallikainen

face
flavicon
face

> Harold Hallikainen <harold <at> hallikainen.org> writes:
>
>> I've done an open collector UART based bus with multiple devices.
>> There's
>> a pull-up resistor on the bus. UART RX pins tie directly to the bus.
>
> That works well and is not limited to pics. 8051s also work with such a
> bus. It
> can also be debugged and controlled from a PC. I have also used such a bus
> in
> the past. The only problem is the requirement for a stable clock, which
> excludes
> RC parts. A solution is the Dallas 1-wire bus which is self clocked.
>
> Peter
>

I think the new PICs with internal RC are stable enough for this
application unless you are doing a very wide temperature range.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\08\19@003422 by Forrest Christian

flavicon
face
Olin Lathrop wrote:
> You left out some important and obvious requirements, like speed, bus
> length, whether it will go outside the box or not, and the kind of external
> noise it must tolerate.  All in all, you need to go back and figure out your
> real spec.  You're not ready for answers to your spec yet since you don't
> have a spec.
>  
I *do* have a spec, but it is pretty open at this point.   I admit that
I missed verbalizing a couple of key points - like distance and speed
(and to answer you, I really only need a few hundred bps, and I need an
end-to end bus length of a few feet, and although noise immunity is a
concern, I don't think I'm all that worried over a few foot bus running
at a few hundred bps.).

But, did you ever think I was perhaps *deliberately* vague about some
points so that I wouldn't put preconcieved notions in people's head?   I
was hoping for a wide variety of answers which would point me in some
directions I hadn't thought about - and the more detailed you write the
"spec" the fewer answers you get - which is exactly what I was trying to
avoid.

I really appreciate everyone that took the time to *think* about this
for at least a few seconds and respond, instead of just assuming that
the person asking the question was a clueless dolt and responding .   In
fact, almost every response other than Olin's was useful and helpful.  
I especially appreciate Harold's response, as I was kinda heading in
that direction already and his experience in doing so proved to validate
what I was thinking.   I'm also going to dig a bit more on a couple of
the other ideas as well (such as dig more into CAN and Manchester coding).

-forrest

2008\08\19@075244 by olin piclist

face picon face
Forrest Christian wrote:
> I *do* have a spec, but it is pretty open at this point.

That's a good one!

I'll remember that along with what two guys that were starting a PC fab
house told me a bunch of years ago: "We can do quality, just not
consistently.".  What makes it so funny is that they were serious.

> I really only need a few hundred bps, and I need
> an end-to end bus length of a few feet, and although noise immunity
> is a concern, I don't think I'm all that worried over a few foot bus
> running at a few hundred bps.

Ah, now we're getting somewhere.  This means some kind of passively pulled
up bus would work.  Some simple two wire clock and data scheme, perhaps.
That's basically what IIC is, but you don't have to use that exact protocol
if it's not convenient.  IIC is rather poor on noise immunity due to the
thresholds having to work with 3V logic.  Something using 5V logic with
Schmidt trigger inputs and stiffer pullups might help.  Since your data rate
is so low, bit banging in firmware is a serious option, especially if you
wire the clock line to a interrupt pin.

> But, did you ever think I was perhaps *deliberately* vague about some
> points so that I wouldn't put preconcieved notions in people's head?

No, I think you hadn't thought out your problem properly and now you're just
coming up with a excuse to save face.  You need to learn to separate
implementation from requirements.  This is one of the key traits that
separate good engineers from mediocre.  For example, telling people you need
a few 100 bits/second isn't telling them how to accomplish it, but it's
important information that opens up a range of possibilities that would not
be open if you needed 100Kbits/second.

> and the more detailed you write
> the "spec" the fewer answers you get

No, you still don't get it.  This is very basic engineering 101.  The spec
says what you need, not how to accomplish it.  Obviously you have
requirements at some level.  A spec is merely a way to describe these
requirements quantitatively.  If you are unsure, then pop up a level or two
until you do know what you need.

> I really appreciate everyone that took the time to *think* about this
> for at least a few seconds and respond, instead of just assuming that
> the person asking the question was a clueless dolt and responding .

Bad specs is a way to common problem, and shouldn't be allowed to go
unchallenged.  It's just as bad as wrong unit or no units at all, for
example.

> In fact, almost every response other than Olin's was useful and
> helpful.

Blame the messenger is you want.  I'm not sure what's worse, a bad spec or
people proposing implementations without knowing what the implementation
needs to accomplish.

Note that my guess of CAN as a possible solution sounds like a bad idea now
in light of additional information you finally provided.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\08\19@102053 by John Day

flavicon
face
At 04:48 AM 8/18/2008, you wrote:
> >>5) Slaves should be able to be detected by the master, and should not
> >>have to have addresses set via dip-switches or other means.   Globally
> >>(factory set) unique addresses are ok (aka 1-wire style), dip-switches
> >>are not (aka i2c is not an option).
> >
> >Nothing that you have said actually rules out I2C. If you use the
> >'general call' address, you can discover the devices on the bus and
> >then dynamically assign an I2C address. In reality it depends almost
> >entirely on how dynamic you little network is, if it is highly
> >dynamic then this may result in a slow start-up each time.
>
>That is my reaction also. You don't say how these devices are connected into
>the network, are they in a card cage, separate devices connected by cables,
>some other scheme? None of this removes the possibility of having an
>appropriate number of pins on the connection plug that sets the device
>address for that node, which gets around your dislike of dip switches.

When I use I2C it is usually with physically separate modules and
cables. My master controller of choice is the LEDuino ( maybe because
I designed it! ) http://www.siliconrailway.com we have adopted a
small low cost 4 pin connector as our interface.


>The other possibility I thought of would be the CAN bus, which has a rather
>different way of setting who receives what, but does have limited message
>length, which requires a bit of thinking about to send long messages.

Interesting you mention CAN. Yes, it is a possibility, but not
simple! Or even cheap. But Microchip do offer a wide variety of
controllers with CAN controllers. Others do as well, but the OP is
specifically interested in CAN. The code overhead is much higher, but
it is a more robust system commonly found in motor vehicles,
aeroplanes and industrial applications.

John


>

2008\08\19@102411 by John Day

flavicon
face
At 06:04 AM 8/18/2008, you wrote:
>To address both items at once:
>
>My past experience with I2C is rather old... and pretty much limited to
>the port-expander and ADC/DAC hardware.  That experience pretty much got
>me thinking along the lines of each device has a hardwired address and
>there isn't much flexibility on most parts as to what addresses are
>available to you.   I've now corrected my thinking in that regards...
>
>As far as how these are connected together...  These are devices which
>are intended to be din-rail (or wall) mounted right next to each other
>with a short, but pin-limited jumper cable between them.  I'm also
>providing power and ground via that jumper.   I figure the jumper will
>likely be a 6p6c or a 8p8c connector.

I2C has come a long way in recent years. One great change has been
the use of the basic I2C spec in a variety of other bus systems. For
lots of info and for details of a variety of buffer / extender
products see http://www.hendersonsemiconductor.com . They also offer
application notes talking about speed-up circuits and the other buses.

John


{Quote hidden}

>

2008\08\19@102725 by John Day

flavicon
face
At 07:13 AM 8/18/2008, you wrote:


{Quote hidden}

Maybe this is more of a PIC limitation than an I2C limitation! I
don't know about the Microchip range but in the Atmel products the 8
pin ATtiny25/45/85 have hardware I2C (master or slave).

Regards, John


{Quote hidden}

>

2008\08\19@112038 by Alan B. Pearce

face picon face
>> > Nothing that you have said actually rules out I2C. If you use the
>> > 'general call' address, you can discover the devices on the bus and
>> > then dynamically assign an I2C address. In reality it depends almost
>> > entirely on how dynamic you little network is, if it is highly
>> > dynamic then this may result in a slow start-up each time.
>>
>>One thing that would tend to make it undesirable IMO is the complexity
>>of implementing a slave in software, especially if you want it to work
>>at reasonable speeds.  If the SSP/MSSP is available on the slave devices
>>then it's not a problem, but having the heardware available on the
>>slaves is less likely than on the master IMO.
>
>Maybe this is more of a PIC limitation than an I2C limitation! I
>don't know about the Microchip range but in the Atmel products the 8
>pin ATtiny25/45/85 have hardware I2C (master or slave).

I have used both master and slave on a PIC 16F using the code in AN734 and
AN735. I converted both to interrupt driven code, and they worked fine for
my application. For the OPs application I would look at using the same code
again.

The only hiccup I see with I2C is his desire to not have to set the address
using DIP switches, and using minimal pin connectors. If able to set an
address in EEPROM on each device then it shouldn't be a problem.

2008\08\19@120824 by BlissWorld

flavicon
face

Hi,

There's a new protocol made by Microchip called UNI/O that makes use of
manchester coding. It's specified as 10 to 100kbps. It uses only one wire.
They made it for use with their cheap low pin count baseline 10F, 12F mcu's
but I think it can be used anywhere. Also cool little things are their new
UNI/O 3-pin SOT-23 (!) serial EEPROMs.

Some documentation:
General:  http://www.microchip.com/unio http://www.microchip.com/unio
Implementations for mcu's:
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2542&param=en533105
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2542&param=en533105
Bus spec:  ww1.microchip.com/downloads/en/DeviceDoc/DS-22076B.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/DS-22076B.pdf

Maybe it's just suitable for your application.
--
View this message in context: www.nabble.com/PIC-Friendly-%22serial-expansion-bus%22-tp19024498p19048267.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2008\08\19@141048 by peter green

flavicon
face

> The only hiccup I see with I2C is his desire to not have to set the address
> using DIP switches, and using minimal pin connectors. If able to set an
> address in EEPROM on each device then it shouldn't be a problem.
>  
The other big problem with I2C is it is a PITA to do in software and
doing it in hardware ties up the MSSP which depending
on what the slave is doing may be needed for other functions.

There are pics with multiple MSSP devices but they tend to have other
downsides like high pin count fine pitch packages.

The USART OTOH is in my experiance mostly used for hooking up a PC and
the USART based open collector bus system still allows you to easilly do
that.



2008\08\19@142738 by olin piclist

face picon face
peter green wrote:
> The other big problem with I2C is it is a PITA to do in software ...

I don't know why you say that.  IIC is all synchronous and is not complex.
I've done it a number of times where there wasn't a MSSP or I was already
using it for something else.  The only issue is the slave has to respond at
the speed of the master.  That means there are speed issues with a software
slave implementation, but that doesn't make it difficult.  Doing a IIC
master is about as easy as really very easy.  Have you looked closely at the
protocol?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\08\19@144850 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [spamBeGonepiclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of Olin Lathrop
> Sent: 19 August 2008 19:30
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] PIC-Friendly "serial expansion bus"
>
> peter green wrote:
> > The other big problem with I2C is it is a PITA to do in software ...
>
> I don't know why you say that.  IIC is all synchronous and is not
complex.
> I've done it a number of times where there wasn't a MSSP or I was
already
> using it for something else.  The only issue is the slave has to
respond
> at
> the speed of the master.  That means there are speed issues with a
> software
> slave implementation, but that doesn't make it difficult.  Doing a IIC
> master is about as easy as really very easy.  Have you looked closely
at
> the
> protocol?

I suspect Peter was referring to the slave implementation.  Now we know
the OP requires only a couple of 100 bps, a software I2C slave becomes
more practical.  Supporting 100kbit/s on a bit bashed slave tends to hog
up an awful lot of CPU cycles.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\08\19@145006 by John Temples

flavicon
face
On Tue, 19 Aug 2008, peter green wrote:

> There are pics with multiple MSSP devices but they tend to have other
> downsides like high pin count fine pitch packages.

The PIC24FJ64GA004 family has two I2C ports, two SPI ports, and two
UARTs.  These are six independent ports; I2C and SPI are not
multiplexed as they are in the PIC16/18 families.  Some parts in this
family are available in a 28-pin DIP package.

--
John W. Temples, III

2008\08\19@155453 by Matthew Miller

flavicon
face
On Mon, Aug 18, 2008 at 01:30:59PM -0700, Harold Hallikainen wrote:
>
>
> I think the new PICs with internal RC are stable enough for this
> application unless you are doing a very wide temperature range.

That's right! At room temperature USART communication works fine, but if
your device is a bit warm then comm fails. This is my experience with the
16F690. I used the chip as part of a data logger and would have to bring the
device inside and once it was at room temp then it worked fine. Not too big
a problem though...

Matthew

2008\08\20@035541 by Alan B. Pearce

face picon face
>> The only hiccup I see with I2C is his desire to not have to set the
>> address
>> using DIP switches, and using minimal pin connectors. If able to set an
>> address in EEPROM on each device then it shouldn't be a problem.
>>
>The other big problem with I2C is it is a PITA to do in software and
>doing it in hardware ties up the MSSP which depending
>on what the slave is doing may be needed for other functions.
>
>There are pics with multiple MSSP devices but they tend to have other
>downsides like high pin count fine pitch packages.
>
>The USART OTOH is in my experiance mostly used for hooking up a PC and
>the USART based open collector bus system still allows you to easilly do
>that.

OK, I guess using the 9 bit mode or LIN mode that some PICs have might be
the way to go then.

2008\08\20@104151 by alan smith

picon face



--- On Tue, 8/19/08, John Day <TakeThisOuTjohn.dayEraseMEspamspam_OUTsiliconrailway.com> wrote:

> From: John Day <RemoveMEjohn.dayspamTakeThisOuTsiliconrailway.com>
> Subject: RE: [PIC] PIC-Friendly "serial expansion bus"
> To: "Microcontroller discussion list - Public." <piclistEraseMEspam.....mit.edu>
> Date: Tuesday, August 19, 2008, 7:26 AM
> At 07:13 AM 8/18/2008, you wrote:
>
>
> > > {Original Message removed}

2008\08\21@174548 by cdb

flavicon
face
Would using the DMX protocol be of any use here? Relatively easy to
bit bang, and with some judicious coding, the different channels could  
be made to 'self address'  a new node.

By that I mean, the chips at the node could be programmed to accept
channel 1 (a sort of broadcast channel), the node chip would read it
itself discover it has a non assigned node number, accepts the address
information contained in the broadcast, updates itself, so that a
channel 1 address won't activate it again, but the new real node
channel now will.  Some fancy mechanism could be thunked up, to
persuade a node to respond to channel 1 again if re-addressing became
necessary. The drawback here would be that nodes could only be brought
online one at a time. Other than that there are 511 channels worth of
slaves to be had.

Colin
--
cdb, EraseMEcolinspambtech-online.co.uk on 22/08/2008

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2008\08\21@191607 by Harold Hallikainen

face
flavicon
face

> Would using the DMX protocol be of any use here? Relatively easy to
> bit bang, and with some judicious coding, the different channels could
> be made to 'self address'  a new node.
>
> By that I mean, the chips at the node could be programmed to accept
> channel 1 (a sort of broadcast channel), the node chip would read it
> itself discover it has a non assigned node number, accepts the address
> information contained in the broadcast, updates itself, so that a
> channel 1 address won't activate it again, but the new real node
> channel now will.  Some fancy mechanism could be thunked up, to
> persuade a node to respond to channel 1 again if re-addressing became
> necessary. The drawback here would be that nodes could only be brought
> online one at a time. Other than that there are 511 channels worth of
> slaves to be had.
>
> Colin


DMX now has Remote Device Management, which includes a discovery mode to
find devices on the network. It runs at 250kbps over EIA485. I did a lot
with DMX for about 15 years, but never implemented RDM. I think it's a bit
fancier than is required here. The use of the break as a start of frame
marker in DMX is useful though. I ended doing the break in hardware. When
I was doing DMX, the UARTs in PICs could not do a break. Those that can do
it will not do a long enough break to meet the DMX spec. It's more
designed for LIN.

Harold




--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\08\22@001509 by M. Adam Davis

face picon face
On Thu, Aug 21, 2008 at 7:15 PM, Harold Hallikainen
<RemoveMEharoldEraseMEspamEraseMEhallikainen.org> wrote:
> I ended doing the break in hardware. When
> I was doing DMX, the UARTs in PICs could not do a break. Those that can do
> it will not do a long enough break to meet the DMX spec. It's more
> designed for LIN.

If you set the bitrate to 100kbps and send the byte 0x00 you'll get a
90uS 'break' on the line (the spec calls for 88uS, but longer is ok
with the earlier spec).  Alternately you can just set the port output
appropriately (switch from the uart for 90uS, then switch back with
the output and data register preset - need only change the peripheral
usage).

Detecting a break is simply detecting two framing errors in a row.

Of course, there are other unusual factors that may require a
different solution, but these are the common PIC DMX generation and
detection methods.

-Adam

--
EARTH DAY 2008
Tuesday April 22
Save Money * Save Oil * Save Lives * Save the Planet
http://www.driveslowly.org

2008\08\22@010907 by David Cary

face picon face
Dear Forrest W Christian,

I've been playing with a few communication physical layers that seem
similar to what you're looking for:
* 5-wire daisy-chain SPI
* 5-wire "completely asynchronous, speed independent"
* 2-wire power + data (and optional gyrators)

Is there a wiki somewhere that discusses developing new communication protocols?
Should I publish my list of "22 common communication pitfalls"?

== 5-wire daisy-chain SPI ==

I am currently using some chips that use "daisy-chain SPI" (is there a
better name for this?).
It sounds very similar to some of the ideas you suggested.
I think JTAG also uses "daisy-chain SPI".
The data tx of each unit is connected to the data rx of the next unit
in a big ring, just as you suggested.
Unlike the "independent-select SPI", the "daisy-chain SPI" does *not*
require the master to generate an independent chip-select for each
slave.
No matter how many slaves there are, the master controls them with 3
output pins and 1 input pin.
Also, each daisy-chain SPI slave has 3 input pins and 1 output pin.

Such an interface also does *not* require any dip-switches or unique
addresses -- every slave can be identical, and yet the master can
still tell which slave generated which message and send each slave its
own commands (by the hop distance along the daisy-chain).

Assuming the slaves are close enough to the master that you only need
a single conductor for each signal (rather than a twisted pair),
each cable from one device to the next carries the global signals
* +power
* -power
* clock
* frame
and the local signal
* data bit.
... also, the "out" cable from the last slave on the chain is
connected to the master, making a big ring.
That's 5 out of the 6 pins available on the 6p6c cable.

The timing requirements for daisy-chained SPI are pretty simple,
making it fairly easy to bit-bang.
(However, later I describe a different protocol that has no timing
requirements at all).

Also, if all the PICs are running at the same voltage (all at 5.0 V or
all at 3.0 V), you can connect the PICs pin-to-pin without any other
hardware.
(But I would throw in at least a resistor between the 2 PICs, because
all too often bugs in my software cause pins that should be inputs
sensing a signal to instead be outputs fighting over the signal).

It sounds like you more-or-less independently re-invented this idea,
eliminating the "frame" signal by adding software complexity (now each
slave needs a unique address), and eliminating the "clock" signal by
adding stricter timing requirements.

> Date: 17 Aug 2008
> From: Forrest W Christian
...
> 1) Cheap.
...
> 2) Two-way communication and messaging.
...
> 3) Implementable using PIC's on both the master and slave side.  A PIC
> implementation should not require any external logic to the PIC.
>
> 4) Daisy-chainable architecture.
...
> 5) Slaves should be able to be detected by the master
...
> (factory set) unique addresses are ok (aka 1-wire style), dip-switches
> are not
...
> 6) Very low pin count.
...
> 1) Bit-bangable is preferred.   Bit-bangable without lots of nasty
> timing issues is even better.
...
{Quote hidden}

== 5-wire "completely asynchronous, speed independent" ==

SPI and IIC are easy to bit-bang on the master.
But a SPI or IIC slave has some timing requirements that, at higher
bitrates, can be a bit tricky to bit-bang.

I *think* it is possible to design a protocol that has no timing
requirements at all, even on the slaves.

> Date: 17 Aug 2008
> From: John Coppens
...
> Maybe combine spi and i2c? Have a dataline that runs around, ring-style,
> but instead of clocking with a fixed (serial-style) clock, which the
> peripherals could hold low to 'brake' the master.

That sounds like a good idea.
But how do you guarantee that the slave is fast enough to notice that
the master has pulled the clock pin down, and quickly also drive the
clock pin down before the master lets it back up?

In order to relax the timing requirements even more (to make it even
easier to bit-bang), I've been thinking about a protocol that is
completely timing-independent.
No matter how fast or slow 2 devices are, they can still communicate
(at a rate limited by the slower device).

Even if one of the devices is distracted halfway through a bit, and
thinks about something else for a few seconds, the protocol can still
resume as if nothing had happened.

Something like this:
Initially, all lines are floating high (open-collector pull-up).
To transmit a "1" bit, the left device pulls down the "T1" line and
lets the "T0" line continue to float high.
Eventually, the right device realizes that a "1" is being transmitted,
and pulls down the "T0" line in response.
Eventually, the left device realizes the bit has been received, and
lets the lines float high again (for faster speed, OK to drive the T1
line high).
Eventually, the right device realizes that the "1" bit is no longer
being transmitted, and lets the lines float high again.

Transmitting a "0" bit is similar, except the left device pulls down
the "T0" line first, the right device pulls down "T1", and then they
relax.
(This is similar to, but not quite the same as, the "dual-rail
encoding" used in some "completely asynchronous, speed independent"
CPUs).

Assuming the slaves are close enough to the master that you only need
a single conductor for each signal (rather than a twisted pair),
each cable from one device to the next carries the global signals
* +power
* -power
* frame
and the local signals
* T0
* T1
(If every slave has a unique serial number, you could dispense with
the global frame signal).

If all the PICs are running at the same voltage (all at 5.0 V or all
at 3.0 V), you can connect the PICs pin-to-pin with only a pull-up
resistor (I think I would one at each end of the cable).
(But I would throw in at least a resistor between the 2 PICs, because
all too often bugs in my software cause pins that should be inputs
sensing a signal to instead be outputs fighting over the signal).


> Date: 18 Aug 2008
> From: Forrest W Christian
...
> These are devices which
> are intended to be din-rail (or wall) mounted right next to each other
> with a short, but pin-limited jumper cable between them.  I'm also
> providing power and ground via that jumper.   I figure the jumper will
> likely be a 6p6c or a 8p8c connector.  Right now, I'm toying with the
> idea of using power, ground, and data on a multidrop serial bus, and
> assigning each device a globally-unique serial number at manufacture
> time so that the probed order can be preserved from run to run.
...

== 2-wire power + data (and optional gyrators) ==

> Date: 18 Aug 2008
> From: "Bob Axtell"
...
> I have had good luck with Manchester coding. It is almost completely
> insensitive to timing
> differences, so I use it between RC-timed PICs or RC-timed PICs and
> crystal-controlled PICs.
...

What I like most about Manchester coding is that I don't have to
manually set a baud rate.

It also has zero DC component, allowing it to easily pass through
coupling capacitors, which is convenient for another serial bus I've
been thinking about:

2 wires in the cable.
The 2 wires carry the data (in one direction).
The 2 wires *also* carry the power.

I'm still impressed that the telephone company engineers somehow
manage to get full-duplex simultaneous 2-way communication *and* power
over a single twisted pair.

This requires a bit more external hardware (a handful of inductors and
capacitors and resistors; also a analog comparator -- although some
PICs have a built-in analog comparator) than the above schemes, so
it's probably not appropriate for your application.
So I'll say no more about it here
(except to say that each inductor can optionally be replaced by
single-transistor gyrator).

Serial Peripheral Interface Bus : Daisy chain SPI configuration
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Daisy_chain_SPI_configuration

two PIC port pins "fighting" each other
http://massmind.org/techref/postbot.asp?by=time&id=piclist\1997\03\11\203507a&tgt=post&key=pins+fighting

Single transistor gyrator for telephony applications
http://www.epanorama.net/documents/telecom/gyrator.html

--
David Cary
http://carybros.com/
http://opencircuits.com/

2008\08\22@105606 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

Since I was simultaneously receiving DMX on the same UART, I could not
disable the UART or change the bit rate to send the break. I ended up
running the UART TX line through a resistor to the EIA485 transmitter. The
far side of the resistor was also connected to a PIC port pin that was
programmed low, but tristated. When I wanted to send a break, I'd set the
pin to output. When I wanted to end the break, I'd tristate the pin again.
Another interesting issue is synchronizing the break with the data. Since
the PIC uart on the 18 series will not generate an interrupt on the
transmit shift register being empty, it was difficult to generate the
break at the correct time. I ended up using a timer interrupt instead of
the UART interrupt. The timer interrupt would run a state machine that set
the break, cleared the break, or sent data. This is the technique I used
in the products I designed for http://www.dovesystems.com .

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\08\22@123310 by olin piclist

face picon face
> Detecting a break is simply detecting two framing errors in a row.

No, just one.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\08\23@031317 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Something like this:
| Initially, all lines are floating high (open-collector pull-up).
| To transmit a "1" bit, the left device pulls down the "T1" line and
| lets the "T0" line continue to float high.
| Eventually, the right device realizes that a "1" is being transmitted,
| and pulls down the "T0" line in response.
| Eventually, the left device realizes the bit has been received, and
| lets the lines float high again (for faster speed, OK to drive the T1
| line high).
| Eventually, the right device realizes that the "1" bit is no longer
| being transmitted, and lets the lines float high again.
|
| Transmitting a "0" bit is similar, except the left device pulls down
| the "T0" line first, the right device pulls down "T1", and then they
| relax.
| (This is similar to, but not quite the same as, the "dual-rail
| encoding" used in some "completely asynchronous, speed independent"
| CPUs).
This is actually very very similar to the idea behind the original
unidirectional transmission mechanism on the PC parallel port, only
you're going serial instead of parallel:
1. the PC sets the data lines and drives strobe
2. the printer sees strobe, reads the data, and drives acknowledge
3. the PC sees acknowledge and drops strobe
4. the printer sees strobe dropped and drops acknowledge
5. the PC sees acknowledge dropped and can proceed to the next byte.

At least, that's what I read. I looked at some code in the Linux
parallel port driver, and I'm not sure it actually implements all the
waiting properly.

I guess if you want higher speed, there's no reason why you couldn't
take a page out of ATA and drive a new data element on each edge of
strobe (rising and falling); in that case, "ack = strobe" means the
recipient has seen all the data so far, and "ack != strobe" means the
recipient hasn't received the most recent datum. This would save the
rather useless wait state of "let strobe go back to its idle state and
wait until the recipient notices that it's idle".

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkivuHMACgkQiD2svb/jCb4wKwCbBRO0gasAIwJ6l0KlQT5pX0BJ
ikgAnjGvxnHaOH6Sf8Xv+3brLlWPKJvg
=udqG
-----END PGP SIGNATURE-----

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...