Re: [Machinekit] using hal_spi module

[mngr]

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 happy with that, I can push a PR, so it is in the packages.
>
>
> On 02/10/18 13:39, mngr wrote:
>
> 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 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
> --- 
> 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.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 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 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
  --- 
  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.

Re: [Machinekit] using hal_spi module

[mngr]

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 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
--- 
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.

Re: [Machinekit] using hal_spi module

[mngr]

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
--- 
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.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 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 some time trying to patch my version, if it is
  too hard I will clone and test yours





Il giorno domenica 30 settembre 2018 18:23:39 UTC+2, Schooner ha
scritto:

   
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



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 removed, to be
  more consistent with hal_gpio, and to use bcm2835.h
  more (this requires work on hal_spi.c)



it compiles, but while executing it has some
  problem in finding get_rpi_revision,
  


That should not be so

You got that error because you only included cpu_info.h but
nothing else.
I included the actual code by using
#include "cpu_info.c"

When I do a check on the module my code produced and the
functions defined I get

root@INTEL-i7:/usr/src/machinekit/rtlib/rt-preempt# nm
-C hal_spi.so
5370 b accum
5358 b accum_diff
53a0 b BCM2835_PERI_BASE
 U cl...@@GLIBC_2.2.5
52d8 b comp_id
52c0 b completed.7389
 w __cxa_finalize@@GLIBC_2.2.5
11a0 t deregister_tm_clones
1210 t __do_global_dtors_aux
4e08 t __do_global_dtors_aux_fini_array_entry
50d0 d __dso_handle
52e0 b dt
4e10 d _DYNAMIC
 U fcl...@@GLIBC_2.2.5
 U fe...@@GLIBC_2.2.5
 U fg...@@GLIBC_2.2.5
2fdc t _fini
 U fo...@@GLIBC_2.2.5
1250 t frame_dummy
4e00 t __frame_dummy_init_array_entry
3760 r __FRAME_END__
12e0 t get_cpuinfo_revision
1422 t get_rpi_revision


So get_cpuinfo_revision() and get_rpi_revision()
are both in the text section of the module and are local to
it.

If they were undefined they would have a U in front of them

Are you somehow trying to run your old module again?

Run the nm command above on your module.


  
 
any suggestion to help hal_spi dinamically link
  this?



maybe a issue or pull request on github may be a
  more relevant place for this discussion?





Il giorno domenica 30 settembre 2018 16:22:51 UTC+2,
Schooner ha scritto:

   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 upon version detected.

Just added code for number_of_cores() and included
cpu_info.c to get the others.

It builds but needs testing

If you get problems, add some DBG prints to see what

Re: [Machinekit] using hal_spi module

[mngr]

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 some time trying to patch my version, if it is too hard I will 
clone and test yours


