Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Gene Heskett 
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  
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-l

Re: [Emc-users] the saga of gene vs pi's continues

2017-05-30 Thread Gene Heskett 
On Tuesday 30 May 2017 14:05:15 John Thornton wrote:

> I hear you Gene, while I can't remember anything from 1940 for obvious
> reasons I can remember things from late 50's like sledding down a road
> with a rather large rock at the sharp turn a the bottom... again with
> the obvious results. The one thing that Dad hated the most was loosing
> his memory and I feel the same way. It's frustrating to get up from
> your chair and walk from the machine shop to the garage and forget why
> you did...
>
> JT
>
Thats called worrying about the hereafter John, you get there, and then 
you can't remember what you came here after. :(

Seems like its happening more and more as the years fly by.  When I was 
65, & beginning to think about retiring, which it took me another 21 
months to do, I had no expectation of still being here 17+ years later 
and in fairly good mental health. (I think)  But not so good physically, 
scoliosis has crept up on me, combined with collapsing disks, so I'm 
about 5 to 6" shorter than I was at 25.  But we've found a pill that 
helps with the sciatic pain, so I can keep on keep'in on most of the 
time.  I'm ok, as long as I can do it at "my" speed. :)

> On 5/30/2017 1:56 AM, Gene Heskett wrote:
> > Short term memory is getting worse
> > all the time.  I can recall something from the 1940's easier than
> > what if anything, I had for breakfast this morning.  Upsetting to
> > put it in mixed company language...
>
> --
> 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 

--
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

Re: [Emc-users] emc2 openProfibus

2017-05-30 Thread andy pugh 
On 30 May 2017 at 16:59, theman whosoldtheworld  wrote:
> I discover that CC-Link is tipycal "open project" but for people who pay
> ... so i search for other industrial bus

Well

At least one other project (STMBL) is using the Mesa Smart-Serial
protocol. (in addition to the Mesa cards, of course).
It's not any sort of industrial standard, but it does seem to be fairly Open.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Chris Albertson 
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".



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.

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.

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.



On Tue, May 30, 2017 at 10:07 AM, Gene Heskett  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=
>

Re: [Emc-users] New kind of stepper motor on eBay

2017-05-30 Thread Fox Mulder 
Am 29.05.2017 um 10:36 schrieb Lester Caine:
> On 28/05/17 05:51, Fox Mulder wrote:
>> Looks to me just like a stepper motor with integrated motor driver without 
>> feedback. Maybe the Mechaduino is more like a closed-loop stepper-servo. I 
>> have ordered some PCBs from DirtyPcb and will assemble them when they 
>> arrive. Hope they are as good as announced.
>>
>> https://www.kickstarter.com/projects/tropicallabs/mechaduino-powerful-open-source-industrial-servo-m
> 
> Has the latest batch of boards already sold out ?
> 
Seems so. I ordered bare PCBs which i have to equip myself with the
corresponding parts.

--
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

Re: [Emc-users] the saga of gene vs pi's continues

2017-05-30 Thread John Thornton 
I hear you Gene, while I can't remember anything from 1940 for obvious 
reasons I can remember things from late 50's like sledding down a road 
with a rather large rock at the sharp turn a the bottom... again with 
the obvious results. The one thing that Dad hated the most was loosing 
his memory and I feel the same way. It's frustrating to get up from your 
chair and walk from the machine shop to the garage and forget why you did...


JT

On 5/30/2017 1:56 AM, Gene Heskett wrote:

Short term memory is getting worse
all the time.  I can recall something from the 1940's easier than what
if anything, I had for breakfast this morning.  Upsetting to put it in
mixed company language...



--
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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Gene Heskett 
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=3200 Hz
hm2_rpspi: Invalid cookie
hm2_rpspi: Read:    
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
:0: exit value: 255
:0: rmmod failed, returned -1
hm2: unloading
: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 t

[Emc-users] emc2 openProfibus

2017-05-30 Thread theman whosoldtheworld 
I discover that CC-Link is tipycal "open project" but for people who pay
... so i search for other industrial bus ... open-powerlink .. rt-space
works on kernel 4.4 (first step of test) ... now more difficult test ...
isol cpu on emc2 and isol cpu on powerlink ...
If any one have other experience about open-powerlink ... can write.

bkt
--
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

Re: [Emc-users] [it was CC-Link emc2] becomes: gmail web Vs. Tbird local

2017-05-30 Thread theman whosoldtheworld 
personally I have nothings against both ...
But is possible to talk about your experiences on the matter.


bkt


