On 04.12.2015 г. 21:49, upsidedown@downunder.com wrote:
> On Mon, 30 Nov 2015 03:24:39 +0200, Dimiter_Popoff <dp@tgi-sci.com>
> wrote:
>
>>>>>> I am not familiar with CAN but I would like to see a standardized
>>>>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>>>>> dreaming of that for may be 25 years.
>>>
>>> The 10Base5 with vampire taps and RG-8 like coaxial cable was nice,
>>> why not implement your own PoE ? The RG-8/213 like coaxial cable can
>>> withstand several hundred volts and several amps :-)
>>
>> I would if I felt I had the muscle to enforce a standard :).
>> It does not have to be 10base5, 10base2 (not sure, the 5mm coax
>> cable thing) is plenty I think. I am not thinking hundreds of meters,
>> rather a few meters to may be tens of meters.
>
> 10base2 (RG-58) cable can only handle 300 Vdc and will melt at around
> 10 A, so the available power would be well below 3000 W :-)

Hmmm, so we'll have to use separate cabling to heat larger rooms during
the cold winter days (no such issue down under I suppose :D ).

>
>> Then may be today
>> we can do somewhat more than 10 Mbps over the coax cable, say 50
>> would be very nice.
>
> Any DMT/OFDM system can carry much more than that. For instance DVB-C2
> used by some CATV companies and MATV systems can carry at least 10
> Gbit/s on a single coaxial cable with up to 12 bits/symbol, at least
> 850 MHz, potentially 2 GHz bandwidth. Of course DVB-C2 is highly
> complex.
>
>> Using a <3mm coax (I always have to look up the
>> RG whatever names...) could also be convenient within say an apartment
>> or a small house.
>
> RG-174 might be carrying several Gbit/s at those distances using some
> sort of DMT/OFDM.
>

My first thought re your suggested cable modem techniques was "too
complex". Well complex of course, but perhaps not "too complex"
nowadays, I would bet cable modems are single chip units
nowadays (actually I opened one some 5-10 years ago and it had
some BGA plus some small stuff, IIRC the radio part was at least
in part discrete).
But my thoughts on that revolve around misusing the RG-174 in the
good old 10 Mbps manner, say 50 Mbps should be easily doable
nowadays. Hopefully the PHY will not need these -9 volts... but
keeping it galvanically isolated makes that irrelevant really.
I would also vote for a version with no galvanic isolation,
say for use within the same room, many people torture i2c at
longer distances to connect a sensor etc., this could make
things easier and more robust if doable cheap enough. And will
be a source of countless torn hairs for people who will
inevitably push it to and beyond its limits.... :D .

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On 04.12.2015 г. 23:26, Hans-Bernhard Bröker wrote:
> Am 04.12.2015 um 11:04 schrieb Dimiter_Popoff:
>
>> How did you handle what I described in my initial message? The
>> "unidirectional" aspect of it I mean (don't know what else to call it,
>> the fact that the master can't know whether the slave had data to send
>> and that the slave has no way of knowing whether the master is clocking
>> in valid data or just clocking it to poll it for output)?
>
> The obvious choice would be to just stop worrying about it, because it's
> not actually an issue.  Both problems go away once you realize that
> there's not actually any hurt in just sending the same data again if the
> originating node has nothing newer available.  Yes, that will mean you
> waste some of the bandwidth on needless repeats, but then again, SPI is
> generally pretty fast to begin with, so a little waste should be tolerable.

No, this just does not work. Please try to _understand_ my initial post.

Dimiter

Am 04.12.2015 um 11:04 schrieb Dimiter_Popoff:

> How did you handle what I described in my initial message? The
> "unidirectional" aspect of it I mean (don't know what else to call it,
> the fact that the master can't know whether the slave had data to send
> and that the slave has no way of knowing whether the master is clocking
> in valid data or just clocking it to poll it for output)?

