Searching \ for '[PIC] I2C switching between master and slave confi' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/i2cs.htm?key=i2c
Search entire site for: 'I2C switching between master and slave confi'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] I2C switching between master and slave confi'
2009\04\06@105928 by Peter Onion

flavicon
face
I'm considering trying to use I2C for the first time.

I'll try something simple to start with (like reading and writing an
EEPROM), but then I need to move to multiple 18F PICs (a mix of 4520s
and 2420s) on a board which need to occasionally communicate with each
other.

None of them is running any particularly time critical applications but
I would prefer to avoid having one master which polls the others.

Are there any "gotchas" to having a PIC switching modes ?  Most of the
time they will be in slave mode waiting for messages and then sometimes
switching to master mode when they need to send to one of the others.
Will the multi-master clock arbitration still work ok ?  Is it OK to
have no masters while they are all idle ?

Pointers to any similar examples would be helpful.

PeterO



2009\04\06@112723 by olin piclist

face picon face
> Will the multi-master clock arbitration still work ok ?

Sortof.  I don't think IIC is defined such that you can guarantee no race
conditions.

> Is it OK to
> have no masters while they are all idle ?

Yes.  The bus lines just float high due to the passive pullups.

Maybe CAN would be a better choice.  It deals with multiple senders,
including collision detection and retry, right in the hardware.


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

2009\04\06@115155 by Tony Vandiver

flavicon
face
Hi Peter,

   If you're going to write your own protocol to support the
communication and there are loose time constraints, then maybe just
consider having one PIC that's always the master, and develop the
protocol to support communication between slaves via the master like the
master polls all devices to see if they have anything they want to
transmit, and if so, the master passes this data to a different slave.  
It's' not the most efficient method, but would guarantee that you didn't
have two masters on the bus at the same time.

Tony


Peter Onion wrote:
{Quote hidden}

2009\04\06@120418 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> > Will the multi-master clock arbitration still work ok ?
>
> Sortof.  I don't think IIC is defined such that you can guarantee no
> race conditions.
>
> > Is it OK to
> > have no masters while they are all idle ?
>
> Yes.  The bus lines just float high due to the passive pullups.
>
> Maybe CAN would be a better choice.  It deals with multiple senders,
> including collision detection and retry, right in the hardware.

Actually, multi-master I2C works much the same way as CAN, but hardware
support is required. I was recently looking into this relative to an FPGA
implementation of an I2C controller.

In addition to making sure the bus is idle before seizing the bus, an I2C
master in a multi-master configuration must monitor the bus while sending
data bits. If another master is sending a zero while you're trying to send
a one (collision), you detect this and immediately back off, allowing the
other master to complete its transaction. As with CAN, the master sending
zero "wins" the collision with no need to retry its transaction.

In order to do this correctly, all masters also need to be handling the
clock line correctly, allowing both slaves and other masters to do clock
stretching. If you've released the data line and it hasn't gone high by
the time the clock line goes high, then you just lost out on a collision.

Keeping this relevant to [PIC], I don't know whether any of the PIC I2C
hardware implementations fully support multi-master operation. You can
certainly do it as part of a bit-banged implementation if speed is not
too much of a concern.

-- Dave Tweed

2009\04\06@123927 by Peter Onion

flavicon
face
On Mon, 2009-04-06 at 12:04 -0400, Dave Tweed wrote:
{Quote hidden}

It's a pity you didn't point out that you don't actually know the answer
four paragraphs ago !  :-(

PeterO


2009\04\06@124404 by Peter Onion

flavicon
face
On Mon, 2009-04-06 at 11:29 -0400, Olin Lathrop wrote:
> > Will the multi-master clock arbitration still work ok ?
>
> Sortof.  I don't think IIC is defined such that you can guarantee no race
> conditions.
>
> > Is it OK to
> > have no masters while they are all idle ?
>
> Yes.  The bus lines just float high due to the passive pullups.

Well I've read a bit more of the MSSP manual now.  I stoped reading when
I got to the section on baud rate generation but there is more important
stuff after that !  (The draw back of reading manuals on screen is that
it is hard to "flick through" them ).

> Maybe CAN would be a better choice.  It deals with multiple senders,
> including collision detection and retry, right in the hardware.

Could be, but it looks even more complex (by an order of magnitude ?).
Anyway I have the first part of the project already running on a 4520 so
I'de like to get the I2C interface doing something useful (even if it
ends up only accessing the EERPOM).