Il giorno domenica 30 settembre 2018 18:23:39 UTC+2, Schooner ha scritto:
>
>
> 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
>
> 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 removed, to be more consistent with hal_gpio, and to use 
> bcm2835.h more (this requires work on hal_spi.c)
>
> it compiles, but while executing it has some problem in finding 
> get_rpi_revision,
>
>
> That should not be so
>
> You got that error because you only included cpu_info.h but nothing else.
> I included the actual code by using
> #include "cpu_info.c"
>
> When I do a check on the module my code produced and the functions defined 
> I get
>
> root@INTEL-i7:/usr/src/machinekit/rtlib/rt-preempt# nm -C hal_spi.so
> 5370 b accum
> 5358 b accum_diff
> 53a0 b BCM2835_PERI_BASE
>  U cl...@@GLIBC_2.2.5 
> 52d8 b comp_id
> 52c0 b completed.7389
>  w __cxa_finalize@@GLIBC_2.2.5
> 11a0 t deregister_tm_clones
> 1210 t __do_global_dtors_aux
> 4e08 t __do_global_dtors_aux_fini_array_entry
> 50d0 d __dso_handle
> 52e0 b dt
> 4e10 d _DYNAMIC
>  U fcl...@@GLIBC_2.2.5 
>  U fe...@@GLIBC_2.2.5 
>  U fg...@@GLIBC_2.2.5 
> 2fdc t _fini
>  U fo...@@GLIBC_2.2.5 
> 1250 t frame_dummy
> 4e00 t __frame_dummy_init_array_entry
> 3760 r __FRAME_END__
> 12e0 t get_cpuinfo_revision
> 1422 t get_rpi_revision
> 
>
> So *get_cpuinfo_revision(*) and *get_rpi_revision()* are both in the text 
> section of the module and are local to it.
>
> If they were undefined they would have a U in front of them
>
> Are you somehow trying to run your old module again?
>
> Run the nm command above on your module.
>
> any suggestion to help hal_spi dinamically link this?
>
> maybe a issue or pull request on github may be a more relevant place for 
> this discussion?
>
>
> Il giorno domenica 30 settembre 2018 16:22:51 UTC+2, Schooner ha scritto: 
>>
>> 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 upon 
>> version detected.
>>
>> Just added code for number_of_cores() and included cpu_info.c to get the 
>> others.
>>
>> It builds but needs testing
>>
>> If you get problems, add some DBG prints to see what revision and number 
>> of cores is being returned
>>
>> regards
>>
>> 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 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 actually linked it or similar.
>>>
>>> Each driver probably needs to have all the routines and info within it.
>>>
>>> On 29/09/18 17:41, mngr wrote:
>>>
>>> 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 not happen if I run halcmd loadrt hal_gpio
>>>
>>>
>>> then I have seen that there is bcm26835.h that unify all the useful 
>>> definitions, it would be nice if hal_spi.h was removed since it duplicates 
>>> definitions.
>>> the only problem is that hal_spi.h defines the register addresses, while 
>>> bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified.
>>>
>>>
>>>
>>> Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: 

 On 28.09.18 17:16, schoo...@gmail.com wrote: 
 > 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. 

 Hi, 

 Gemi has wrote this driver for a particular board 
  https://github.com/kinsamanka/PICnc-V2/wiki . 
 I can't 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

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



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 removed, to be more consistent with
  hal_gpio, and to use bcm2835.h more (this requires work on
  hal_spi.c)



it compiles, but while executing it has some problem in
  finding get_rpi_revision,
  


That should not be so

You got that error because you only included cpu_info.h but nothing
else.
I included the actual code by using
#include "cpu_info.c"

When I do a check on the module my code produced and the functions
defined I get

root@INTEL-i7:/usr/src/machinekit/rtlib/rt-preempt# nm -C hal_spi.so
5370 b accum
5358 b accum_diff
53a0 b BCM2835_PERI_BASE
 U close@@GLIBC_2.2.5
52d8 b comp_id
52c0 b completed.7389
 w __cxa_finalize@@GLIBC_2.2.5
11a0 t deregister_tm_clones
1210 t __do_global_dtors_aux
4e08 t __do_global_dtors_aux_fini_array_entry
50d0 d __dso_handle
52e0 b dt
4e10 d _DYNAMIC
 U fclose@@GLIBC_2.2.5
 U feof@@GLIBC_2.2.5
 U fgets@@GLIBC_2.2.5
2fdc t _fini
 U fopen@@GLIBC_2.2.5
1250 t frame_dummy
4e00 t __frame_dummy_init_array_entry
3760 r __FRAME_END__
12e0 t get_cpuinfo_revision
1422 t get_rpi_revision


So get_cpuinfo_revision() and get_rpi_revision() are
both in the text section of the module and are local to it.

If they were undefined they would have a U in front of them

Are you somehow trying to run your old module again?

Run the nm command above on your module.


  
 
any suggestion to help hal_spi dinamically link this?



maybe a issue or pull request on github may be a more
  relevant place for this discussion?





Il giorno domenica 30 settembre 2018 16:22:51 UTC+2, Schooner ha
scritto:

   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 upon version detected.

Just added code for number_of_cores() and included
cpu_info.c to get the others.

It builds but needs testing

If you get problems, add some DBG prints to see what
revision and number of cores is being returned

regards

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 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 actually linked it or similar.

Each driver probably needs to have all the routines
and info within it.

On 29/09/18 17:41, mngr wrote:


  
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

Re: [Machinekit] using hal_spi module

[mngr]

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 removed, to be more consistent with hal_gpio, and to use 
bcm2835.h more (this requires work on hal_spi.c)

it compiles, but while executing it has some problem in finding 
get_rpi_revision,
any suggestion to help hal_spi dinamically link this?