The obvious choice would be to just stop worrying about it, because it's 
not actually an issue.  Both problems go away once you realize that 
there's not actually any hurt in just sending the same data again if the 
originating node has nothing newer available.  Yes, that will mean you 
waste some of the bandwidth on needless repeats, but then again, SPI is 
generally pretty fast to begin with, so a little waste should be tolerable.

On Mon, 30 Nov 2015 03:24:39 +0200, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>>>>> I am not familiar with CAN but I would like to see a standardized
>>>>> Ethernet connector for coaxial cable plus power pins (12V?). Have been
>>>>> dreaming of that for may be 25 years.
>>
>> The 10Base5 with vampire taps and RG-8 like coaxial cable was nice,
>> why not implement your own PoE ? The RG-8/213 like coaxial cable can
>> withstand several hundred volts and several amps :-)
>
>I would if I felt I had the muscle to enforce a standard :).
>It does not have to be 10base5, 10base2 (not sure, the 5mm coax
>cable thing) is plenty I think. I am not thinking hundreds of meters,
>rather a few meters to may be tens of meters.

10base2 (RG-58) cable can only handle 300 Vdc and will melt at around
10 A, so the available power would be well below 3000 W :-)
 
>Then may be today
>we can do somewhat more than 10 Mbps over the coax cable, say 50
>would be very nice. 

Any DMT/OFDM system can carry much more than that. For instance DVB-C2
used by some CATV companies and MATV systems can carry at least 10
Gbit/s on a single coaxial cable with up to 12 bits/symbol, at least
850 MHz, potentially 2 GHz bandwidth. Of course DVB-C2 is highly
complex.
 
>Using a <3mm coax (I always have to look up the
>RG whatever names...) could also be convenient within say an apartment
>or a small house.

RG-174 might be carrying several Gbit/s at those distances using some
sort of DMT/OFDM.

On Sun, 29 Nov 2015 13:48:44 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>>PoE could have been so cheap and simple that we would use it everywhere.
>> Instead, it is far too complicated and expensive for the majority of uses.
>
>
>The two standards bit does get a bit silly, but the problem with
>standardizing power distribution is that you immediately run into the
>question of how much power is available to the device.  If you have a
>bus-like configuration, it gets worse because you now have to deal
>with unknown numbers of devices drawing unknown amounts of power.  A
>good chunk of the power related complexity in USB and PoE is the
>management of that.

If the available power is an issue, why not switch to some kind of
Power Line Communication and you do not need to worry about available
power :-)

Of course, the available bandwidth and distance (especially in
multiphase systems) will be limited.

So you really have to chose between power and bandwidth.

On 4.12.15 15:31, Dimiter_Popoff wrote:
(-- clip clip --)

> OK, the word choice is not of much importance here as the posts
> carry enough explanation what they mean (given the posts get
> read, that is :-) ).
>
> I am curious how you handled that issue at the time you connected
> MCU-s via SPI?
>
> In my case it is a single master with multiple slaves and individual
> select lines to each of them; the master (a 68340, this was 1992-3,
> remember) would talk to one slave (they all were 68HC11...) at a
> time using the 7 bit protocol I described - and I think it would
> ensure something like a 1 mS minimum time between bytes so that
> each HC11 would process the byte (the HC11 code was such that
> it guaranteed it would cope for that time). Slow but faster than
> was needed.
> How did you address all this?
>
> Dimiter


Years ago, I made a network of 27 AVR slaves connected to one
AVR master with SPI. The sources may be somewhere on the archive
CD's still.

-- 

-Tauno Voipio

