OK, good there is some progress.
You will probably find that whilst loaded, it may not work.
That while statement is actually
while(!( *(spi + 0) & 0x00010000)
which is extremely specific and if something has changed or if SPI
is not enabled, it will hang forever.
(gripe here, I have asked you 3 specific questions and you have not
answered any of them)
On 23/09/18 18:01, mngr wrote:
Thanks for the explanation about machinkit workings,
I played with the stamps and found that it was blocking on
while (!(BCM2835_SPICS &
SPI_CS_DONE)); (Line 438)
removing it halrun loads, now I will see if and what it
writes. maybe I will have to control the low level
implementation... but now I know more things.
One more question, how does a hal module read the args?
Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha
scritto:
Sep 23 15:03:17
realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so default
iparms: ''
Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user :
hal_spi init!!!!err
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user :
hal_spi init!!!!dbg
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user
halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1
arg1=0 arg2=0/0x0
Since you haven't said where these extra prints are located,
their presence means nothing to me
The module is obviously
loading to a point but it does not look as though the driver
is getting any further than hal_init, which calls
halg_xinitfv()
then is failing catastrophically
You are loading with no args, are the defaults suitable for
your board / setup?
Not that it looks that it gets that far, due the complete
absence of other error or info messages
The insmod error is completely non specific, so doesn't
help, may just be picking up the last return value.
What is the output from /proc/cpuinfo and what version etc
is your Pi?
On 23/09/18 16:12, mngr wrote:
Attached.
In the log you can see the message I added in the
hal_spi rtapi_app_main.
pi@realtimepi:~ $ halcmd loadrt hal_spi
<commandline>:0: insmod failed, returned -1:
rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.
pi@realtimepi:~ $ halcmd show all
halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:281
Il giorno domenica 23 settembre 2018 16:43:25
UTC+2, Schooner ha scritto:
On 23/09/18 15:16, mngr wrote:
Il giorno domenica 23 settembre 2018 15:34:58
UTC+2, Schooner ha scritto:
It's
not about doubt
cat /proc/cpuinfo
will tell you whether you have BCM2835
Thanks didn't know about that! on the rpi
is written 2837, bit cpuinfo says 2835!
So at least the part that writes in the SPI
registers should work.
I tried to add some debug message in
hal_spi rtapi_app_main function, but I
don't see them anywhere, I have exported
DEBUG=5, and maximized the DEBUG value in
the ini file. I am looking in
/var/log/linuxcnc.log and in the terminal
output.
I have tried with different msg types
rtapi_print_msg(RTAPI_MSG_ERR, ":
hal_spi init!!!!err\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi
init!!!!dbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi
init!!!!all\n");
There are plenty of error messages in the driver
already. I did not see any in the log however which
makes me
suspect it was never loaded.
If insmod errors it should say why however and that
was not in there either.
Instead of complicating things with loading a non
working config, just to load the driver, try this in
a terminal on your Pi
sudo > /var/log/linuxcnc.log (you may have to run
this a root, it should zero the log)
DEBUG=5 realtime restart
halcmd loadrt hal_spi
halcmd show all
halrun -U
That should give you a short log and if it errors
loading hal_spi will be easier to trace through
In addition to the log do
dmesg | tail > dmesg.log
and attach that log too
If you
do and the driver should work, we can try to
find out why it isn't.
If you don't, what the differences are from
the BCM2837 for example, I have no idea
I am guessing you are trying to generate
steps using the SPI, that is an area outside
my experience
but there seems to be quite a bit about it
on the RPi forums
Actually, I tought that hal_spi is used to
write something to a MCU that will control the
motor generating steps.
I think it sends the commanded velocity and
the MCU updates the PWM.
I am not sure of those things, though
On 23/09/18 13:50, mngr wrote:
Il giorno domenica 23 settembre 2018
13:41:42 UTC+2, Schooner ha scritto:
The log does not show what your
earlier email showed, there is not
mention of an error from insmod
I think you need to get right back to
basics.
This driver was written 5 years ago
and is specific to the BCM2835 chip
It can only have been meant to support
Pi v1 & v2 and maybe not all of
them, as they kept changing versions
and hardware,
because nothing of a higher version
had been released then
Does this driver support your Pi?
In case of doubt I gave a look to
wiringPi, it calls ioctl and write/reads
from /dev/spidev.
Is calling that syscall from a hal
driver a sane thing to do? (It is for
example used here)
Regards DEBUG, the ini file bit was
explained by the text you deleted from
yours.
It takes a hexidecimal number up to
0x7FFFFFFF, the output is to terminal
and the output is from NML messaging
The exported DEBUG=5 is the debug
setting for logging and relates to the
rtapi system, not NML
Thanks for the explanation, Schooner
On 23/09/18 11:07, mngr wrote:
Il giorno venerdì 21 settembre
2018 16:44:50 UTC+2, Schooner ha
scritto:
You are not
running with DEBUG=5
I edited DEBUG = 5 in ini
file(in EMC section), nothing
changed, then I exported DEBUG=5
in bash. what is the difference?
what is the deBUG setting in the
ini file for?
Attached you can find the ini
and the hal file, I edited the
CRAMPS configuration, basically
removing everything relative to
the PRU, and adding loadrt
hal_spi in CRAMPS.hal (and
leaving one only axis)
linuxcnc_old.log is
everything before adding loadrt
hal_spi.
linuxcnc.log is the execution
with loadrt hal_spi and
termila_output shows what has
been written, I attached it
because it talks about
rtapi_rpc(): reply timeout, that
is not mentioned in the log
pi@realtimepi:~ $
uname -a
Linux
realtimepi 4.14.66-rt40-v7 #2
SMP PREEMPT RT Mon Sep
17 21:15:46 UTC 2018
armv7l GNU/Linux
Do so and
your linuxcnc.log will have
info as to what failed.
Also as I said in my last
reply, it does not look as
though you have a realtime
kernel, irrespective of what
you have named your pi.
On 21/09/18 15:31, mngr
wrote:
Hi everyone,
I am sorry to post
another noob question
here, but,
I am trying to use
the hal module hal_spi,
shortly I tried with
CRAMPS.hal:15:
insmod failed, returned -1:
rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.
in the log
Sep 21
14:22:09 realtimepi msgd:0: startup pid=5979 flavor=posix rtlevel=1
usrlevel=1
halsize=524288
shm=Posix
cc=gcc 6.3.0
20170516 version=unknown
Sep 21
14:22:09 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics libwebsockets=2.0.3
Sep 21
14:22:09 realtimepi msgd:0: configured: sha=b87920504
Sep 21
14:22:09 realtimepi msgd:0: built:
Sep 18 2018
16:43:17 sha=b87920504
Sep 21
14:22:09 realtimepi msgd:0: register_stuff: actual hostname as announced by avahi='realtimepi.local'
Sep 21
14:22:09 realtimepi msgd:0: zeroconf: registering: 'Log service on
realtimepi.local
pid 5979'
Sep 21
14:22:10 realtimepi rtapi:0: rtapi_msgd went away, exiting
Sep 21
14:22:10 realtimepi msgd:0: zeroconf: registered 'Log
service on
realtimepi.local
pid 5979' _machinekit._tcp 0
TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=b9c730a2-bda9-11e8-bcc3-b827eb4bcf42" "service=log" "dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"
I tried launching
machinekit without it
and adding it later
using halcmd loadrt
hal_spi, but with
similar results
should I give it some
arguments? I don't know
how to understand how to
write them from the
code...
Maybe the module is
old and has lost some
compatibility?
right now i am
executing from
Linux realtimepi 4.14.69-v7+
#1141
SMP Mon Sep 10
15:26:29 BST
2018 armv7l
GNU/Linux
Debian Stretch,
Machinekit compiled from
source
maybe should I
explicit the path to
hal_spi?
mngr
--
website: http://www.machinekit.io
blog: http://blog.machinekit.io
github: https://github.com/machinekit
---
You received this message
because you are subscribed
to the Google Groups
"Machinekit" group.
To unsubscribe from this
group and stop receiving
emails from it, send an
email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io
blog: http://blog.machinekit.io
github: https://github.com/machinekit
---
You received this message because
you are subscribed to the Google
Groups "Machinekit" group.
To unsubscribe from this group and
stop receiving emails from it, send
an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog:
http://blog.machinekit.io
github: https://github.com/machinekit
---
You received this message because you are
subscribed to the Google Groups "Machinekit"
group.
To unsubscribe from this group and stop
receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are
subscribed to the Google Groups "Machinekit"
group.
To unsubscribe from this group and stop receiving
emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to
the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io
blog: http://blog.machinekit.io
github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google
Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
|