maybe a issue or pull request on github may be a more relevant place for 
this discussion?


Il giorno domenica 30 settembre 2018 16:22:51 UTC+2, Schooner ha scritto:
>
> 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 upon version 
> detected.
>
> Just added code for number_of_cores() and included cpu_info.c to get the 
> others.
>
> It builds but needs testing
>
> If you get problems, add some DBG prints to see what revision and number 
> of cores is being returned
>
> regards
>
> 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 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 actually linked it or similar.
>>
>> Each driver probably needs to have all the routines and info within it.
>>
>> On 29/09/18 17:41, mngr wrote:
>>
>> 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 not happen if I run halcmd loadrt hal_gpio
>>
>>
>> then I have seen that there is bcm26835.h that unify all the useful 
>> definitions, it would be nice if hal_spi.h was removed since it duplicates 
>> definitions.
>> the only problem is that hal_spi.h defines the register addresses, while 
>> bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified.
>>
>>
>>
>> Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: 
>>>
>>> On 28.09.18 17:16, schoo...@gmail.com wrote: 
>>> > 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. 
>>>
>>> Hi, 
>>>
>>> Gemi has wrote this driver for a particular board 
>>>  https://github.com/kinsamanka/PICnc-V2/wiki . 
>>> I can't believe that it is very useful for someone else. 
>>> IMHO the nomenclature isn't overly happy. 
>>> A little bit to general. ;) 
>>>
>>> BR 
>>>
>>
>> I need a way to write commanded velocity on the spi, my bigger problem 
>> wiill be on the spi-slave, and this seems to me a pretty easy protocol to 
>> implement 
>>  
>> -- 
>> 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.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 upon
version detected.

Just added code for number_of_cores() and included cpu_info.c to get
the others.

It builds but needs testing

If you get problems, add some DBG prints to see what revision and
number of cores is being returned

regards

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
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 actually linked
it or similar.

Each driver probably needs to have all the routines and info
within it.

On 29/09/18 17:41, mngr wrote:


  
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 not happen if I run halcmd loadrt hal_gpio




then I have seen that there is bcm26835.h that
  unify all the useful definitions, it would be nice if
  hal_spi.h was removed since it duplicates definitions.
the only problem is that hal_spi.h defines the
  register addresses, while bcm2835.h defines offsets,
  so a lot of hal_spi.c would have to be modified.






Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2,
XL600R ha scritto:
On 28.09.18 17:16, schoo...@gmail.com
  wrote: 
  > 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. 
  
  Hi, 
  
  Gemi has wrote this driver for a particular board 
   https://github.com/kinsamanka/PICnc-V2/wiki
  . 
  I can't believe that it is very useful for someone
  else. 
  IMHO the nomenclature isn't overly happy. 
  A little bit to general. ;) 
  
  BR 



I need a way to write commanded velocity on the
  spi, my bigger problem wiill be on the spi-slave, and
  this seems to me a pretty easy protocol to implement 

 
  
  -- 
  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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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
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 actually linked
it or similar.

Each driver probably needs to have all the routines and info
within it.

On 29/09/18 17:41, mngr wrote:


  
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 not happen if I run halcmd loadrt hal_gpio




then I have seen that there is bcm26835.h that
  unify all the useful definitions, it would be nice if
  hal_spi.h was removed since it duplicates definitions.
the only problem is that hal_spi.h defines the
  register addresses, while bcm2835.h defines offsets,
  so a lot of hal_spi.c would have to be modified.






Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2,
XL600R ha scritto:
On 28.09.18 17:16, schoo...@gmail.com
  wrote: 
  > 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. 
  
  Hi, 
  
  Gemi has wrote this driver for a particular board 
   https://github.com/kinsamanka/PICnc-V2/wiki
  . 
  I can't believe that it is very useful for someone
  else. 
  IMHO the nomenclature isn't overly happy. 
  A little bit to general. ;) 
  
  BR 



I need a way to write commanded velocity on the
  spi, my bigger problem wiill be on the spi-slave, and
  this seems to me a pretty easy protocol to implement 

 
  
  -- 
  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.

Re: [Machinekit] using hal_spi module