On 04/12/15 14:31, Dimiter_Popoff wrote:
> On 04.12.2015 г. 14:58, David Brown wrote:
>> On 04/12/15 11:04, Dimiter_Popoff wrote:
>>> On 04.12.2015 г. 11:26, David Brown wrote:
>>>> On 04/12/15 02:42, Dimiter_Popoff wrote:
>>>>>   ....
>>>>>
>>>>> While I am sure practically everyone in this group has used SPI
>>>>> in the manner of a plain serial link to shift registers, not many - if
>>>>> anyone except me - has used it as a link between two MCU-s in a
>>>>> way one would use say UARTs, which made me think the story was worth
>>>>> telling; not that I am surprised that the thicker know-betters would
>>>>> locate a word in it to pick on, neither do I care much about it.
>>>>>
>>>>
>>>> I have also used SPI to communicate between two micros.  It wasn't a
>>>> great choice in my case - it couldn't be much faster than a UART
>>>> because
>>>> the slave had no buffering or DMA, so had to use interrupts on the
>>>> incoming data.  But on devices with DMA and good slave SPI support, it
>>>> can work well.
>>>>
>>>
>>> How did you handle what I described in my initial message? The
>>> "unidirectional" aspect of it I mean (don't know what else to call it,
>>> the fact that the master can't know whether the slave had data to send
>>> and that the slave has no way of knowing whether the master is clocking
>>> in valid data or just clocking it to poll it for output)?
>>>
>>
>> I think at the time I just skipped over that bit - your use of
>> "unidirectional" didn't make sense to me, but the rest was fine.  I
>> thought perhaps you meant that the individual SPI signals are
>> unidirectional (unlike RS485), which is why it is a lot easier to do
>> galvanic isolation with SPI than RS485.
>>
>> But what you meant here is that there is one master on the bus which
>> controls everything, rather than multi-master.  When you write
>> "unidirectional" in a more general context (and you wrote "SPI is meant
>> to be unidirectional"), I would say the normal interpretation is that
>> you are saying the data flow is "unidirectional" - which is clearly not
>> the case.
>>
>>
> 
> OK, the word choice is not of much importance here as the posts
> carry enough explanation what they mean (given the posts get
> read, that is :-) ).
> 
> I am curious how you handled that issue at the time you connected
> MCU-s via SPI?
> 
> In my case it is a single master with multiple slaves and individual
> select lines to each of them; the master (a 68340, this was 1992-3,
> remember) would talk to one slave (they all were 68HC11...) at a
> time using the 7 bit protocol I described - and I think it would
> ensure something like a 1 mS minimum time between bytes so that
> each HC11 would process the byte (the HC11 code was such that
> it guaranteed it would cope for that time). Slow but faster than
> was needed.
> How did you address all this?
> 

I am afraid I can't remember - it was a long time ago.  I can't even
remember what project it was, or what microcontrollers.  But I think the
communication was mostly master to slave - the slaves just passed back a
status byte or two as the master sent out its commands.

On 04.12.2015 г. 14:58, David Brown wrote:
> On 04/12/15 11:04, Dimiter_Popoff wrote:
>> On 04.12.2015 г. 11:26, David Brown wrote:
>>> On 04/12/15 02:42, Dimiter_Popoff wrote:
>>>>   ....
>>>>
>>>> While I am sure practically everyone in this group has used SPI
>>>> in the manner of a plain serial link to shift registers, not many - if
>>>> anyone except me - has used it as a link between two MCU-s in a
>>>> way one would use say UARTs, which made me think the story was worth
>>>> telling; not that I am surprised that the thicker know-betters would
>>>> locate a word in it to pick on, neither do I care much about it.
>>>>
>>>
>>> I have also used SPI to communicate between two micros.  It wasn't a
>>> great choice in my case - it couldn't be much faster than a UART because
>>> the slave had no buffering or DMA, so had to use interrupts on the
>>> incoming data.  But on devices with DMA and good slave SPI support, it
>>> can work well.
>>>
>>
>> How did you handle what I described in my initial message? The
>> "unidirectional" aspect of it I mean (don't know what else to call it,
>> the fact that the master can't know whether the slave had data to send
>> and that the slave has no way of knowing whether the master is clocking
>> in valid data or just clocking it to poll it for output)?
>>
>
> I think at the time I just skipped over that bit - your use of
> "unidirectional" didn't make sense to me, but the rest was fine.  I
> thought perhaps you meant that the individual SPI signals are
> unidirectional (unlike RS485), which is why it is a lot easier to do
> galvanic isolation with SPI than RS485.
>
> But what you meant here is that there is one master on the bus which
> controls everything, rather than multi-master.  When you write
> "unidirectional" in a more general context (and you wrote "SPI is meant
> to be unidirectional"), I would say the normal interpretation is that
> you are saying the data flow is "unidirectional" - which is clearly not
> the case.
>
>

OK, the word choice is not of much importance here as the posts
carry enough explanation what they mean (given the posts get
read, that is :-) ).