2017-05-30 17:10 GMT+02:00 Dave Cole :

> On 5/27/2017 7:53 AM, Mark wrote:
>
>> On 05/26/2017 06:15 PM, andy pugh wrote:
>>
>>>
>>> It's too late, I have been using Gmail exclusively for many years. (I
>>> like how it threads mailing lists).
>>>
>>
>> Ditto, though I refuse to use the web interface.  I download my emails to
>> Thunderbird on my local laptop, an HP running Ubuntu 16.04 LTS.  Have
>> experienced no problems, and no ads.
>>
>> Mark
>>
>>
>>
> I do the same thing except I run Thunderbird on Windows.   I think I have
> 6 gmail accounts.   One for each list, so they are easy to maintain. It
> works well.   No adds.   I rarely use their web interface.
>
> Dave
>
>
> 
> --
> 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
>
--
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

Re: [Emc-users] CC-Link emc2

2017-05-30 Thread Dave Cole 

On 5/27/2017 7:53 AM, Mark wrote:

On 05/26/2017 06:15 PM, andy pugh wrote:


It's too late, I have been using Gmail exclusively for many years. (I
like how it threads mailing lists).


Ditto, though I refuse to use the web interface.  I download my emails 
to Thunderbird on my local laptop, an HP running Ubuntu 16.04 LTS.  
Have experienced no problems, and no ads.


Mark




I do the same thing except I run Thunderbird on Windows.   I think I 
have 6 gmail accounts.   One for each list, so they are easy to 
maintain. It works well.   No adds.   I rarely use their web interface.


Dave

--
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

Re: [Emc-users] RPI saga continues - SPI probably [not] solved

2017-05-30 Thread Bertho Stultiens 
On 05/30/2017 02:28 PM, Jeff Epler wrote:
> We already have a driver for hostmot2 that uses /dev/spidev*,
> hm2_spi.  hm2_rpspi exists because its contributor stated that on
> their system, hm2_spi did not perform adequately.

That reminds me of setting scheduling/cpu affinity. Maybe the solution
can be simpler.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Bertho Stultiens 
On 05/30/2017 02:28 PM, Jeff Epler wrote:
>> 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.
> [snip]
> 
> We already have a driver for hostmot2 that uses /dev/spidev*,
> hm2_spi.  hm2_rpspi exists because its contributor stated that on
> their system, hm2_spi did not perform adequately.

My guess is that it was on a Pi2. The Pi3 should perform better. The
problem is that you cannot control the SMP behavior correctly from
userspace, unless all interrupts are disabled and caching is taken into
account.

The only performance issue I can see is the asynchronous chip select.
The original code in the hm2_rpspi is significantly slower in transfers
due to synchronous write/read sequences.

-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Jeff Epler 
On Tue, May 30, 2017 at 02:20:38PM +0200, Bertho Stultiens wrote:
> 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.
[snip]

We already have a driver for hostmot2 that uses /dev/spidev*,
hm2_spi.  hm2_rpspi exists because its contributor stated that on
their system, hm2_spi did not perform adequately.

Jeff

--
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

Re: [Emc-users] RPI saga continues - SPI probably solved

2017-05-30 Thread Bertho Stultiens 
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

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).

-- 
Greetings Bertho

(disclaimers are disclaimed)
/*This is a component for RaspberryPi to hostmot2 over SPI for linuxcnc.
 *Copyright 2016 Matsche 
 *Copyright 2017 B.Stultiens 
 *
 *This program is free software; you can redistribute it and/or modify
 *it under the terms of the GNU General Public License as published by
 *the Free Software Foundation; either version 2 of the License, or
 *(at your option) any later version.
 *
 *This program is distributed in the hope that it will be useful,
 *but WITHOUT ANY WARRANTY; without even the implied warranty of
 *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *GNU General Public License for more details.
 *
 *You should have received a copy of the GNU General Public License
 *along with this program; if not, write to the Free Software
 *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

/* Without Source Tree */
#undef WOST

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include "hal.h"
#include "rtapi.h"
#include "rtapi_app.h"

#include "rtapi_stdint.h"
#include "rtapi_bool.h"
#include "rtapi_gfp.h"

#include "rtapi_bool.h"

#if defined (WOST)
#include "include/hostmot2-lowlevel.h"
#include "include/hostmot2.h"
#else
#include "hostmot2-lowlevel.h"
#include "hostmot2.h"
#endif

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Matsche");
MODULE_DESCRIPTION("Driver for HostMot2 devices connected via SPI to RaspberryPi");
MODULE_SUPPORTED_DEVICE("Mesa-AnythingIO-7i90");

