Am 03.12.2015 um 02:36 schrieb Dimiter_Popoff:> On 02.12.2015 г. 22:28, Hans-Bernhard Bröker wrote: >> Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff: >>> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote: >>>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:>>>>> Was not so straight forward as SPI is meant to be unidirectional,>>>> Huh? How do you arrive at classifying a full duplex link like SPI as >>>> "unidirectional"?>>> I am not sure how you define full duplex but it _is_ unidirectional >>> in that the master has no way of knowing - other that the data contents >>> it receives from the slave - whether the slave had something to say or >>> not.>> And I absolutely don't see any sense in which the term "direction" or >> "directional" could have a relation to what you're saying there. A >> direction is something like "node A to node B", or "node B to node A". A >> single SPI link (unless artificially crippled) between A and B already >> supports both of those directions, fully simultaneously, so I really >> don't see how you justify calling that "uni-directional." > > You should read more carefully if you want to have success at being > the always know better.Well, if that's the kind of argument you want to have: you should heed your own advice, starting by reading what _you_ wrote, before making blatantly false claims like the following:> I said SPI was _meant_ to be unidirectional in its use, not that > it was unidirectionl as you claim I have said.Evidence to the contrary is in the quoted material above, but just in case, look at this: >>> I am not sure how you define full duplex but it _is_ unidirectional> IOW, it is _meant_ to > be used either as input or as output, not both at the same time > (e.g. DAC/ADC etc.).And that's just as untrue as it was the first two times round. In any sanely designed physical data link actually _meant_ to be used for data flowing in only one direction at a time, there would be only _one_ data line; the second one would be a total waste. The fact that SPI has both a MOSI and a MISO line is thus pretty compelling evidence against your claims about how it was meant to be used. > I am afraid I cannot help you much any further. I'll agree to that, although I'm quite sure my reasons for arriving at that conclusion are the opposite of yours.
CANBUS Tx/Rx with data length > 8 bytes
Started by ●November 19, 2015
Reply by ●December 3, 20152015-12-03
Reply by ●December 3, 20152015-12-03
On 03.12.2015 г. 10:52, David Brown wrote:> On 03/12/15 02:36, Dimiter_Popoff wrote: >> On 02.12.2015 г. 22:28, Hans-Bernhard Bröker wrote: >>> Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff: >>>> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote: >>>>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff: >>> >>>>>> Was not so straight forward as SPI is meant to be unidirectional, >>> >>>>> Huh? How do you arrive at classifying a full duplex link like SPI as >>>>> "unidirectional"? >>> >>>> I am not sure how you define full duplex but it _is_ unidirectional >>>> in that the master has no way of knowing - other that the data contents >>>> it receives from the slave - whether the slave had something to say or >>>> not. >>> >>> And I absolutely don't see any sense in which the term "direction" or >>> "directional" could have a relation to what you're saying there. A >>> direction is something like "node A to node B", or "node B to node A". A >>> single SPI link (unless artificially crippled) between A and B already >>> supports both of those directions, fully simultaneously, so I really >>> don't see how you justify calling that "uni-directional." >> >> You should read more carefully if you want to have success at being >> the always know better. >> >> I said SPI was _meant_ to be unidirectional in its use, not that >> it was unidirectionl as you claim I have said. IOW, it is _meant_ to >> be used either as input or as output, not both at the same time >> (e.g. DAC/ADC etc.). > > I don't follow you here. It is common practice to use an SPI bus for > both DACs and ADCs, or other mixes of input and output. It is also > common practice for SPI communication to an ADC to transfer a new > command to the ADC (such as "start reading from mux channel 3") while > simultaneously reading out the previous conversion value.David, I _know_ that. Moreover I have been doing it over the decades, last time I recall (reading an ADC with an input mux as you describe) was about 10 years ago on that thing: http://tgi-sci.com/y2demo/index.htm It is quite obvious what I say in my original message, I'll leave the nitpicking whether "unidirectional" is the best chosen word for that to the always know betters on the list, some of whom (not you) have yet to post a message other than "know better" and yet to demonstrate to have ever done something real and working. 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. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●December 3, 20152015-12-03
On 12/3/15 8:42 PM, Dimiter_Popoff wrote:> It is quite obvious what I say in my original message, I'll leave the > nitpicking whether "unidirectional" is the best chosen word for that > to the always know betters on the list, some of whom (not you) have > yet to post a message other than "know better" and yet to demonstrate > to have ever done something real and working. > Dimiter >I think the concept you are thinking of is SPI is a 'Single Master' method. Buses like CAN are (at least potentially) 'Multi Master' systems. (And then non-bussed links like a simple serial port are masterless)
Reply by ●December 4, 20152015-12-04
On 04/12/15 02:42, Dimiter_Popoff wrote:> On 03.12.2015 г. 10:52, David Brown wrote: >> On 03/12/15 02:36, Dimiter_Popoff wrote: >>> On 02.12.2015 г. 22:28, Hans-Bernhard Bröker wrote: >>>> Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff: >>>>> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote: >>>>>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff: >>>> >>>>>>> Was not so straight forward as SPI is meant to be unidirectional, >>>> >>>>>> Huh? How do you arrive at classifying a full duplex link like SPI as >>>>>> "unidirectional"? >>>> >>>>> I am not sure how you define full duplex but it _is_ unidirectional >>>>> in that the master has no way of knowing - other that the data >>>>> contents >>>>> it receives from the slave - whether the slave had something to say or >>>>> not. >>>> >>>> And I absolutely don't see any sense in which the term "direction" or >>>> "directional" could have a relation to what you're saying there. A >>>> direction is something like "node A to node B", or "node B to node >>>> A". A >>>> single SPI link (unless artificially crippled) between A and B already >>>> supports both of those directions, fully simultaneously, so I really >>>> don't see how you justify calling that "uni-directional." >>> >>> You should read more carefully if you want to have success at being >>> the always know better. >>> >>> I said SPI was _meant_ to be unidirectional in its use, not that >>> it was unidirectionl as you claim I have said. IOW, it is _meant_ to >>> be used either as input or as output, not both at the same time >>> (e.g. DAC/ADC etc.). >> >> I don't follow you here. It is common practice to use an SPI bus for >> both DACs and ADCs, or other mixes of input and output. It is also >> common practice for SPI communication to an ADC to transfer a new >> command to the ADC (such as "start reading from mux channel 3") while >> simultaneously reading out the previous conversion value. > > David, I _know_ that. Moreover I have been doing it over the decades, > last time I recall (reading an ADC with an input mux as you describe) > was about 10 years ago on that thing: > > http://tgi-sci.com/y2demo/index.htm > > It is quite obvious what I say in my original message, I'll leave the > nitpicking whether "unidirectional" is the best chosen word for that > to the always know betters on the list, some of whom (not you) have > yet to post a message other than "know better" and yet to demonstrate > to have ever done something real and working.I think it is fairly clear that "unidirectional" was a /bad/ choice of words here - and the result that your original message was not obvious. I have no doubts at all that you understand how SPI works, and how it can be used - it is merely a miscommunication. Even though you call that "nitpicking", remember that posts in a newsgroup are for everyone, and they are archived and searchable for future users. What is a mere minor error amongst experienced developers can confuse other less experienced developers - so it is worth correcting such mistakes. What is unfortunate is that instead of a "I don't think you wrote what you meant to write" correction, it was more "You are completely wrong" - and tempers have flared, insults have flown (and been treated more seriously than they were meant, I believe). With a bit of luck, it can all end now.> > 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.
Reply by ●December 4, 20152015-12-04
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/
Reply by ●December 4, 20152015-12-04
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.
Reply by ●December 4, 20152015-12-04
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/
Reply by ●December 4, 20152015-12-04
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.
Reply by ●December 4, 20152015-12-04
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? > > DimiterYears 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
Reply by ●December 4, 20152015-12-04
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.
