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