PeterO



2009\04\06@130527 by olin piclist

face picon face
Peter Onion wrote:
{Quote hidden}

Dave was pointing out that it is possible to do multi-master IIC, which was
relevant to the discussion.  This narrows the question down to whether PICs
support this in hardware or not.  I think the answer is they don't, although
I haven't looked at the IIC implementation of some of the newer PICs at that
detail.

If you are willing to run your IIC bus at a slow enough speed, then it is
possible to do multi-master using all firmware, as Dave also mentioned.  The
bit time needs to be long enough so that a master trying to write a 1 can
see the bus is at 0 after a long enough delay so that it should have risen
by itself, but with enough time left in the bit for the master to bug off
and abort before the next bit starts.  These times also have to take into
account the masters being a few instructions out of sync in their loops.  It
gets even more tricky if the master that lost the contention could actually
be the intended receiver, since you want to use the IIC hardware in slave
mode.  There are ways around this, but you need to think it thru carefully.
My first knee jerk reaction is to use separate pins for the softare master
implementation than the hardware slave, and basically leave the hardware
slave on all the time.


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

2009\04\06@165957 by Barry Gershenfeld

picon face
>
> I'll try something simple to start with (like reading and writing an
> EEPROM),


Since you are new to this, you will find that just getting the ack from the
device to be the first challenge.  An EEPROM is not the simplest thing you
could try.  Most larger EEPROMs have two address registers, and you have to
break up the 16-bit address into two bytes before you send it.  On writes,
the chip goes away for a time and the "reappears" after it's ready.  And
then there's that page-writing feature that gets discussed here regularly.
Nonetheless, it's still probably close enough to simple for your purposes.


> Are there any "gotchas" to having a PIC switching modes ?


I think this has been mentioned, but at the time you are "turning the line
around", you risk missing something, or introducing a problem that only
happens occasionally.

If you are going to use clock stretching (and you probably will if you use a
uP-based slave), that will be a very nice challenge of its own.

So, one possible outcome is, that after reading all these replies,  you may
decide that polling ain't so bad after all.  This all is quite an adventure
for an i2c first-timer.

For the master/slave bit, I had some notion that the two would be active at
the same time. But not in the PIC hardware, it appears.

Then, Olin adds:

> My first knee jerk reaction is to use separate pins for the softare master
> implementation than the hardware slave, and basically leave the hardware
> slave on all the time.


Illustrating the likelihood that Olin's knees are still smarter than most of
our brains.

2009\04\07@034242 by Peter Onion

flavicon
face
On Mon, 2009-04-06 at 13:59 -0700, Barry Gershenfeld wrote:
> >
> > I'll try something simple to start with (like reading and writing an
> > EEPROM),
>
>
> Since you are new to this, you will find that just getting the ack from the
> device to be the first challenge.  An EEPROM is not the simplest thing you
> could try.

Oh well it sounds like I should give up now then,  oh,  hang on, wait a
minute,  I've already got the EEPROM read and write code working....

Oh well, never mind....

PeterO



2009\04\07@040011 by Alan B. Pearce

face picon face
>So, one possible outcome is, that after reading all these replies,
>you may decide that polling ain't so bad after all.  This all is
>quite an adventure for an i2c first-timer.

There is an alternative to polling, doing a token passing to determine who
is master. It will require each master to know the next address of who may
want to be a master in the system, to know who to pass the 'master' token
to, but that could be set up by a broadcast message from the 'master
master'.

This will save the overhead of one device doing all the polling. Each device
'just' needs to look for the message that passes the master token, and if it
doesn't require access to other devices, it passes the token on to the next
potential master.

2009\04\07@042033 by Alan B. Pearce

face picon face
>Oh well it sounds like I should give up now then,  oh,  hang on, wait a
>minute,  I've already got the EEPROM read and write code working....
>
>Oh well, never mind....

Yeah, I thought Barry was being a bit pessimistic ... ;))

I certainly found it easy enough to get code to deal with EEPROMS working,
starting from the Microchip app notes.

2009\04\07@061807 by Peter Onion