[mngr]

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 actually linked it or similar.
>
> Each driver probably needs to have all the routines and info within it.
>
> On 29/09/18 17:41, mngr wrote:
>
> 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 not happen if I run halcmd loadrt hal_gpio
>
>
> then I have seen that there is bcm26835.h that unify all the useful 
> definitions, it would be nice if hal_spi.h was removed since it duplicates 
> definitions.
> the only problem is that hal_spi.h defines the register addresses, while 
> bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified.
>
>
>
> Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto: 
>>
>> On 28.09.18 17:16, schoo...@gmail.com wrote: 
>> > 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. 
>>
>> Hi, 
>>
>> Gemi has wrote this driver for a particular board 
>>  https://github.com/kinsamanka/PICnc-V2/wiki . 
>> I can't believe that it is very useful for someone else. 
>> IMHO the nomenclature isn't overly happy. 
>> A little bit to general. ;) 
>>
>> BR 
>>
>
> I need a way to write commanded velocity on the spi, my bigger problem 
> wiill be on the spi-slave, and this seems to me a pretty easy protocol to 
> implement 
>  
> -- 
> 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.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 info within
it.

On 29/09/18 17:41, mngr wrote:


  
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 not happen if I run halcmd loadrt hal_gpio




then I have seen that there is bcm26835.h that unify all
  the useful definitions, it would be nice if hal_spi.h was
  removed since it duplicates definitions.
the only problem is that hal_spi.h defines the register
  addresses, while bcm2835.h defines offsets, so a lot of
  hal_spi.c would have to be modified.






Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha
scritto:
On
  28.09.18 17:16, schoo...@gmail.com
  wrote:
  
  > 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.
  
  
  Hi,
  
  
  Gemi has wrote this driver for a particular board
  
   https://github.com/kinsamanka/PICnc-V2/wiki
  .
  
  I can't believe that it is very useful for someone else.
  
  IMHO the nomenclature isn't overly happy.
  
  A little bit to general. ;)
  
  
  BR
  



I need a way to write commanded velocity on the spi, my
  bigger problem wiill be on the spi-slave, and this seems to me
  a pretty easy protocol to implement 

 
  
  -- 
  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.

Re: [Machinekit] using hal_spi module

[mngr]

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 not happen if I run halcmd loadrt hal_gpio


then I have seen that there is bcm26835.h that unify all the useful 
definitions, it would be nice if hal_spi.h was removed since it duplicates 
definitions.
the only problem is that hal_spi.h defines the register addresses, while 
bcm2835.h defines offsets, so a lot of hal_spi.c would have to be modified.



Il giorno venerdì 28 settembre 2018 19:45:13 UTC+2, XL600R ha scritto:
>
> On 28.09.18 17:16, schoo...@gmail.com  wrote: 
> > 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. 
>
> Hi, 
>
> Gemi has wrote this driver for a particular board 
>  https://github.com/kinsamanka/PICnc-V2/wiki . 
> I can't believe that it is very useful for someone else. 
> IMHO the nomenclature isn't overly happy. 
> A little bit to general. ;) 
>
> BR 
>

I need a way to write commanded velocity on the spi, my bigger problem 
wiill be on the spi-slave, and this seems to me a pretty easy protocol to 
implement 
 

-- 
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.

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

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 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.

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;
and https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401
  it does something on GPIO23 and 24. for which raspberry
  version was it written?
  


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 0x2000 from RPi 2 on it is at  0x3F00


hal gpio recognize this difference, hal_spi
  does not, I still have to run hal gpio, though,
  will do it in next days



https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
  here is a BCM 2837 datasheet that shows all the
  addresses, I will try to correct them 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?
 

Re: [Machinekit] using hal_spi module

[mngr]

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.
>
> 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;
and 
https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_spi.c#L401
 
it does something on GPIO23 and 24. for which raspberry version was it 
written? 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.


 

>
>
> 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 0x2000 from RPi 2 
>> on it is at  0x3F00
>>
>> hal gpio recognize this difference, hal_spi does not, I still have to run 
>> hal gpio, though, will do it in next days
>>
>> https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
>> here is a BCM 2837 datasheet that shows all the addresses, I will try to 
>> correct them 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) & 0x0001)
 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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

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.

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 0x2000
from RPi 2 on it is at  0x3F00


hal gpio recognize this difference, hal_spi does not, I
  still have to run hal gpio, though, will do it in next
  days



