On Saturday 10 March 2018 12:42:56 Nicklas Karlsson wrote: > I just discovered it take about 200µs to write six bytes of process > data in process RAM via SPI into the LAN9252 chip! It's horrible slow. > I can't figure out they think about then they make SPI protocol like > this. > > Write adresse(s) and read/write as many bytes as needed had been the > most obvious, now there are several commands and wait in between. > Wow! Thats time to call a surveyor and have him set stakes!
But from what little I've fooled with spi, on a pi 3b no less, its many*2 faster than that. I have it writing to a Mesa 7i90HD at 41 megabaud, and reading the responses back from the 7i90HD at 25 megabaud. Sending and receiving in 32 bit packets. The data rate, going either direction is determined by the master, with errors if any determined to have occurred by a simple rx checksum. Data generally goes out to be latched into the slaves on the falling edge of the master generated clock, and comes back in the full duplex mode if its used, or by doing single direction at a time, in any event latched by the master on the riseing edge of the clock. That last may be polarity inverted, its been a while since I last had a scope on the lines. And its difficult to see whats happening since the loading of the usual 7 to 8 pf + 10 megohms scope probe will generally screw the pooch because of its induced errors caused by the lengthening of the t=rc rise/fall times. My interconnecting cable is also only about 2" of signal path long. Longer will no doubt slow it down for the same reason. That spi driver is rpspi.ko, and at the present time, runs ONLY on the pi, and in fact has init code in it that prevents it from running on anything but the pi's. The src code is now in LinuxCNC's src tree, and I believe professor Bertho Stultans, who wrote it, is about burned out because it turned into a much bigger project than he had in mind when he volunteered to see what he could do with it after the original author took a random remark wrong and bailed out. In any event, I'd like to see the pi only stuff expunged from that driver, as it could then be built to run on the arm64's like the rock64, a considerably faster teeny card than the pi will ever be. And now you know as much about the spi bus as I do, IOW not that much... What I've been able to deduce, running on the pi, is that the spi data does NOT have to go thru the pi's internal usb2 hub, something the mouse and keyboard MUST do, and that results in input events being thrown away in the traffic jam caused by this internal hub. There is NO data loss in the spi bus, it Just Works(TM). > On Fri, 2 Mar 2018 08:07:33 -0500 > > Kenneth Lerman <ler...@se-ltd.com> wrote: > > Change the species. > > > > etherCAT becomes etherDOG > > > > Ken > > > > Kenneth Lerman > > 55 Main Street > > Newtown, CT 06470 > > > > > > On Wed, Feb 21, 2018 at 4:51 PM, Nicklas Karlsson < > > > > nicklas.karlsso...@gmail.com> wrote: > > > On Tue, 23 Jan 2018 08:17:52 -0500 > > > > > > Gene Heskett <ghesk...@shentel.net> wrote: > > > > On Tuesday 23 January 2018 08:01:01 andy pugh wrote: > > > > > On 23 January 2018 at 03:26, Rod Webster > > > > > <r...@vehiclemods.net.au> > > > > > > > > wrote: > > > > > > This link seems to confirm the Etherlab invocation is GPLv2 > > > > > > so you may be right! > > > > > > https://etherlab.org/en/ethercat/index.php > > > > > > > > > > Etherlab and SOEM are both GPL (or want to be) > > > > > > > > > > The problem is with Beckhoff who own the EtherCAT trademark > > > > > and technology. > > > > > > > > Then we need to come up with a new name for it, and this > > > > interface chip Nicklas has used offloads the technology aspect. > > > > So it seems to me that should cover those 2 items of concern. I > > > > haven't a clue what to use for a name and anything I would > > > > suggest would disqualify itself based on the clean room > > > > principle. > > > > > > I could name the file "ethercat.c", soem is in a sub folder and > > > set up a new repository on github? Or could I push somewhere else? > > > > > > I created a local fork but needed some method to configure devices > > > and decided a CANopen gateway may be a good solution, it is CiA > > > 309 if I remember correct. > > > > > > > > > Nicklas Karlsson > > > > > > ------------------------------------------------------------ > > > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Emc-developers mailing list > > > Emc-developers@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > -------------------------------------------------------------------- > >---------- Check out the vibrant tech community on one of the world's > > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ---------------------------------------------------------------------- >-------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