flavicon
face
On Tue, 2009-04-07 at 08:59 +0100, Alan B. Pearce wrote:
> >So, one possible outcome is, that after reading all these replies,
> >you may decide that polling ain't so bad after all.  This all is
> >quite an adventure for an i2c first-timer.
>
> There is an alternative to polling, doing a token passing to determine who
> is master. It will require each master to know the next address of who may
> want to be a master in the system, to know who to pass the 'master' token
> to, but that could be set up by a broadcast message from the 'master
> master'.

I hadn't thought of token passing, it might be useful if the collision
detection doesn't work well enough....

It will be a totally static system so "next address" can be hard coded
without a problem.  

> This will save the overhead of one device doing all the polling. Each device
> 'just' needs to look for the message that passes the master token, and if it
> doesn't require access to other devices, it passes the token on to the next
> potential master.

I shall think about this, but right now I have the simpler task of an
RS-232 interface to the host to implement.  

PeterO


2009\04\07@083053 by Wouter van Ooijen

face picon face
Alan B. Pearce wrote:
>> So, one possible outcome is, that after reading all these replies,
>> you may decide that polling ain't so bad after all.  This all is
>> quite an adventure for an i2c first-timer.
>
> There is an alternative to polling, doing a token passing to determine who
> is master. It will require each master to know the next address of who may
> want to be a master in the system, to know who to pass the 'master' token
> to, but that could be set up by a broadcast message from the 'master
> master'.
>
> This will save the overhead of one device doing all the polling. Each device
> 'just' needs to look for the message that passes the master token, and if it
> doesn't require access to other devices, it passes the token on to the next
> potential master.

The big question for token-passing protocols is: how do you recover from
situations where the number of tokens 'in play' is not equal to one?


--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\04\07@100251 by Alan B. Pearce

face picon face
>The big question for token-passing protocols is: how do you
>recover from situations where the number of tokens 'in play'
>is not equal to one?

<VBG> I think I would have the 'master master' always wait for close to a
timeout time after receiving a token before issuing it again, to prevent
having multiple tokens on the network. This way it could conceivably
'swallow' several tokens, if there are multiples, before issuing a new one.

The other trick with using I2C is you can monitor the network to see if
there is activity, and only timeout to issue a new token if there is no
activity.

2009\04\07@171655 by Barry Gershenfeld

picon face
>
> >Oh well it sounds like I should give up now then,  oh,  hang on, wait a
> >minute,  I've already got the EEPROM read and write code working....
> >
> >Oh well, never mind....
>
> Yeah, I thought Barry was being a bit pessimistic ... ;))
>

I guess I have just read too many discussions with folks who really have a
hard time with things like this.  A lot of them don't have the advantage of
a 'scope, either. Then there was the guy that worked here and "never could
get that 24LC128 to work".  Because of that extra address register.

Anyway, it's easy enough to guess wrong, when it's just a guess.  I'm glad I
was wrong this time.

2009\04\09@175523 by Gerhard Fiedler

picon face
Peter Onion wrote:

> On Mon, 2009-04-06 at 11:29 -0400, Olin Lathrop wrote:
>> Maybe CAN would be a better choice.  It deals with multiple senders,
>> including collision detection and retry, right in the hardware.
>
> Could be, but it looks even more complex (by an order of magnitude ?).

The CAN module is more complex to configure (many more registers), but
once you have them configured, it mostly "just works" -- especially if
you're not dealing with long distances. You have full hardware support
for collision detection, message verification, even addressing if you
want it, etc.

Gerhard

2009\04\10@033128 by Peter Onion

flavicon
face
On Thu, 2009-04-09 at 18:55 -0300, Gerhard Fiedler wrote:
> Peter Onion wrote:
>
> > On Mon, 2009-04-06 at 11:29 -0400, Olin Lathrop wrote:
> >> Maybe CAN would be a better choice.  It deals with multiple senders,
> >> including collision detection and retry, right in the hardware.
> >
> > Could be, but it looks even more complex (by an order of magnitude ?).
>
> The CAN module is more complex to configure (many more registers), but
> once you have them configured, it mostly "just works" -- especially if
> you're not dealing with long distances. You have full hardware support
> for collision detection, message verification, even addressing if you
> want it, etc.
>
> Gerhard

You've encouraged me to "take the CAN-challenge" so  I've ordered some
18F4580s and some MCP2551s to try out.

Expect some CAN-noob questions soon !

PeterO


2009\04\10@071749 by Jan-Erik Soderholm

face picon face
Peter Onion wrote:
{Quote hidden}

