Sure, push the updates.
Il giorno martedì 2 ottobre 2018 15:18:53 UTC+2, Schooner ha scritto:
>
> Good to hear.
>
> It just makes the minimal changes, as it appeared the only thing that had
> changed was the base address.
>
Agree, I was going to a lot more of non-necessary code
> If you are
Good to hear.
It just makes the minimal changes, as it appeared the only thing
that had changed was the base address.
If you are happy with that, I can push a PR, so it is in the
packages.
On 02/10/18 13:39, mngr wrote:
I tested
I tested your branch, everything is working fine, it loads and the spi
writes.
Il giorno domenica 30 settembre 2018 22:55:45 UTC+2, mngr ha scritto:
>
> It will probably take me more of a evening because the next couple of days
> is already full. Maybe I will test your version and then make
It will probably take me more of a evening because the next couple of days is
already full. Maybe I will test your version and then make another pr to unify
hal_spi.h and bcm2835.h
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
OK,
Hear from you in a bit
On 30/09/18 18:15, mngr wrote:
I lacked attention, I thought you imported cpuinfo.h
rebuilded and now it runs, but I still need to edit
something more to make it work
nm shows that both
I lacked attention, I thought you imported cpuinfo.h
rebuilded and now it runs, but I still need to edit something more to make
it work
nm shows that both get_cpuinfo_revision() and get_rpi_revision() are defined
anyway, it reads correctly giving number cores as 4 and revision as 4.
I will give
On 30/09/18 16:59, mngr wrote:
A young guy just learned how beautiful commit diffs are
here is a link to the diffs!
https://github.com/machinekit/machinekit/compare/master...mngr0:master
A young guy just learned how beautiful commit diffs are
here is a link to the diffs!
https://github.com/machinekit/machinekit/compare/master...mngr0:master
I have been very sticky to the workings in hal_gpio.c,
and the changes in hal_spi.h are not really necessary, but I think it
should be
See https://github.com/ArcEye/machinekit/tree/hal_spi_base
I have used the simplest strategy.
As only the _PERI_BASE seems to be different, I have changed the
#define to an unsigned int variable.
This is then set to either 0x2000 or 0x3F00 depending
OK, I'll have a look tomorrow
Won't be able to test so I'll be back to you :)
On 29/09/18 17:56, mngr wrote:
https://github.com/mngr0/machinekit
Il giorno sabato 29 settembre 2018 18:50:47 UTC+2, Schooner ha
https://github.com/mngr0/machinekit
Il giorno sabato 29 settembre 2018 18:50:47 UTC+2, Schooner ha scritto:
>
> Can you link to a github repo with this in? I will look tomorrow.
>
> You have probably declared something as extern or otherwise done enough to
> satisfy the compiler, but not
Can you link to a github repo with this in? I will look tomorrow.
You have probably declared something as extern or otherwise done
enough to satisfy the compiler, but not actually linked it or
similar.
Each driver probably needs to have all the routines and
i have copied all the function and recompiled,
now when i run realtime start; halcmd loadrt hal_spi an error says
do_load_cmd: dlopen: /home/pi/machinekit/rtlib/rt-preempt/hal_spi.so:
undefined symbol: get_rpi_revision
rpath=/home/pi/machinekit/rtlib/rt-preempt:/home/pi/machinekit/lib
it does
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
Il giorno venerdì 28 settembre 2018 15:10:04 UTC+2, Schooner ha scritto:
>
>
> On 28/09/18 13:21, mngr wrote:
>
> edited from 0x2000 to 0x3F00 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.
>
>
On 28/09/18 13:21, mngr wrote:
edited from 0x2000 to 0x3F00
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
edited from 0x2000 to 0x3F00 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 .
Il giorno mercoledì 26 settembre 2018 12:33:31 UTC+2, mngr ha scritto:
>
> The cpuinfo information says BCM2835 for any raspberry version
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 0x2000 from RPi 2 on
it is at 0x3F00
hal gpio recognize this difference,
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
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
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) & 0x0001)
which is extremely specific and if something has changed or if SPI
is not enabled, it will hang
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
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
initerr
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi
initdbg
Sep 23 15:03:17
Attached.
In the log you can see the message I added in the hal_spi rtapi_app_main.
pi@realtimepi:~ $ halcmd loadrt hal_spi
: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
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
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
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
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
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 are not running with DEBUG=5
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
30 matches
Mail list logo
