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) & 0x00010000) which is extremely specific and if something has changed or if SPI is not enabled, it will hang forever. (gripe here, I have asked you 3 specific questions and you have not answered any of them) On 23/09/18 18:01, mngr wrote: Thanks for the explanation about machinkit workings, I played with the stamps and found that it was blocking on while (!(BCM2835_SPICS & SPI_CS_DONE)); (Line 438) removing it halrun loads, now I will see if and what it writes. maybe I will have to control the low level implementation... but now I know more things. One more question, how does a hal module read the args? Il giorno domenica 23 settembre 2018 17:47:44 UTC+2, Schooner ha scritto: Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user hal_spi.so default iparms: '' Sep 23 15:03:17 realtimepi rtapi:0: 1:rtapi_app:701:user : hal_spi init!!!!err Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user : hal_spi init!!!!dbg Sep 23 15:03:17 realtimepi rtapi:0: 4:rtapi_app:701:user halg_xinitfv:90 HAL: initializing component 'hal_spi' type=1 arg1=0 arg2=0/0x0 Since you haven't said where these extra prints are located, their presence means nothing to me The module is obviously loading to a point but it does not look as though the driver is getting any further than hal_init, which calls halg_xinitfv() then is failing catastrophically You are loading with no args, are the defaults suitable for your board / setup? Not that it looks that it gets that far, due the complete absence of other error or info messages The insmod error is completely non specific, so doesn't help, may just be picking up the last return value. What is the output from /proc/cpuinfo and what version etc is your Pi? On 23/09/18 16:12, mngr wrote: Attached. In the log you can see the message I added in the hal_spi rtapi_app_main. pi@realtimepi:~ $ halcmd loadrt hal_spi <commandline>:0: insmod failed, returned -1: rtapi_rpc(): reply timeout See /var/log/linuxcnc.log for more information. pi@realtimepi:~ $ halcmd show all halcmd: cant connect to rtapi_app: -1 (uri= uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout E: 18-09-23 15:04:20 dangling 'DEALER' socket created at hal/utils/halcmd_rtapiapp.cc:281 Il giorno domenica 23 settembre 2018 16:43:25 UTC+2, Schooner ha scritto: On 23/09/18 15:16, mngr wrote: Il giorno domenica 23 settembre 2018 15:34:58 UTC+2, Schooner ha scritto: It's not about doubt cat /proc/cpuinfo will tell you whether you have BCM2835   Thanks didn't know about that! on the rpi is written 2837, bit cpuinfo says 2835! So at least the part that writes in the SPI registers should work. I tried to add some debug message in hal_spi rtapi_app_main function, but I don't see them anywhere, I have exported DEBUG=5, and maximized the DEBUG value in the ini file. I am looking in /var/log/linuxcnc.log and in the terminal output. I have tried with different msg types rtapi_print_msg(RTAPI_MSG_ERR, ": hal_spi init!!!!err\n"); rtapi_print_msg(RTAPI_MSG_DBG, ": hal_spi init!!!!dbg\n"); rtapi_print_msg(RTAPI_MSG_ALL, ": hal_spi init!!!!all\n"); There are plenty of error messages in the driver already.  I did not see any in the log however which makes me suspect it was never loaded. If insmod errors it should say why however and that was not in there either. Instead of complicating things with loading a non working config, just to load the driver, try this in a terminal on your Pi sudo > /var/log/linuxcnc.log (you may have to run this a root, it should zero the log) DEBUG=5 realtime restart halcmd loadrt hal_spi halcmd show all halrun -U That should give you a short log and if it errors loading hal_spi will be easier to trace through In addition to the log do dmesg | tail > dmesg.log and attach that log too If you do and the driver should work, we can try to find out why it isn't. If you don't, what the differences are from the BCM2837 for example, I have no idea I am guessing you are trying to generate steps using the SPI, that is an area outside my experience but there seems to be quite a bit about it on the RPi forums Actually, I tought that hal_spi is used to write something to a MCU that will control the motor generating steps. I think it sends the commanded velocity and the MCU updates the PWM. I am not sure of those things, though On 23/09/18 13:50, mngr wrote: Il giorno domenica 23 settembre 2018 13:41:42 UTC+2, Schooner ha scritto: The log does not show what your earlier email showed, there is not mention of an error from insmod I think you need to get right back to basics. This driver was written 5 years ago and is specific to the BCM2835 chip It can only have been meant to support Pi v1 & v2 and maybe not all of them, as they kept changing versions and hardware, because nothing of a higher version had been released then Does this driver support your Pi? In case of doubt I gave a look to wiringPi, it calls ioctl and write/reads from /dev/spidev. Is calling that syscall from a hal driver a sane thing to do? (It is for example used here)   Regards DEBUG, the ini file bit was explained by the text you deleted from yours. It takes a hexidecimal number up to 0x7FFFFFFF, the output is to terminal and the output is from NML messaging The exported DEBUG=5 is the debug setting for logging and relates to the rtapi system, not NML Thanks for the explanation, Schooner   On 23/09/18 11:07, mngr wrote: Il giorno venerdì 21 settembre 2018 16:44:50 UTC+2, Schooner ha scritto: You are not running with DEBUG=5 I edited DEBUG = 5 in ini file(in EMC section), nothing changed, then I exported DEBUG=5 in bash. what is the difference? what is the deBUG setting in the ini file for? Attached you can find the ini and the hal file, I edited the CRAMPS configuration, basically removing everything relative to the PRU, and adding loadrt hal_spi in CRAMPS.hal (and leaving one only axis) linuxcnc_old.log is everything before adding loadrt hal_spi. linuxcnc.log is the execution with loadrt hal_spi and termila_output shows what has been written, I attached it because it talks about rtapi_rpc(): reply timeout, that is not mentioned in the log pi@realtimepi:~ $ uname -a Linux realtimepi 4.14.66-rt40-v7 #2 SMP PREEMPT RT Mon Sep 17 21:15:46 UTC 2018 armv7l GNU/Linux   Do so and your linuxcnc.log will have info as to what failed. Also as I said in my last reply, it does not look as though you have a realtime kernel, irrespective of what you have named your pi. On 21/09/18 15:31, mngr wrote: Hi everyone, I am sorry to post another noob question here, but, I am trying to use the hal module hal_spi, shortly I tried with 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+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout. -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.