The thing I like with CAN is that it is "message-based"
instead of "adress-based" like I2C or SPI.

That is, if one node in the CAN-network transmittes
say a temperature, it doesn't send it to specific
addresses, it's up to the receivers to set up theirs
messages-filters *if* they are interested in the
temperature. So CAN-nodes doesn't realy know about
other *nodes*, they only knows about *messages*...

So you can replace the temp-sending node with other/new
hardware, and the temp-receivers will never see any
difference, as log as the message-ID for "temperature"
is still the same. Or you could have one node sending
two different temperatures (with different message-ID)
and split that into two nodes without any change in
the receivers. They have no idea if two different
message-IDs comes from the one node or from two
different nodes.

OK, one could say that the "message-ID" realy is an
address, but since one node can handle multiple
messages I think that sticking to message-ID is
clearer.

Jan-Erik.

2009\04\10@082647 by Gerhard Fiedler

picon face
Peter Onion wrote:

>> The CAN module is more complex to configure (many more registers),
>> but once you have them configured, it mostly "just works" --
>> especially if you're not dealing with long distances. You have full
>> hardware support for collision detection, message verification, even
>> addressing if you want it, etc.
>
> You've encouraged me to "take the CAN-challenge" so  I've ordered
> some 18F4580s and some MCP2551s to try out.

I've never done on-board CAN, but since you were talking about I2C, you
seem to be talking about very short distances, maybe on-board. In this
case, you may not need the MCP2551 (which provides one possible hardware
layer for CAN). The most important requirements for a CAN hardware layer
are that it provides the support for the collision detection and is fast
enough. On very short distances, wired-or can do this.

Gerhard

2009\04\10@082907 by VICENTE COLOMAR PRATS

picon face
I do not knew CAN was so easy and usefull. I'm actually working with I2C,
but sure give a try to this bus, thank to you.

2009/4/10 Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com>

{Quote hidden}

2009\04\10@091522 by Peter Onion

flavicon
face
On Fri, 2009-04-10 at 09:26 -0300, Gerhard Fiedler wrote:
> Peter Onion wrote:
>
> >> The CAN module is more complex to configure (many more registers),
> >> but once you have them configured, it mostly "just works" --
> >> especially if you're not dealing with long distances. You have full
> >> hardware support for collision detection, message verification, even
> >> addressing if you want it, etc.
> >
> > You've encouraged me to "take the CAN-challenge" so  I've ordered
> > some 18F4580s and some MCP2551s to try out.
>
> I've never done on-board CAN, but since you were talking about I2C, you
> seem to be talking about very short distances, maybe on-board.

Initially it will be all on-board, but later it would be nice to add
some comms between parts which are "on the same desk".



> In this
> case, you may not need the MCP2551 (which provides one possible hardware
> layer for CAN).

OK, I was surprised that there is no mention of the hardware layer in
the PIC manuals so I assumed you needed an external i/f chip.

>  The most important requirements for a CAN hardware layer
> are that it provides the support for the collision detection and is fast
> enough. On very short distances, wired-or can do this.
>
> Gerhard

Thanks,

PeterO


2009\04\10@143524 by Gerhard Fiedler

picon face
Peter Onion wrote:

> OK, I was surprised that there is no mention of the hardware layer in
> the PIC manuals so I assumed you needed an external i/f chip.

You need to provide /some/ hardware interface; in this you assumed
correctly.

CAN doesn't include a spec for the hardware layer. ISO 11898 includes
specs for a few hardware interfaces for CAN; the MCP2551 implements one
of them. But there are CAN implementations that use all kinds of
hardware interfaces.

Gerhard

2009\04\10@160832 by Vitaliy

flavicon
face
VICENTE COLOMAR PRATS wrote:
>I do not knew CAN was so easy and usefull. I'm actually working with I2C,
> but sure give a try to this bus, thank to you.

I2C hardware is cheaper, and there are far fewer things to configure.

Vitaliy

2009\04\10@173830 by Jan-Erik Soderholm

face picon face
Vitaliy wrote:
> VICENTE COLOMAR PRATS wrote:
>> I do not knew CAN was so easy and usefull. I'm actually working with I2C,
>> but sure give a try to this bus, thank to you.
>
> I2C hardware is cheaper, and there are far fewer things to configure.

Can't realy compare them like that.
CAN can be used over a distanse with the right hardware interface.
It's realy two different usage areas...


>
> Vitaliy