#define MAX_BOARDS	1		// XXX: cannot be anything else than 1 at the moment
#define MAX_MSG		512

typedef struct hm2_rpspi_struct {
	hm2_lowlevel_io_t llio;
	int nr;
	uint32_t txBuf[MAX_MSG];
	uint32_t rxBuf[MAX_MSG];
	int spiclk;
	int spifd;
} hm2_rpspi_t;

static char *config[MAX_BOARDS];
static int spiclk = 3200;

RTAPI_MP_ARRAY_STRING(config, MAX_BOARDS, "config string for the AnyIO boards (see hostmot2(9) manpage)")
RTAPI_MP_INT(spiclk, "SPI clock frequency in Hz, default 3200 Hz)");

static hm2_rpspi_t boards[MAX_BOARDS];
static int comp_id;

static int spi_open(const char *dev, int mode, int speed, int wsize)
{
	int fd;

	if(-1 == (fd = open(dev, O_RDWR|O_NOCTTY))) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: open: %s", dev, strerror(errno));
		return -1;
	}

	if(-1 == ioctl(fd, SPI_IOC_WR_MODE, &mode)) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: ioctl: SPI_IOC_WR_MODE: %s", dev, strerror(errno));
		close(fd);
		return -1;
	}

	if(-1 == ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &wsize)) {
		rtapi_print_msg(RTAPI_MSG_ERR, "hm2_rpspi: %s: ioctl: SPI_IOC_WR_BITS_PER_WORD: %s", dev,

Re: [Emc-users] the saga of gene vs pi's continues

2017-05-30 Thread Gene Heskett 
On Tuesday 30 May 2017 02:06:38 Erik Christiansen wrote:

> On 29.05.17 16:58, Gene Heskett wrote:
> > Now, a fat32 file system (/boot) has no concept of making a file
> > immutable that I know of, so how can I protect the kernel.img and
> > kernel7.img's from being replaced by non-realtime crap from raspian?
>
> If you don't format fat32 for any reason other than giving the media
> away, then there is no fat problem. Even if /boot is on the SD card,
> that's not a great reason to use a crippled file format in a *nix
> environment. For USB sticks & SD cards, I'm using:
>
> Plug it in, and wait for automounting to complete, then:
> # mount # To see what /dev/s??? it is.
> # umount# So we can format it.
> # mkfs.ext3 /dev/s???
>
> If there's a better treatment for fat32, then I haven't yet heard of
> it, except perhaps for going to ext4. (Haven't tried that yet.)
>
> ...
>
> > Now, following along in man apt_preferences, I've written a pin file
> > and placed it in /etc/apt/preferences.d as "kernel.list" that reads
> > like this:
> >
> > Package: linux-kernel
> > Pin: version 4.4.9-rt17-v7+
> > Pin-Priority: 1001
> >
> > Package: linux-headers
> > Pin: version 4.4.9-rt17-v7+
> > Pin-Priority: 1001
> >
> > Maybe dpkg will obey? Apt and apt-get should.
>
> Now that's hopefully a gremlin-proof fence. (But watch out for
> Murphy's pigs.) ;-) As apt-get is quite convenient for
> installs/updates, it's probably worth cultivating the habit of using
> that.
>
> ...
>
> > It would be nice if all these detours didn't get in the way. :)
>
> Yebbut, now you're a pinning guru. (I've just taken a quick look at
> "man apt_preferences", and it suggests that /etc/apt/preferences is
> 'where you could specify "pinning"'. It seems to use the same syntax
> as you have, though. If I can avoid having to discover what e.g.
> "kernel.list" filename to use, then the apparently simpler single file
> approach suits me, lower on that learning curve)
>
> Erik

Well, apt just told me I named the file wrong.  For a change its not 
a .list, its either no extension or .pref. No complaints after I mv'd it 
to "kernel.pref"  That little tidbit of info is in the man page, but 
about 2 paragraphs up from the examples. I had to actually read the 
thing, horrors.  Its one of those man pages that almost fits the TL;DR 
category. One other tidbit is that they are read alphabetically, and 
last one governs. So I'm wondering if I should mv the file to 
z.prefs. ;-)

My bigger problem is that I may now be a pinning guru, but by this time 
next week, I may have forgotten it.  Short term memory is getting worse 
all the time.  I can recall something from the 1940's easier than what 
if anything, I had for breakfast this morning.  Upsetting to put it in 
mixed company language...

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 

--
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