On 28/09/18 13:21, mngr wrote:
edited from 0x20000000 to 0x3F000000
and now the raspberry loads the hal_spi module. hal_spi.c
should check the Pi version in a similar way to hal_gpio.c
.
Well done.
There were no other Pi versions when it was written.
Would you like to submit a PR?
Cut and paste the hal_gpio.c code that version checks into hal-spi.c
and test that.
Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha
scritto:
The cpuinfo information says BCM2835 for any raspberry
version you can have, this helps with something in the
kernel, the revision is the filed actually accurate.
The first version of RPi have the base address at 0x20000000
from RPi 2 on it is at 0x3F000000
hal gpio recognize this difference, hal_spi does not, I
still have to run hal gpio, though, will do it in next
days
Other says to have a SPI driver for the 2710
(aka 2837) but it is hard to find the code, in case I will
try to ask directly to them
Il giorno lunedì 24 settembre 2018 11:41:53 UTC+2, Schooner
ha scritto:
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+...@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.
|