2009\04\10@195037 by Vitaliy

flavicon
face
Jan-Erik Soderholm wrote:
>> VICENTE COLOMAR PRATS wrote:
>>> I do not knew CAN was so easy and usefull. I'm actually working with
>>> I2C,
>>> but sure give a try to this bus, thank to you.
>>
>> I2C hardware is cheaper, and there are far fewer things to configure.
>
> Can't realy compare them like that.
> CAN can be used over a distanse with the right hardware interface.
> It's realy two different usage areas...

Well of course. But it sounded like Vicente wanted to adopt CAN for an
application where he's using I2C. Unless he has a good reason to switch, I'd
say "if it ain't broken..."

Vitaliy

2009\04\10@200335 by olin piclist

face picon face
Gerhard Fiedler wrote:
> CAN doesn't include a spec for the hardware layer.

The original Bosch spec certainly did.

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

2009\04\10@201204 by olin piclist

face picon face
Vitaliy wrote:
> Well of course. But it sounded like Vicente wanted to adopt CAN for an
> application where he's using I2C. Unless he has a good reason to
> switch, I'd say "if it ain't broken..."

I thought it wasn't working yet and he was struggling with IIC to do the
job, mostly because he wants multiple masters to equally and asynchronously
to be able to send on the bus.  This would take some work to implement with
IIC, but is built into all PIC CAN controllers.


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

2009\04\10@202452 by VICENTE COLOMAR PRATS

picon face
I use pics in my robotics hobby and I2C to communicate with displays or
other micros. Never tried CAN bus, but as people is speaking so good of it,
I will give a try as I have time to.

2009/4/11 Olin Lathrop <olin_piclistspamKILLspamembedinc.com>

> Vitaliy wrote:
> > Well of course. But it sounded like Vicente wanted to adopt CAN for an
> > application where he's using I2C. Unless he has a good reason to
> > switch, I'd say "if it ain't broken..."
>
> I thought it wasn't working yet and he was struggling with IIC to do the
> job, mostly because he wants multiple masters to equally and asynchronously
> to be able to send on the bus.  This would take some work to implement with
> IIC, but is built into all PIC CAN controllers.
>

2009\04\10@204316 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> Well of course. But it sounded like Vicente wanted to adopt CAN for an
>> application where he's using I2C. Unless he has a good reason to
>> switch, I'd say "if it ain't broken..."
>
> I thought it wasn't working yet and he was struggling with IIC to do the
> job, mostly because he wants multiple masters to equally and
> asynchronously
> to be able to send on the bus.  This would take some work to implement
> with
> IIC, but is built into all PIC CAN controllers.

Vicente is not the OP, unless he also goes by the name "Peter Onion".

Vitaliy

2009\04\16@183956 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> CAN doesn't include a spec for the hardware layer.
>
> The original Bosch spec certainly did.

Really? What do you call the "original Bosch spec"? Do you have a link
to or a copy of a Bosch CAN spec that defines the physical layer?

