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+unsubscr...@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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
|
