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 >>> <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. >> 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.
processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 2 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 3 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : BCM2835 Revision : a02082 Serial : 00000000934bcf42