The Bosch spec I know (see
<http://www.semiconductors.bosch.de/pdf/can2spec.pdf> ) says that "the
scope of this specification is to define the transfer layer and the
consequences of the CAN protocol on the surrounding layers" -- and with
that specifically exclude the physical layer. They also write that
"there may be, however, much freedom in selecting a physical layer."
Also, on page 4 of part A of this document, they add "CAN" in
parentheses to the object and transfer layers, but not to the physical
layer, kind of implying that there is no CAN physical layer (as opposed
to the transfer layer, for example). They use similar wording in the
introduction of part B (page 34f).

Gerhard

2009\04\18@095541 by olin piclist

face picon face
Gerhard Fiedler wrote:
> Really? What do you call the "original Bosch spec"? Do you have a link
> to or a copy of a Bosch CAN spec that defines the physical layer?

I went back and looked at the Bosch spec from 1991 that I had in a notebook
and found the same thing you did.  However, I do remember reading about the
differential signalling, impedence of the twisted pair, etc.  After all,
these things still have to agree in any one implementation, and
semiconductor companies would not have invested in the development of chips
that connect directly to the physical link if there wasn't some kind of
agreement on what that should be.

My recollection is that I read the physical layer details in a Bosch
document somewhere over a decade ago, but I can't find that now so I could
be wrong.


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

2009\04\18@105800 by Xiaofan Chen

face picon face
On Fri, Apr 17, 2009 at 6:39 AM, Gerhard Fiedler
<.....listsKILLspamspam.....connectionbrazil.com> wrote:
> Really? What do you call the "original Bosch spec"? Do you have a link
> to or a copy of a Bosch CAN spec that defines the physical layer?
>
> The Bosch spec I know (see
> <http://www.semiconductors.bosch.de/pdf/can2spec.pdf> ) says that "the
> scope of this specification is to define the transfer layer and the
> consequences of the CAN protocol on the surrounding layers" -- and with
> that specifically exclude the physical layer. They also write that
> "there may be, however, much freedom in selecting a physical layer."
> Also, on page 4 of part A of this document, they add "CAN" in
> parentheses to the object and transfer layers, but not to the physical
> layer, kind of implying that there is no CAN physical layer (as opposed
> to the transfer layer, for example). They use similar wording in the
> introduction of part B (page 34f).
>

The Bosch CAN spec does mention some of the physical layer
aspect. If you read page 37, page 59 and some other pages,
you will know that.

Slightly updated (still obsolete) version can be downloaded here.
http://www.can-cia.org/index.php?id=441

They are replaced by ISO11898-1. Other CAN related standards
specify the physical layer in more detail.
http://www.can-cia.org/index.php?id=88

On top of CAN, there are higher level protocols like DeviceNet
which does specify the physical layer in details along with higher
layer protocols.

--
Xiaofan http://mcuee.blogspot.com

2009\04\18@113017 by olin piclist

face picon face
Xiaofan Chen wrote:
> On top of CAN, there are higher level protocols like DeviceNet
> which does specify the physical layer in details along with higher
> layer protocols.

Yes, NMEA 2000 goes so far as specifying the type and thickness of wire, and
maybe even the insulation thickness if I recall correctly (I may not).


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

2009\04\19@140458 by Peter Onion

flavicon
face
On Fri, 2009-04-10 at 08:31 +0100, Peter Onion wrote:

> You've encouraged me to "take the CAN-challenge" so  I've ordered some
> 18F4580s and some MCP2551s to try out.
>
> Expect some CAN-noob questions soon !
>
> PeterO

I got some 18F4580s last week, and I got around to putting one on a
board today.  I have to say that even by Microchips standards the
documentation on the ECAN module is awful !

I had to resorted to looking at the C code in AN738 to work out what has
to be done.

So far all I've managed to do to is send a 1 byte message via the
loopback, but even that feels like a major achievement !

PeterO


2009\04\19@192044 by olin piclist

face picon face
Peter Onion wrote:
> I got some 18F4580s last week, and I got around to putting one on a
> board today.  I have to say that even by Microchips standards the
> documentation on the ECAN module is awful !

I've got some 18F4580s on boards awaiting CAN code too.  I've read the
datasheet and thought it made a lot of sense.  I haven't tried writing
actual code yet, but it seems to make sense so far.  When you complain about
Microchip documentation, especially in broad terms, you are really indicting
yourself.  What specifically did you find confusing?


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

2009\04\19@193010 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

{Quote hidden}

I'm not sure we have the same understanding of "spec" here. On p. 37,
for example, they write "Within this specification the Driver/Receiver
Characteristics of the Physical Layer are not defined [...]". To me,
this sounds pretty much as if they did /not/ define the physical layer
:)

What they mention is what the physical layer must provide -- for
example, it must have a dominant and a recessive bit state for the
arbitration.

> They are replaced by ISO11898-1.

The other parts of the ISO 11898 standard define several different
implementations of the physical layer. But they are all just possible
options for a CAN physical layer. Differently from some other protocols,
the physical layer of CAN is not defined. There are a number of common
(somehow standardized) implementations, and all of them are CAN buses.
And if you roll your own (say a one-wire interface that allows you to
power the connected units), it's still a CAN bus.

Gerhard

2009\04\19@194038 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> My recollection is that I read the physical layer details in a Bosch
> document somewhere over a decade ago, but I can't find that now so I
> could be wrong.

Could this have been the ISO 11898-2 spec? This is the most common (but
not the only common) spec for an implementation of the physical layer
for a CAN bus.

Gerhard

2009\04\19@200406 by Xiaofan Chen

face picon face
On Mon, Apr 20, 2009 at 7:30 AM, Gerhard Fiedler
<EraseMElistsspam_OUTspamTakeThisOuTconnectionbrazil.com> wrote:

> I'm not sure we have the same understanding of "spec" here. On p. 37,
> for example, they write "Within this specification the Driver/Receiver
> Characteristics of the Physical Layer are not defined [...]". To me,
> this sounds pretty much as if they did /not/ define the physical layer
> :)
>
> What they mention is what the physical layer must provide -- for
> example, it must have a dominant and a recessive bit state for the
> arbitration.

