Re: [time-nuts] Form factor
On Tue, Dec 21, 2010 at 11:50 AM, bownes bownes@gmail.com wrote:
That would all depend upon the interconnect strategy, which hasn't reached consensus either.
Based on the early module list, a bus probably isn't necessary, and individual ribbon cable and/or coax will do if speeds stay low.
I think the goal on should be to have the least interaction between
modules as possible. If you have a shared backplane or shared ribon
cable then system level integration will be a mess. If this project
is successful there might be a half dozen module types and a couple
revisions of each one. I doubt anyone will have a test lab where we
can test all posable module-to-module interactions. So these have to
be mostly independent modules that send only minimal information.
Development might halt because in order to design a module you'd need
to own an example of every other module.
I put two requirements in my proposal to address this problem
- Modules shall NOT expose their internal design to the system bus
- Modulas must perform some potentially useful default mode function
when used stand-alone, disconnected from the system bus
These two requirements are aimed to make testing much simpler or even
posable when none of the designers are colocated
=====
Chris Albertson
Redondo Beach, California
What is the minimum size micro controller that can support CAN?
Every module, not matter how simple will need a uP that can suport
whatever bus we choose. It would be great if we could get away with
an 8-pin AVR "tiny" these sell for abut a buck each. I hate to use
up a minimum 1 square inch of PCB space just to handle the system bus.
But mmaybe CAN is easy and the software fits in 1K of on-chip flash?
I don't know.
I really don't think we need anything so complex as CAN. A HYGE Open
Counter system might have a dozen modules and I'd figure a typical
number might be 2 or 4.
With I2C we'd make up our own message dictioary and the uPs on each
card would run at the "bit level" not using any kind of protocol
stack. If noise on the wire is an issue then either every cards
needs a balanced driver and we use twisted pair as out physical layer
or we put the single ended i2c inside coax jumpers between cards.
Again I don't care much what is used but I think we need
- Reasonable speed
- ALL cards should be peers with no "master"
- in-band addressing
- Small minimum size for the uP and low Flash memory footprint
Can "CAN" do this? I'm worried about #2 and #4. I don't have time to
read up on this right now and the Wiki article was not detailed enough
On Wed, Dec 22, 2010 at 12:10 PM, Robert LaJeunesse
rlajeunesse@sbcglobal.net wrote:
The I2C bus is moderately well defined for the hardware interface, but hardly at
all at the software level. This could be problematic for a system that supports
multiple hardware configurations. It also uses single ended signalling which
creates RF noise if not treated extremely carefully. Might I suggest the use of
a more robust, extensible interface with strong software support and
differential signalling? The best that comes to minde is 2-wire CAN based on the
CANopen standard. See http://en.wikipedia.org/wiki/CANopen and
http://www.canopen.us/
Bob L.
From: Chris Albertson albertson.chris@gmail.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wed, December 22, 2010 2:58:10 PM
Subject: Re: [time-nuts] Form factor
The use of i@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.
...
time-nuts mailing list -- time-nuts@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
In message AANLkTikLKD2Z15kwbPEwXTFGFf=wqWsiNv+To7OuPf61@mail.gmail.com, Chri
s Albertson writes:
Can "CAN" do this?
CANbus is mostly intented for hostile environments, and for anything
"in-box" less can do.
The problem with I2C is that it is not well suited for systems with
more than one master on the bus. It can be done, but it's messy.
MODBUS is also an option.
Be aware that most of these types of protocols are strictly
command-reponse, there is no provision for 'interrupts' or
other asynchronous events.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
On Wed, Dec 22, 2010 at 2:41 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message AANLkTikLKD2Z15kwbPEwXTFGFf=wqWsiNv+To7OuPf61@mail.gmail.com, Chri
s Albertson writes:
Can "CAN" do this?
CANbus is mostly intented for hostile environments, and for anything
"in-box" less can do.
The problem with I2C is that it is not well suited for systems with
more than one master on the bus. It can be done, but it's messy.
MODBUS is also an option.
Quick reading says that MODBUS allows only one master unless the
physical media is TCP/IP over Ethernet. I don't think we want
something that complex.
How hard is it to do multi-master I2C. I still like I2C because it
can be doe on the smallest of uP with zero extra hardware. But
something else might be better.
If I try to make a prototype I2C multi-master system what are some
problems I should look out for.
I think prototypes or simulations are the way to decide this. Seems
we are not going to know which is best for this purpose without taking
each proposal to the next level of design detail
Maybe we should have a budget in square mm and dollars for bus
interface would be good to say "100 mm^2 and $2. but I don't know
what's realisticMaybe use those numbers as a figure of merit when
comparing two designs
=====
Chris Albertson
Redondo Beach, California
El 22/12/2010 23:11, Chris Albertson escribió:
Again I don't care much what is used but I think we need
- Reasonable speed
- ALL cards should be peers with no "master"
- in-band addressing
- Small minimum size for the uP and low Flash memory footprint
Can "CAN" do this? I'm worried about #2 and #4. I don't have time to
read up on this right now and the Wiki article was not detailed enough
#2 yes. CAN is more oriented to variables, not to a master-slave
architecture. For example, in a car, if one node requires one variable
it sends a message with the message Id (11 or 29 bits, depending on CAN
version) and RTR bit set. The node that has that variable answer with a
message with the Id, RTR clear, and the variable value. Some nodes send
continuously messages. SAE-J1939 is a protocol oriented that way, simple
variable exchange.
#4 yes, for example AT91SAM7X128 (LQFP 100, enough Flash and RAM for
running as a quite complex CANopen node, for example)
But have in mind that CAN messages are limited to an 8-byte payload. And
CAN is not so complex, but more intended for its original application:
automotive message exchange. But it is very robust, and have gained a
lot of acceptance in industrial fields, where some automation protocols
have been designed to run specifically to run over CAN, like CANopen.
And also is used in spacecraft (ExoMars mission uses CANopen and CAN
message architecture, but with RS-485 physical layer instead of the
standard CAN automotive phisical layer).
Regards,
Javier
--
Javier Herrero EMAIL: jherrero@hvsistemas.com
Chief Technology Officer
HV Sistemas S.L. PHONE: +34 949 336 806
Los Charcones, 17 FAX: +34 949 336 792
19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.com
In message AANLkTinSVCO_Px6NpttFVrtJaFy-wctgTFKXe6keErho@mail.gmail.com, Chri
s Albertson writes:
How hard is it to do multi-master I2C.
About as hard as multi-master MODBUS
I still like I2C because it
can be doe on the smallest of uP with zero extra hardware. But
something else might be better.
One thing you may want to consider is that I2C is hard to optoisolate
and debug. Async is much easier for both.
If I try to make a prototype I2C multi-master system what are some
problems I should look out for.
Collisions and how to resolve them.
Same as with any protocol on shared media.
Badly written MODBUS implementations can get confused by multi-master
systems, but if you follow the spec precisely with timeouts etc,
and the masters have some way to resolve who gets to use the
bus, it will work just fine.
I think prototypes or simulations are the way to decide this.
There is tons of experience to reuse, don't invent the deep water.
I built a pretty complicated battery-backed power-supply which ended
up having 7 microcontrollers for various bits of work.
I used a shared opto-isolated async bus. You need two optocouplers
per microcontroller, and one place you power the shared bus, and
you're all set.
I have yet to see an microcontroller without an async port.
Poul-Henning
PS: I can highly recommend A. Tanenbaums "Computer Networks"
if you have never worked with this kinds of comms issues before.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
On Wed, Dec 22, 2010 at 3:32 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
I used a shared opto-isolated async bus. You need two optocouplers
per microcontroller, and one place you power the shared bus, and
you're all set.
I have yet to see an microcontroller without an async port.
Opto-isolater? Why not just use fiber cable between cards. I know
it sounds exotic but also seems to have half the parts count. those
s/pdif jacks are so cheap and I bet you can use them as pretty much
drop in replacements for opto-isolators. Would s/pdif jacks work as a
physical layer?
Really I just used I2C in my write-up as a place holder. I you say
nothing no one ever says a blank paper is wrong and suggests something
better.
s optical isolation required when all the modules are sharing a common
power supply? Does this means all the coax connectors need to be
isolated. I guess some one better step up and propose a grounding
scheme. That's not going to be me.
Chris Albertson
Redondo Beach, California
Perhaps I'm old school, but this sounds overly complex to me.
Probably the most important thing I learned in engineering school
(besides where the beer and amiable consorts were) was KISS. The more
complex, the less likely the project is to complete.
So I pose the question: Do we need a bus like this at all to meet the
basic goals?
The suggestion of a main board with input/output modules that plug
into the main board sounds much simpler. If the IO needs to be
modified, you build a separate module. If you think there are going to
be parameters that will be switched on/off/adjusted/whatever on that
module, put a few io pins from the main controller on the connector to
the module. May never get used, but if someone wants to rework the i/o
module, you're all set. Many of the popular controllers can put an I2C
bus or a serial port on any pin pair. Libraries for both are common
for the controllers I'm familiar with.
Example: How much complexity do you need in an input module? What are
the features you might like to manipulate there? Would it really take
more than, say, 8 pins?
The discussion about opto isolation and/or differential pairs and the
like seems like overkill as well. My vision is that this thing fits
into a single box. If you need that much isolation or are worried
about that much noise on a bus inside a box, either you are pushing
some serious speed or operating in an environment that's way more
hostile than I would like to be sitting in and observing the front
panel.
With that said, I also concur that any module should be easy to test
in a standalone mode. Not necessarily useful to many folks outside of
the opencontroller project, but easy to test. That's why, for example,
I suggested that the core counter module be usable with nothing more
than TTL inputs/outputs. An input module then might be nothing more
than appropriate signal conditioning.
Final design, will, of course, dictate pcb sizes.
Bob
On Wed, Dec 22, 2010 at 9:05 PM, Chris Albertson
albertson.chris@gmail.com wrote:
On Wed, Dec 22, 2010 at 3:32 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
I used a shared opto-isolated async bus. You need two optocouplers
per microcontroller, and one place you power the shared bus, and
you're all set.
I have yet to see an microcontroller without an async port.
Opto-isolater? Why not just use fiber cable between cards. I know
it sounds exotic but also seems to have half the parts count. those
s/pdif jacks are so cheap and I bet you can use them as pretty much
drop in replacements for opto-isolators. Would s/pdif jacks work as a
physical layer?
Really I just used I2C in my write-up as a place holder. I you say
nothing no one ever says a blank paper is wrong and suggests something
better.
s optical isolation required when all the modules are sharing a common
power supply? Does this means all the coax connectors need to be
isolated. I guess some one better step up and propose a grounding
scheme. That's not going to be me.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I don't see how a backplane bus with modules you plug in is simpler
then having only the modules with no backplane bus. The problem with
a hard backplane is that you have to know in advance what you are
going to plug into it. Another (seemingly unsolvable) problem is the
mechanical design. No one has yet come up with one that can be build
at home with normal tools or a low-cost of the shelf.
I think what we are talking about is the same think but only the "back
plane" is cable that you daisy chain from one module to the next.
Call it a "flexible backplane. It might be a small 10 pin ribbon
cable, a coax or a fiber cable.
I don't know if opto-isolation is required but in any case that is a
feature of a module that a module designer may or may not need. At
the system level we don't care what is inside each module. So I
agree, any talk about isolation is premature. However we do need to
pick a bus
The problem with picking a size for a PCB is that we can't know what
the final design will be. With luck people will be building modules
for a long time and building modules to do functions we have not
thought of. Without knowing what these funtions might be we can't
know the design.
I do agree with "KISS". The best thing is to simply eliminate
everything you can. People could not agree on a chassis design so,
out that went, no chassis execpt as an option built by the end user.
But the PCB size is selected to give the end user a wide selection of
options. Same with how to interface this to a computer of if we even
want a physical front panel. It appeared that argument would never
end, so out with that too. The system just has a bus or 2 or 4 wires
(TBD) if if yu like some kind of computer interface then build an
"interface module". So what is left? Just an interface spec. When
you remove the last module yu have just air in the box. Seem to me
that is KISS is extreme.
The simplest Open Counter, I can think of is just two modules, (1) A
basic low performance frequency counts like the FCC1 and (2) and
interface module to translat the system bus to USB. That could be
build with 1/2 dozen chips for under $50. A more complex system would
have better modules, cost more and I think is what people want but I
think a good measure of our quality of system engineering will be the
size and cost of a minimum system.
On Wed, Dec 22, 2010 at 7:56 PM, Bob Bownes bownes@gmail.com wrote:
Perhaps I'm old school, but this sounds overly complex to me.
Probably the most important thing I learned in engineering school
(besides where the beer and amiable consorts were) was KISS. The more
complex, the less likely the project is to complete.
So I pose the question: Do we need a bus like this at all to meet the
basic goals?
The suggestion of a main board with input/output modules that plug
into the main board sounds much simpler. If the IO needs to be
modified, you build a separate module. If you think there are going to
be parameters that will be switched on/off/adjusted/whatever on that
module, put a few io pins from the main controller on the connector to
the module. May never get used, but if someone wants to rework the i/o
module, you're all set. Many of the popular controllers can put an I2C
bus or a serial port on any pin pair. Libraries for both are common
for the controllers I'm familiar with.
Example: How much complexity do you need in an input module? What are
the features you might like to manipulate there? Would it really take
more than, say, 8 pins?
The discussion about opto isolation and/or differential pairs and the
like seems like overkill as well. My vision is that this thing fits
into a single box. If you need that much isolation or are worried
about that much noise on a bus inside a box, either you are pushing
some serious speed or operating in an environment that's way more
hostile than I would like to be sitting in and observing the front
panel.
With that said, I also concur that any module should be easy to test
in a standalone mode. Not necessarily useful to many folks outside of
the opencontroller project, but easy to test. That's why, for example,
I suggested that the core counter module be usable with nothing more
than TTL inputs/outputs. An input module then might be nothing more
than appropriate signal conditioning.
Final design, will, of course, dictate pcb sizes.
Bob
On Wed, Dec 22, 2010 at 9:05 PM, Chris Albertson
albertson.chris@gmail.com wrote:
On Wed, Dec 22, 2010 at 3:32 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
I used a shared opto-isolated async bus. You need two optocouplers
per microcontroller, and one place you power the shared bus, and
you're all set.
I have yet to see an microcontroller without an async port.
Opto-isolater? Why not just use fiber cable between cards. I know
it sounds exotic but also seems to have half the parts count. those
s/pdif jacks are so cheap and I bet you can use them as pretty much
drop in replacements for opto-isolators. Would s/pdif jacks work as a
physical layer?
Really I just used I2C in my write-up as a place holder. I you say
nothing no one ever says a blank paper is wrong and suggests something
better.
s optical isolation required when all the modules are sharing a common
power supply? Does this means all the coax connectors need to be
isolated. I guess some one better step up and propose a grounding
scheme. That's not going to be me.
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@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
In message AANLkTi=JWicDWbFWiZoRpUF3vpJ=DZXxVEq7cJ-aBd2q@mail.gmail.com, Chri
s Albertson writes:
Opto-isolater? Why not just use fiber cable between cards.
I have only ever seen point-to-point versions, I needed 7 cards
connected.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.