Well, despite what /proc/cpuinfo says, I don't see how it can be a
BCM2835 Soc.
The elinux hardware history (https://elinux.org/RPi_HardwareHistory)
clearly shows the v3 B has a BCM2037 and even if you
were sold an almost identical v2 B purporting to be a v3 B, it would
have a BCM2036.
Looks like it is testing CS (chip select) to see if it is in an
active state and waiting until it is?
Hence my question about whether SPI was activated.
The most likely sources of the problem are either that SPI is
inactive or
that whatever address *spi points to it does not contain what is
expected so the & test will never result as expected.
This in turn makes one suspicious about what will happen when the
driver is attached to a thread and started.
Will it work?
It might be useful to try to get the hal_gpio demo running on the
board with DEBUG set and look at the output.
Regards the args, that is peculiar. Just ignore the print out.
Look at hal_gpio.c for an example of how RTAPI_MP_STRING should
appear, and then you can see them being used in the later code.
If there is any initialisation to be done it would normally be in
rtapi_app_main()
You need to find someone who is up on bit twiddling on the v3 B and
check all the addresses and offsets with them.
(Particularly the SPI_BASE offset, which may or may not vary between
models of Soc)
On 23/09/18 20:35, mngr wrote:
I am really sorry Schooner, I was excited about the
findings...
I actually don't know which args suits my setup, I looked
in the source, but I don't know how to find where they are
used,
I tried to scroll it all, but found no place that seems to
use them.
My board is a Raspberry Pi 3 model B V 1.2 and attached
you can find the cpuinfo output
Spi is enabled from raspi-config, and in /dev there is
spidev0.0 and spidev0.1
Il giorno domenica 23 settembre 2018 19:35:25 UTC+2, Schooner ha
scritto:
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 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.
|