On 28/09/18 16:06, mngr wrote:
Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha
scritto:
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?
sure thing!
I have just seen that after modifying naively
BCM2835_PERI_BASE the chip select stops working.
there is some part of hal_spi that I don't understand: a
very lot of costants in hal_spi.h are not used;
It can only have been written for v1 or v2, probably not v2B given
its date of writing.
I have not heard anything of the guy who wrote it for some years
either.
I see it is related to pin_out hal pin, but... how was it
designed?
Cut and paste the
hal_gpio.c code that version checks into hal-spi.c and test
that.
I only have rasppberry 3B on my desk, so I only can test on
it.
That's fine, we know it worked with earlier versions, if it can
detect a v3B and change the main base address accordingly
so that it works, it will be improved
If the BCM2835_PERI_BASE works, then leave as is.
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+...@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.
|
