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 >> <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_p260c.c> >> ) >> >> >> >>> 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 <javascript:>. > 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.