https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
  here is a BCM 2837 datasheet that shows all the addresses,
  I will try to correct them 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 

Re: [Machinekit] using hal_spi module

[mngr]

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 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, hal_spi does not, I still have to run 
> hal gpio, though, will do it in next days
>
> https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
> here is a BCM 2837 datasheet that shows all the addresses, I will try to 
> correct them 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) & 0x0001)
>>> 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 
 initerr
 Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
 initdbg
 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 

Re: [Machinekit] using hal_spi module

[mngr]

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, hal_spi does not, I still have to run 
hal gpio, though, will do it in next days

https://web.stanford.edu/class/cs140e/docs/BCM2837-ARM-Peripherals.pdf
here is a BCM 2837 datasheet that shows all the addresses, I will try to 
correct them 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) & 0x0001)
>> 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 
>>> initerr
>>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
>>> initdbg
>>> 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.
>>>
>>> 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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) & 0x0001)
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 initerr
Sep 23 15:03:17 realtimepi rtapi:0:
4:rtapi_app:701:user : hal_spi initdbg
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

Re: [Machinekit] using hal_spi module

[mngr]

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) & 0x0001)
> 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 
>> initerr
>> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
>> initdbg
>> 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
>> :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 initerr\n");
>>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
>>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 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 initerr
Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user :
hal_spi initdbg
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
: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.
  

Re: [Machinekit] using hal_spi module

[mngr]

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 
> initerr
> Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi 
> initdbg
> 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
> :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 initerr\n");
>> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
>> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\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?
>>>
>>

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 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
: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
initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi
initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi
initall\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, 

Re: [Machinekit] using hal_spi module

[mngr]

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 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 initerr\n");
> rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
> rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\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 0x7FFF, 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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  

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 initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\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 0x7FFF, 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
   

Re: [Machinekit] using hal_spi module

[mngr]

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 initerr\n");
rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi initdbg\n");
rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi initall\n");

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 0x7FFF, 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 
>> loadrt hal_spi
>> in the hal file, but 
>> 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 intrinsicslibwebsockets=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" 
>> 

Re: [Machinekit] using hal_spi module

[mngr]

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 0x7FFF, 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 
>> loadrt hal_spi
>> in the hal file, but 
>> 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 intrinsicslibwebsockets=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 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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?

Regards DEBUG, the ini file bit was explained by the text you
deleted from yours.
It takes a hexidecimal number up to 0x7FFF, 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

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 


  
  loadrt hal_spi


  in the hal file, but 

  
  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

Re: [Machinekit] using hal_spi module

[mngr]

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 
> loadrt hal_spi
> in the hal file, but 
> 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 intrinsicslibwebsockets=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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


CRAMPS.ini
Description: Binary data


CRAMPS.hal
Description: Binary data
Sep 22 09:42:34 realtimepi pi: logtest:ac39f5cfe91390fa49d37c47c58f4784
Sep 22 09:42:44 realtimepi pi: logtest:45acd71bcc7d98aa8a2059b954a25bd7
Sep 22 09:43:11 realtimepi pi: logtest:baadee1b75f3acfa77e024757363affe
Sep 22 09:46:23 realtimepi msgd:0: startup pid=862 flavor=rt-preempt rtlevel=1 
usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516  version=unknown
Sep 22 09:46:23 realtimepi msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 
atomics=gcc intrinsicslibwebsockets=2.0.3
Sep 22 09:46:23 realtimepi msgd:0: configured: sha=f63b8a215
Sep 22 09:46:23 realtimepi msgd:0: built:  Sep 22 2018 08:06:40 
sha=f63b8a215
Sep 22 09:46:23 realtimepi msgd:0: register_stuff: actual hostname as announced 
by avahi='realtimepi.local'
Sep 22 09:46:23 realtimepi msgd:0: zeroconf: registering: 'Log service on 
realtimepi.local pid 862'
Sep 22 09:46:24 realtimepi msgd:0: zeroconf: registered 'Log service on 
realtimepi.local pid 862' _machinekit._tcp 0 TXT 
"uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" 

Re: [Machinekit] using hal_spi module

[schoone...@gmail.com]

  
  
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 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 


  
  loadrt hal_spi


  in the hal file, but 

  
  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+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.