[time-nuts] Form factor

Chris Albertson albertson.chris at gmail.com
Wed Dec 22 19:58:10 UTC 2010


The use of i at c that I proposed was ONLY for module-to-module
communication.  I wrote that none of the internal chips in a module
were to be exposed to the i2c bus.   A module may very well have it's
own internal bus but that design detai needs to be hidden from the
rest of the system.

In an open system built with modules yu realy, have to be careful to
never expose the inner working on a module.  Else other modules come
to depend on the internal design of other modules and then you can
never upgrade of replace any of them because you have a circular
dependency loop or likely even multiple loops.   So we have to be
carfull to never expose the kind of chip or it's internal bus address
between modules.

So in the proposel I wrote i2c is used ONLY between the external
interfaces of modules.  A module would be free to use a SPI internally
and TDC-GP2 chip if it wants.

I just read up on  SPI.   There are a few problems with it for this application

1) No in-band addressing.  You need to run select lines. This means
you have to know in advance what "slave" devices you will be
connecting.  This Open Counter is going to be "open" in that we will
be plugging devices in and out and do not know the final list of
devices in advance.

2) A bigger problem is that SPI is not "multi-master".  An open system
is much easier to construct if no module is "special" and all are
equal on the bus.   An example is  the desktop PC is the "master".
That works until you want to control it via a front panel switch or
remotely over the network.  OK you can build both slave and master
interfaces to each module and have some command to switch modes but
then complexity is far to high

I don't care is I2C is used or not but I thing the bus needs several attributes

1) Reasonable speed, say about 100K bps
2) No "master", all nodes are peers
3) The number of wires remains constant is the number of nodes on the
bus varies.  In other words in-band addressing, no select lines.

On Wed, Dec 22, 2010 at 10:37 AM, Bruce Griffiths
<bruce.griffiths at xtra.co.nz> wrote:
> Chris Albertson wrote:
>>
>> I wrote some more ideas, I'm trying here to write what might later,
>> after some edits become a "consensous document". that captures what
>> most people want.   Edit away, maybe some of this will make it to the
>> web site...
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++
>> Here is an idea for the top of the web page:
>>
>> How is the Open Counter project "open".
>> 1) The basic design of the counter is open to the addition of new
>> modules and new technology.  New modules can be pllugged in or replac
>> older modules.  The interface between modules is published, anyone is
>> open to design or build a module
>>
>> 2) The design of each module is open for all to see.  Anyone can
>> provide kits or parts or make PCBs.  (There may be some restrictions
>> on commercial sales.)
>>
>> 3) The designs are publishing using open file formats that are industry
>> standads
>>
>> 4) the design tools, compilers, schematic captures, word processors,
>> used to read and modify the design files are available to all wit at
>> the most a very modest fee or preferable are Open Source tools
>>
>> 5) the hardware is designed such that it can be physiclly built by
>> anyone with "amateur level" skills. the parts can be build by an open
>> group
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Form Factor: One more idea.  I think there is a way to have "all of the
>> above"
>>
>> Let's say we agree to make all PCBs the same size as a 160-3U Eurocard
>> but with four holes in the corners too.  A real Eurocard system is
>> expensive but I'm just saying to use the same size rectangle but no
>> back plane.   If you do this they will (mechanically, not
>> electrically) fit in a Euro card cage they will also fit in those
>> Hammond boxes and with four holes people can stack them on threaded
>> rods with spacers or mount them in  1U  chassis on standoffs.  They
>> could also by mounted with standoffs to a "disk sled" and then go into
>> a computer or file server chassis.
>>
>> The spec is easy to write and understand too:
>> "Cards shall be 100mm x 160mm, less than 2mm thick and have 5mm holes
>> in each corner spaced 5mm from each edge."
>>
>> These cards would fit perfectly into a Hammond 1455P2201 box or as I
>> said above mounted just about any way that has so far been suggested.
>>
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> The next thing to work on is the rear facing edge of the card.  We
>> really need to minimize the number of different connectors and signal
>> levels.  The smaller the set the better.  I'll take a stabe at it
>> below and
>>
>> This is for the REAR edge:
>> 1) power:  four pins on 0.1 inch centers for +12, -12, +5 and ground
>>
>> 2) frequency reference can be 1Hz, 10MHz or ?? as required but will
>> use SMA connector
>>
>> 3) Data, for command and setup and digital output wiil use a shared
>> 100Kbps i2c bus (also called "two wire") Each card is to have two
>> connectors so the multiple cards can be diasy chained.  cards shall
>> NOT allow there internal components to be visible on this external i2c
>> bus.
>>
>
> Using the i2c bus isn't a good idea for anything other than very simple
> applications such as interfacing to serial EEPROMS.
> Compatibility issues and other hidden problems (such as when attempting to
> use multiple masters) soon become apparent.
> SPI is far less problematic and allows economic use of interesting chips
> like the ACAM TDC-GP2.
>
>> 4) Many cards such as a trigger or pre-scaeler will produce output
>> signals that need to to sent point to point to the rear edge of other
>> cards I'll suggest SMA for this
>>
>> (I hope this covers everything.  unless we might need digitized
>> signals and these can be very high bandwidth)
>>
>> The FRONT edage of each card is reserved entirely for signals that the
>> user would directly interact with, such as input jacks or status/power
>> LED or a data connectors for a computer or network
>>
>>
>> The next level of interface design is the format of the data to go
>> over the I2C bus.  Some ideas.
>>
>> 1) Each card type (trigger, counter,  Interface,...) will have it's
>> own unique number.  Each physial card will have it's own "instance
>> number"  So if two cards of the same type are in the system each is
>> numbered 0, 1, 2,..  Cards in an Open Counter are identified by
>> combining the two numbers.  There are many options but all allow for
>> over 100 cards in one system.
>>
>> 2) As a minimum each card must implement one command, that would be
>> "Identify yourself".  The card must respond with at least a one bit
>> status saying  "present".   By this mmeans any card can find out what
>> other cards are present.
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> At some point we need to say what is and what is not an "Open Counter"....
>> Open Counter System requirements.
>>
>> 1) An Open Counter system will always require a minimum of two cards
>> with one being an "Interface card" and the other some kind of signal
>> handing card.  An Interface card connects the data in the 12c system
>> bus to a computer, network or to a human operator via a display or
>> status LEDs.
>>
>> 2) Notwithstanding the above, single cards must be usable devices when
>> used by themselves.  cards may poll the (disconnected) i2c bus to find
>> that they are isolated and then must default to standalone mode.
>>
>> 3) Cards must allow that multiple instance of their own type may be
>> connected on the same system i2c bus, that is, all output data shall
>> include the card's instance number. (This allows for a multi channel
>> Open Counter)  This requirement applies to Interface Cards too.    A
>> large Open Counter system might have multiple input channels and also
>> a set of interface cards connecting it to a network and a computer via
>> USB and a front panel with a large LCD screen.
>>
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> The above, if accepted has a design implication.  Cards can not track
>> the state of the system by simply remembering the set of commands they
>> have transmitted.  That is because other cards may have transmitted
>> commands.   To make an analogy you should never assume Joe is at home
>> because to told Joe to go home.  You must ask Joe his location
>> whenever you need to know it.
>>
>> There are likely 1,000 other implications from the above proposals and
>> these need to be worked out.  But in most projects you only find them
>> during the first cycle of detail design
>> I
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>
> Bruce
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
=====
Chris Albertson
Redondo Beach, California



More information about the time-nuts mailing list