On Tuesday 30 May 2017 15:00:31 Chris Albertson wrote: > Gene, > > So many words here I can't see the problem. If if you are trying to > reliably export the P's screen to your "your computer" You might just > skip trying to use X11 and go with VNC. I run a VNC server on my > Pi3 and it has been running continuously now for about a month. When > I log in from my iMac I get a graphic session. > > If you are god with Google. Stop reading here and just Goole "VNC".
I've thought of that, and the 2nd or 3rd message I read is squawking about the lag. > > The down side of VNC is the lag. It's very noticeable . VNC is the > same technology Both Microsoft and Apple use for their remote desktop > products. There are a number of implementations of VNC both server and > client some open source, some closed but zero cost and some > commercial. Some Windows versions ship with it installed. > You are talking windows Chris. Only ones I have here are made of glass. M$ products are verboten at the coyote.den. > It does not depend on X11, so you can do tricks like have the Windows > 10 desktop showing in the Pi or vice versa and it works even over the > Internet. Technical support people use it to debug user problems In > fact if you have VNC server running on the Pi, some expert 1,000 miles > away could look at your Pi, even while you were logged on. > > But did I warn you about lag? It's so bad VNC uses a double cursor, > one moves in real time the other shows what the remote computer > thinks, they seem to be connected by a bungee cord. I don't know as I could tolerate that. > > One other good thing: I have VNC client on my iPad. So I can walk > around and access the Pi3 with no wires. Works for simple things > within limits of 7 inch screen and glass keyboard. Works on iPhone > too but tiny screen is useless. > > Google for details but steps are to (1) install VNC server on one > computer, make sure it runs at boot timed (2) install client on > computer #2 then from menu select first computer or type in IP address > if not on menu. I suggest the first experiments be done on two > computers you are comfortable with, maybe you Linux desktop and your > Windows box. THEN try on there Pi. > > Al that said, for me, ssh works perfect with zero lag. Also I can > export ONE app from Pi to iMac (not the entire desktop session) and it > work lag-free also. My Pi is using a wired Ethernet connection. So is mine. And I've not figured out yet how to stop whatever it is thats bringing wlan0 up at boot. I'd remove its execute rights. This one is not behind alu siding, so its attackable, successfully, by a neighbor that I've not been able to ident. > On Tue, May 30, 2017 at 10:07 AM, Gene Heskett <ghesk...@shentel.net> wrote: > > On Tuesday 30 May 2017 08:20:38 Bertho Stultiens wrote: > > > On 05/30/2017 02:32 AM, Bertho Stultiens wrote: > > > > After some digging I noticed that there might be a data-barrier > > > > problem, where peripheral register access can become > > > > out-of-order. The ARM has the __sync_synchronize() (via gcc) to > > > > insert DMB (data-memory-barrier) instructions when you need to > > > > guarantee ordering. Inserting DMB made things worse, such that > > > > sometimes the setup is 32MHz and sometimes 50MHz. Well, > > > > actually, it exposes a deeper problem. > > > > > > I suddenly realized that the SPI peripheral is configured and > > > accessed in userspace. That will fail miserably if not extremely > > > careful, especially on SMP. > > > > > > However, there already is a solution for this! The linux kernel > > > has a SPI driver, which is quite good (used it before). It solves > > > all the userspace problems and, to say the least, some very clever > > > people have had a crack at this problem before. > > > > > > So, drop userspace access to the hardware and use the kernel > > > interface. > > > > > > 1 - run raspi-config and enable the kernel SPI driver -> reboot > > > 2 - you should now have /dev/spidev0.[01] > > > 3 - replace the hm2_rpspi.c file in src/hal/drivers/mesa-hostmot2/ > > > with the one attached > > > 4 - recompile > > > 5 - run > > > > > > Gene, with my (4GB) SD image do (you know the cmdline): > > > - run raspi-config to enable the kernel SPI driver and reboot > > > - save attached file on SD card as hm2_rpspi.c.new > > > $ cp hm2_rpspi.c.new > > > linuxcnc-git/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c $ cd > > > linuxcnc-git/src > > > $ make > > > $ sudo make setuid > > > $ ../scripts/linuxcnc -v > > > ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini > > > > Well, I am still trying to figure out how to run linuxcnc w/o a gfx > > screen. > > > > I followed the above instructions when it wouldn't run the first > > time, and now I get a somewhat different message, so lemme see if I > > can log in from here and duplicate the results, at least to the > > interesting part. > > > > pi@pionsheldon:~/linuxcnc-git/scripts > > $ ./linuxcnc -v ../../linuxcnc/configs/sheldon-lathe/7i90-axis.ini > > Verbose mode on > > RUN_IN_PLACE=yes > > LINUXCNC_DIR= > > LINUXCNC_BIN_DIR=/home/pi/linuxcnc-git/bin > > LINUXCNC_TCL_DIR=/home/pi/linuxcnc-git/tcl > > LINUXCNC_SCRIPT_DIR= > > LINUXCNC_RTLIB_DIR=/home/pi/linuxcnc-git/rtlib > > LINUXCNC_CONFIG_DIR= > > LINUXCNC_LANG_DIR=/home/pi/linuxcnc-git/src/objects > > INIVAR=inivar > > HALCMD=halcmd > > LINUXCNC_EMCSH=/usr/bin/wish8.6 > > LINUXCNC - 2.8.0~pre1 > > Machine configuration directory > > is > > '/home/pi/linuxcnc-git/scripts/../../linuxcnc/configs/sheldon-lathe' > > Machine configuration file is '7i90-axis.ini' > > INIFILE=/home/pi/linuxcnc-git/scripts/../../linuxcnc/ > > configs/sheldon-lathe/7i90-axis.ini > > VERSION=1.0 > > PARAMETER_FILE=hm2-stepper.var > > TASK=milltask > > HALUI= > > DISPLAY=axis > > COORDINATES=X Z > > KINEMATICS=trivkins coordinates=XZ > > Starting LinuxCNC... > > Starting LinuxCNC server program: linuxcncsvr > > Loading Real Time OS, RTAPI, and HAL_LIB modules > > Starting LinuxCNC IO program: io > > Found file(REL): ./hm2-7i90-stepper.hal > > Note: Using POSIX realtime > > hm2: loading Mesa HostMot2 driver version 0.15 > > hm2_rpspi: spiclk=32000000 Hz > > hm2_rpspi: Invalid cookie > > hm2_rpspi: Read: 00000000 00000000 00000000 00000000 > > hm2_rpspi: rtapi_app_main: No such device (-19) > > ./hm2-7i90-stepper.hal:32: waitpid > > failed /home/pi/linuxcnc-git/bin/rtapi_app hm2_rpspi > > ./hm2-7i90-stepper.hal:32: /home/pi/linuxcnc-git/bin/rtapi_app > > exited without becoming ready > > ./hm2-7i90-stepper.hal:32: insmod for hm2_rpspi failed, returned -1 > > Shutting down and cleaning up LinuxCNC... > > Killing task linuxcncsvr, PID=690 > > hm2_rpspi: not loaded > > <commandline>:0: exit value: 255 > > <commandline>:0: rmmod failed, returned -1 > > hm2: unloading > > <commandline>:0: unloadrt failed > > Removing HAL_LIB, RTAPI, and Real Time OS modules > > Note: Using POSIX realtime > > Removing NML shared memory segments > > LinuxCNC terminated with an error. You can find more information in > > the log: > > /home/pi/linuxcnc_debug.txt > > and > > /home/pi/linuxcnc_print.txt > > as well as in the output of the shell command 'dmesg' and in the > > terminal pi@pionsheldon:~/linuxcnc-git/scripts $ > > > > Is that 14 pf cap to ground on the spi-clk0 now screwing it up? > > > > On the first attempt, the error wording seemed to indicate it > > couldn't find a display. I wish I'd have thought to capture it. > > > > On the other card, I had 4 workspaces set up on the other card > > before I had increased the framebuffer depth to 24, and I found they > > were still there, just blank screens, and I could make my terminal > > session go away by rolling the mouse wheel, and if I kept rolling > > the same direction it wrapped and put me back on the 1st screen. > > Shade tree engineering at its best. :) Doesn't work now of course. > > > > Your turn, should you choose to accept it. > > > > I'm going to put the other card back in and see if I have a good > > 7i90 under all those 7i42ta's. The one its running on now has some > > blown bus buffers according to Peter. With 4 of them laying about, > > I may have grabbed a bad one. So I'd better check before I bury it > > any deeper. > > > > > I get the result as shown in the images. The advantage is that > > > there are no inter-word delays anymore. The time for chip select > > > to be active varies a bit (16.5 us in image 8 vs. 6.3 us data > > > transfer in image 6). This variability is inherent to the driver > > > how it handles chip select asynchronously. Still, it is an > > > improvement, especially for large transfers. > > > > > > I did add a rtapi module parameter - spiclk - which should set the > > > clock upon load. However, I've not been able to get that to work. > > > Probably something trivial I did wrong. Ah well, at least it runs > > > at a good speed now, also after reboots. > > > > > > My hm2_rpspi driver hack is fixed to /dev/spidev0.0 (CE0 pin). > > > This should be a configurable parameter (features for the future). > > > > 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-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users 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-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