NRZI, bit stuffing are part of the physical layer. The specification
defines the some parts of physical layer, but not all.

On the other hand, Bosch has too much control on the
CAN implementation, so I would say most of the
CAN IP ultimately comes from Bosch's IP and so the
actually implementation is more than the published
specification. The physically layer is still not fully defined though.

>> They are replaced by ISO11898-1.
>
> The other parts of the ISO 11898 standard define several different
> implementations of the physical layer. But they are all just possible
> options for a CAN physical layer. Differently from some other protocols,
> the physical layer of CAN is not defined. There are a number of common
> (somehow standardized) implementations, and all of them are CAN buses.
> And if you roll your own (say a one-wire interface that allows you to
> power the connected units), it's still a CAN bus.

Right. I've seen two CAN bus based I/O backplanes in my two jobs.
Still you need to use the common CAN controller and CAN transceiver
which fulfil the basic physical layer requirement of the CAN spec
and Bosch's other unstated requirement.

--
Xiaofan http://mcuee.blogspot.com

2009\04\20@120345 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

>> The other parts of the ISO 11898 standard define several different
>> implementations of the physical layer. But they are all just
>> possible options for a CAN physical layer. Differently from some
>> other protocols, the physical layer of CAN is not defined. There are
>> a number of common (somehow standardized) implementations, and all
>> of them are CAN buses. And if you roll your own (say a one-wire
>> interface that allows you to power the connected units), it's still
>> a CAN bus.
>
> Right. I've seen two CAN bus based I/O backplanes in my two jobs.
> Still you need to use the common CAN controller and CAN transceiver
> which fulfil the basic physical layer requirement of the CAN spec
> and Bosch's other unstated requirement.

I don't understand this. Why do you think that a CAN implementation that
doesn't use the standard ISO 11898-2 controllers wouldn't be CAN? Even
ISO 11898 defines a physical layer that is not compatible with the
common ISO 11898-2 controllers. There's also SAE J2411 and others, and
there's nothing that says I can't implement a one-wire interface for the
CAN bus that also provides supply to the devices. Or a simple wired-or
interface.

Gerhard

2009\04\20@141058 by VICENTE COLOMAR PRATS

picon face
I think the original post was about I2C, but now is going too much about
CAN, is it? May be shoud it go in different post?

2009\04\20@155528 by Peter Onion

flavicon
face
On Sun, 2009-04-19 at 19:20 -0400, Olin Lathrop wrote:
>   What specifically did you find confusing?

The lack of a simple "this is what you need to do to make it work"
example.  There are bits of (not very good) code scattered through the
whole section, and page after page of descriptions of registers.....

In the end it turns out to be quite simple, but you don't get that idea
from reading the description.

And there is no complete example in assembler in any of the application
notes that I could find.

I wish I had your giant brain so I could just scan the text and then
write optimal assembly code ;-)

PeterO



2009\04\20@161547 by olin piclist

face picon face
Peter Onion wrote:
>>   What specifically did you find confusing?
>
> The lack of a simple "this is what you need to do to make it work"
> example.

That's pretty hard for CAN since there are so many ways you could set it up.

> and page after page of descriptions of registers.....

Lots of options take lots of bits to chose them.


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

2009\04\20@192723 by Xiaofan Chen

face picon face
On Tue, Apr 21, 2009 at 12:03 AM, Gerhard Fiedler
<listsspamspam_OUTconnectionbrazil.com> wrote:

> I don't understand this. Why do you think that a CAN implementation that
> doesn't use the standard ISO 11898-2 controllers wouldn't be CAN?

Nobody said that.

> Even
> ISO 11898 defines a physical layer that is not compatible with the
> common ISO 11898-2 controllers. There's also SAE J2411 and others, and
> there's nothing that says I can't implement a one-wire interface for the
> CAN bus that also provides supply to the devices. Or a simple wired-or
> interface.
>


--
Xiaofan http://mcuee.blogspot.com

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