I am curious how you handled that issue at the time you connected
MCU-s via SPI?

In my case it is a single master with multiple slaves and individual
select lines to each of them; the master (a 68340, this was 1992-3,
remember) would talk to one slave (they all were 68HC11...) at a
time using the 7 bit protocol I described - and I think it would
ensure something like a 1 mS minimum time between bytes so that
each HC11 would process the byte (the HC11 code was such that
it guaranteed it would cope for that time). Slow but faster than
was needed.
How did you address all this?

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On 04/12/15 11:04, Dimiter_Popoff wrote:
> On 04.12.2015 г. 11:26, David Brown wrote:
>> On 04/12/15 02:42, Dimiter_Popoff wrote:
>>>  ....
>>>
>>> While I am sure practically everyone in this group has used SPI
>>> in the manner of a plain serial link to shift registers, not many - if
>>> anyone except me - has used it as a link between two MCU-s in a
>>> way one would use say UARTs, which made me think the story was worth
>>> telling; not that I am surprised that the thicker know-betters would
>>> locate a word in it to pick on, neither do I care much about it.
>>>
>>
>> I have also used SPI to communicate between two micros.  It wasn't a
>> great choice in my case - it couldn't be much faster than a UART because
>> the slave had no buffering or DMA, so had to use interrupts on the
>> incoming data.  But on devices with DMA and good slave SPI support, it
>> can work well.
>>
> 
> How did you handle what I described in my initial message? The
> "unidirectional" aspect of it I mean (don't know what else to call it,
> the fact that the master can't know whether the slave had data to send
> and that the slave has no way of knowing whether the master is clocking
> in valid data or just clocking it to poll it for output)?
> 

I think at the time I just skipped over that bit - your use of
"unidirectional" didn't make sense to me, but the rest was fine.  I
thought perhaps you meant that the individual SPI signals are
unidirectional (unlike RS485), which is why it is a lot easier to do
galvanic isolation with SPI than RS485.

But what you meant here is that there is one master on the bus which
controls everything, rather than multi-master.  When you write
"unidirectional" in a more general context (and you wrote "SPI is meant
to be unidirectional"), I would say the normal interpretation is that
you are saying the data flow is "unidirectional" - which is clearly not
the case.

On 04.12.2015 г. 11:26, David Brown wrote:
> On 04/12/15 02:42, Dimiter_Popoff wrote:
>>  ....
>>
>> While I am sure practically everyone in this group has used SPI
>> in the manner of a plain serial link to shift registers, not many - if
>> anyone except me - has used it as a link between two MCU-s in a
>> way one would use say UARTs, which made me think the story was worth
>> telling; not that I am surprised that the thicker know-betters would
>> locate a word in it to pick on, neither do I care much about it.
>>
>
> I have also used SPI to communicate between two micros.  It wasn't a
> great choice in my case - it couldn't be much faster than a UART because
> the slave had no buffering or DMA, so had to use interrupts on the
> incoming data.  But on devices with DMA and good slave SPI support, it
> can work well.
>

How did you handle what I described in my initial message? The
"unidirectional" aspect of it I mean (don't know what else to call it,
the fact that the master can't know whether the slave had data to send
and that the slave has no way of knowing whether the master is clocking
in valid data or just clocking it to poll it for output)?

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/